proposal: cohort management

[bobheadxi]

Summary

Rocket becomes capable of managing cohorts - tracking current members, retention rates, etc.

Requirements

A cohort corresponds to a Launch Pad season, for example "Fall 2020". This is different from a team in that members can sign up and leave themselves, and that each cohort is associated with periods of time. Cohorts should also be designed to persist across years and represent a history of participation for club membership. Maybe we can associate teams with cohorts as well.

Cohorts are associated with start and end dates:

• Before the start date, users can freely register and leave.
• After the start, users can only leave.
• After the end date, users can no longer make changes themselves.

UX

We add a set of /rocket cohort commands:

• /rocket cohort create $COHORT --start $START --end $END
  • Sets up a cohort of Rocket users.
  • Admins only.
• /rocket cohort delete $COHORT
  • Deletes a cohort of Rocket users.
  • Admins only.
• /rocket cohort edit $COHORT [--start $START] [--end $END]
  • Edits properties of a cohort.
  • Admins only.
• /rocket cohort list
  • Lists all cohorts and basic statistics about each.
  • All users.
• /rocket cohort view $COHORT
  • Comprehensive statistics about a cohort.
  • All users.
• /rocket cohort register $COHORT [--username $USER] [--force]
  • Registers a user in the cohort, defaulting to self. If the cohort has started, the command fails, unless the force flag is provided.
  • All users. Username and force flags for leads.
• /rocket cohort leave $COHORT
  • Removes user from the cohort. If the cohort has ended, the command fails.
  • All users.
• /rocket cohort remove $COHORT $USER
  • Removes given user from the cohort. Separate from cohort leave for ergonomic purposes.
  • Leads only.

Implementation

Database design requires some more thought as we decide how much scope this should encapsulate.

Context

This was brought up by @renehuang1999 , who expressed concerns about difficulties we have managing who is actively in Launch Pad, as well as their history of participation. This would also replace our current method of sending out tons of Google Forms with membership changing from form to figure out who is in Launch Pad each year.

It also makes the experience more proactive - instead of us always chasing down who is going to be a part of Launch Pad, members make that step themselves.

[renehuang1999]

This looks amazing! The only concern I have is that people sharing the command with people outside of the cohort and hence being seen as part of the cohort. But other than that this is really good, it will help us to track/update their contact and other info really easily. Perhaps we can even integrate polls with rocket, so their answers can be recorded in the database!

[bobheadxi]

The only concern I have is that people sharing the command with people outside of the cohort and hence being seen as part of the cohort.

This should be fine - after the start date, no one else will be able to join (unless they are an admin), and the cohort list can start being a point of reference to see who signed up / who shouldn't be there