repository access permissions

Controlling what access people have to repositories.

Classroom has the following levels of organization.

• owners — Members of the Classroom Team who manage GitHub membership and organization settings. Owners are set in the GitHub interface. They are omitted from the schemes described below.
• Classroom Team — Have admin access to every repository and can create new repositories. Can grant teachers write access to a repository.
• teachers and students — Write access to select repositories. Can handle pull requests for those repositories only. Cannot create new repositories. Read access to everything else.
• everyone else — Read access to every repository. Can make pull requests and open issues.

I see two ways to implement this. Both ways have their strengths and drawbacks. However, the no-teams approach seems to be simplest and fits our needs the best. I will implement that unless someone has objections.

Teams

Everyone participating in Classroom, whether they are part of Classroom Team or not, are members of the organization. Repository access is determined by membership in GitHub teams.

• Classroom Team — Administrators — This team has admin access to every repository. The members of this team maintain every other team. (Can that be done automatically?)
• teachers and students — many topic/use specific teams — Members of these teams have write access. Most of these teams may only have one repository each.

It may not possible to automatically make the members of Administrators the maintainers of every other team. Perhaps it could be done with a script? Manually setting would be cumbersome especially when adding someone to the Classroom Team, removing from the Classroom Team, and adding a new GitHub team.

All members of the organization can create repositories or no one can. I don't know any way to have different types of members. All members of the organization can create teams or no one can. Once again, I see no way to give this power to only select members. We can make all members of the Classroom Team organization owners and deny regular members the ability to create new repositories and teams. While I trust all the current members of the Classroom Team, we can't guarantee everyone in the future will be as trusted. (Folks from Arch Women, recall what happened to the Facebook page.)

The one thing about this approach which I really like is that it will show on everyone's account that they are part of Classroom. :)

No teams

GitHub has a rigid hierarchy of three kinds of contributors: organization owners, organization members, and outside collaborators. We map our hierarchy to that.

• Classroom Team — organization members — Default repository access will be admin. Have the ability to create new repositories.
• teachers and students — outside collaborators — Write access is granted only to the repositories they need to be able to push to. Or admin access. We can decide on a case by case basis.

This is simpler and gives the exact levels of access we want to give.

[eli-schwartz]

I think we should be able to do it with teams, assuming all permissions are set by the repo creator or an organization owner. What is the downside of allowing any member to create repos, at least assuming the admins keep an eye on all updates?

It shouldn't be hard for a teacher to ask an admin to create a new team, if no admins can manage a timely response we might have larger problems! 😲 I don't like the idea of organization hierarchies that end up with project leads that stop being involved and cannot be reached, as it would result in general decay at the top.

But TBH I'm not sure of the precise utility in adding anyone who asks and attended a class, as a member just so they can show it on their account.

Students of the git glass were given access to remote repositories to practice in for the class. Those were on the Arch Women server. I thought, may be for the future they can use repositories on GitHub. Now that you mention it, there is no reason to give them full membership. Even with teams, we could just give them outside contributor access.

With teachers, we only vet them for teaching a class. I don't want to give them full admin access to every repository. (I definitely do not want them all to have the ability to delete repositories.) At the same time I want to give full admin access to every repository to people on the Classroom Team (currently you, me, meskarune, HalosGhost, and polyzen). How do we do that with teams?

[eli-schwartz]

1. mark us (the supertrust group) as owners.

2. Create the classroom team and give the team admin access to the main repos. Politely ask teachers to give admin access to the classroom team, and (depending on the situation) drop their own permissions afterwards (the classroom team can always do this later though) for organizational purposes. Note that the "Default repository permission" setting could always be manually overridden by a repo creator, so it isn't really a security policy.

CORRECTION: You cannot drop permissions from the default permission, AFAICT. Sorry...
Not sure this actually matters though.

3. Add teachers to teams, thereby allowing them write or admin access as desired to the project repositories they are relevant to. By default anyone involved enough to be an org member can create and manage personal repos or personal teams under the archclassroom umbrella (and give other members access to their own repos via those teams), and if they abuse the privilege by creating the "I-hate-Archclassroom" repo full of propaganda for our dastardly competitors, or alternatively create 400 irrelevant repos full of their grandmother's salad recipes, we can expel them.

