elm-community / guidelines

guidelines for *-extra contributors

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Consolidate GitHub teams and standardize access permissions

mgold opened this issue · comments

We had some difficulty getting a new maintainer getting their access permissions (see #44). Let's organize this.

GitHub's organization team permission system is flexible, but somewhat complicated and probably designed for a more complicated case than ours. Recap:

  • "elm-community" is an organization.
  • Organizations can have members and "outside collaborators". We currently have a good amount of both.
  • Members can be given default permissions of none, read, write, or admin. Currently set to read.
  • Organizations can have teams. Members and repos must be added to teams manually, but if you need to control access to a subset of repos, they seem useful. Teams can be at-mentioned. We currently have these teams: Owners (which I think is "special"), guides (useless IMHO), maintainers (probably useful for mentions but tedious to keep updated), Manifesto (seems useless), and packages (used to give write or admin access to many repos; no apparent reasoning as to which are write vs admin).

I don't think we need to lock down write access to any repo to any member. It's not worth the hassle to, say, only allow the maintainer to merge a PR-- let etiquette dictate that instead. So here's my proposal:

  • We try to convert as many outside collaborators into members as possible (provided we trust them, and we should).
  • We change the default member access to Write.
  • We keep the Owners group small and give them admin access to everything.
  • We can discuss if we think Maintainers is worth keeping for the at-mentions.
  • All other groups are removed.
  • Users can be given admin access to specific repos if necessary. I don't think maintainers need admin access to their repo (moving a repo unexpectedly can wreak havoc, as I've found out...).

What do people think?

commented

Pretty busy right now so I'll keep replies short

We try to convert as many outside collaborators into members as possible (provided we trust them, and we should).

Yes

We change the default member access to Write.

Yes

We keep the Owners group small and give them admin access to everything.

Yes

We can discuss if we think Maintainers is worth keeping for the at-mentions. All other groups are removed.

Yes. We need to keep some way of mentioning people via tagging. A team seems the easiest way.

Users can be given admin access to specific repos if necessary. I don't think maintainers need admin access to their repo (moving a repo unexpectedly can wreak havoc, as I've found out...).

Somewhat disagree - there are some things you can't do without being an admin, like setting up build systems and friends -> https://help.github.com/articles/repository-permission-levels-for-an-organization/#changing-repository-settings
But don't care enough to push back hard

Users can be given admin access to specific repos if necessary. I don't think maintainers need admin access to their repo (moving a repo unexpectedly can wreak havoc, as I've found out...).

Somewhat disagree - there are some things you can't do without being an admin, like setting up build systems and friends

Having CI for all/most of our repos would be great, so I definitely don't want to discourage that. We can discuss this point further.

I have removed all teams except owners and maintainers, and changed the default permissions to write. I have also invited a few outside collaborators who I have seen around (virtually) to be members; that's an ongoing process.

It also seems that the Owners team does not impart any permissions and is not auto-updated, but it's useful for at-mentions.