Team management for administrators

[johndbritton]

When accepting a GroupAssignmentInvitation users have the ability to create or join a team, but in some cases they make a mistake as in #291.

One potential solution to this problem is to provide an interface for teachers to manage teams. This way they can reorganize the users if there's a mistake and we can keep the organization administrators in control of team changes.

It's also possible to have cases where repositories or teams have been deleted, we should make these situations recoverable.

cc/ @leouieda

[cboettig]

I believe this issue is related to #730, and thus might be (at least in part) addressed by pending PR #980. Linking them here since neither is mentioned above, though I'd appreciate clarification on this issue.

I agree that the inability to manage or change teams is a significant problem. Summarizing the above, a user cannot un-join a team; deleting the team using the GitHub 'Teams' interface just leaves the user a member of the team (Deleted Team), creating ghosts in assignments. This prevents changing teams between assignments or undoing accidentally joined teams.

One work-around I have found is to create a new "Set of Teams" when creating the assignment. This allows a user who had previously joined a team in some other "Set of Teams" to join a new new team. Unfortunately, there is no interface to list or manage these "Sets", and they appear to have no correspondence to the "Teams" menu in the GitHub organization (teams appear in that menu but with no mention or association to the "Set of Teams".).

Ideally these sets would show up as "meta-teams" (teams of teams) in the usual Teams menu of the organization, and deleting them there would simply erase the effect of creating a team.

A related but independent issue is that the current interface allows any student to join any other student's team. Maybe this is fine and nicely streamlines the process by sidestepping the need for the instructor to laboriously create all the student teams in advance. However, it also seems brittle, in that invariably someone will join the wrong team or want to change teams (an issue which is exacerbated by the inability to 'undo' this by 'leaving' or even deleting the team). The first student to create the 'team' doesn't get any control over which other student joins: perhaps a better workflow would be for the student who creates the team to get some ability to invite their teammates directly, rather than letting anyone opt in to their team?

Thanks for all the work on GitHub Classroom, this is a truly awesome and compelling workflow!

[leouieda]

One work-around I have found is to create a new "Set of Teams" when creating the assignment. This allows a user who had previously joined a team in some other "Set of Teams" to join a new new team.

After having a lot of trouble with students dropping out of the class or having problems with their teammates, I defaulted to creating new teams for every assignment. Most problems of that kind went away after that. It's not very efficient but for large classes it seems easier than micromanaging teams.

perhaps a better workflow would be for the student who creates the team to get some ability to invite their teammates directly, rather than letting anyone opt in to their team?

This seems like a great idea!

Explaining the workflow of "one student creates the team and the other then join that team" always causes some confusion in the first assignments. There is always someone who forgets to join the team and then keeps getting "access denied" errors when trying to push.

Thanks for all the work on GitHub Classroom, this is a truly awesome and compelling workflow!

+1000. This is an awesome product!