4. Default permissions will be read-only for all repos, unless you are 1) the repo creator, or 2) a member of the classroom team which is always added as an admin to new repos as a courtesy.

5. Classroom attendees are always welcome to join, and we can make them collaborators on test repos if needed, but they aren't really "members".
   Also Github has a perfectly adequate forking model, so we may not actually need this. I'm unclear on why the Arch Women server was offered back then at all, but my first guess is that not everyone has or wants a Github account. This specific usability issue would obviously not be solved by adding them as members to a Github organization.

I like this. Just one issue.

mark us (the supertrust group) as owners.

Owners can expel everyone else and what not. While I trust the current team, we can't guarantee everyone in the future will have that same level of trust. Sometimes you think a person is trustworthy and later you find out they aren't. (This has happened in other parts of the Arch community. I mentioned Arch Women's Facebook as one publicly known example.) We have the following hierarchy of people who need special access.

• Project lead(s)
• Classroom team
• Teachers

GitHub has three levels as well, owners, members, and outside contributors. The no-team scheme just a one-to-one correspondence between the two.

[eli-schwartz]

Depends on who "us" is. 😛 If classroom team is just a github team which is by convention given admin access to repos, then the "us" is whoever you have that same level of trust in (and if you cannot guarantee future members, then you can just add them to classroom team instead).

The alternative is to not add Teachers as organization members, but as collaborators.

The "us" group could just be you, meskarune, and HalosGhost as it currently is, assuming everyone thinks this is enough active people with the power to go in and fix repo access (because I'm certain if it came to kicking out a rogue salad recipe uploader, someone would find the time).

[meskarune]

So I am on the side of allowing people more access rather than less. But some things to consider: in the organization settings, we can turn off members being able to create/delete/change visibility/fork repositories individually. I think it might be a good idea to give all members access to contribute but prevent them from deleting so if someone trolls we can just roll back the history.

edit here is a list of the member permissions we can set which affect ALL members:

• Repository creation
• Repository deletion
• Repository visibility changes from public to private or vis versa
• Forking of members only (private) repositories
• Default repository permissions (each team can be assigned access to individual repos, however having lots of teams with such few contributors doesn't make sense to me, so maybe we can only add teams on an as needed basis)
  • Admin: Members will be able to clone, pull, push, and add new collaborators to all repositories.
  • Write: Members will be able to clone, pull, and push all repositories.
  • Read (this is the current setting): Members will be able to clone and pull all repositories.
  • None: Members will only be able to clone and pull public repositories. To give a member additional access, you’ll need to add them to teams or make them collaborators on individual repositories.

I propose we have the classroom organizers as a team and teachers as a team, all others can just have the default member permissions.

So first we need to decide, what should the default permissions for all members be? And what permissions should teachers and classroom organizers have?

I suggest that default members not have deletion/visibility change access, nor forking of private repos. Read access is also probably fine as a default.

Classroom organizers can be given the ability to delete/change visibility and fork private repos and teachers should be able to to change visibility of repos and have write access.

Teams can be assigned repos they have access to, so teachers can have access to the class repos, while classroom organizers would have access to the website repo along with everything else.

[meskarune]

Repositories also have per repo collaborators and team access.

Should be at the url scheme: github.com/archclassroom//settings/collaboration

We can assign collaborators and teams to individual repos rather than having a team with access to all repos, but idk how useful this would be.

[eli-schwartz]

This seems reasonable, but I cannot see those settings -- so, can default permissions be set separately per user/team in addition to the organization defaults?

[meskarune]

@eli-schwartz yes, you can have default settings for all members and settings per team.

Right now we have 3 teams, organizers which have access to the website repo, teachers which have access to the starter repo and past classes repo, and students which don't have access to anything, but which I think should have access to a "playground" repo for git workshops. We can add people for the class then remove after the class and reset the playground.