Hi everyone,
This is another proposal in my series of GitHub permissions cleanups
(previously: [1][2][3]).
This is a pre-JEP email request for comments.
This proposal affects how we manage GitHub permissions longer term, so should
be JEPed.
Thanks!
Daniel
The problem
===========
Currently we're using mostly per-repository teams for managing per-repository
permissions. My best guess is that this is a relic from when GitHub did not
have the concept of 'outside collaborators'[4], and there was no other way to
manage permissions.
Given that we overwhelmingly define permissions on a per-repository (typically
for a plugin) level, this resulted in more than 1700 teams, org-wide, much more
than could be hoped to be managed efficiently. From an inventory I've done on
Saturday, Feb 17:
- We have 62 teams with neither members nor associated repos.
- We have 327 teams with one repository but without members.
- We have 176 teams with one member and no associated repos.
- We have 700 teams with one member and one repository.
All of these cases are pretty useless *as teams*:
- The first three don't grant permissions or facilitate communication[5]. I'll
remove them at the earliest opportunity, but that'll still leave 1200.
- The fourth case just adds an additional, unnecessary level of indirection to
granting one user permissions on one repository.
Then there are the nontrivial configurations:
- We have 455 teams with multiple members and one repository. While there's
per-team communication on GitHub that could be used in these cases, I don't
know whether any actually use it (and the preview API for it seems broken right
now, contacted GH support already).
- We have 22 teams with multiple members and no repos, which is sometimes used
for special teams like Code Reviewers. Some of these are useful as teams.
- We have 10 teams with one member and multiple repos, which are exclusively
per-repo teams with incorrect repo associations (leftovers from [3]).
- We have 17 teams with multiple repos and multiple members. Some of these are
useful as teams.
A few more notes on how permissions currently work:
- Per-repo teams ("foo-plugin Developers") are being used to grant permissions
on repos different from the one they're named after (see [3], and there are
still -- or again -- such teams). It is unclear whether that is intentional or
not, and there's no natural way for team maintainers to indicate one way or the
other. Our aproach makes using teams as intended very difficult, as I'm likely
to just reset them to the 'proper' state, disrupting their members' work.
- Basically no team has a 'team maintainer', i.e. a member who can manage team
membership and invite others, as we use the bot for that.
- Since we grant repo admin permissions, but not team maintainer permissions,
there are already many repos that use 'outside contributors' to manage
permissions.
All of the above combined mean that teams are a clunky mechanism we're using in
a way that gives us no benefits, adds an additional admin burden, and is
inconsistent with how developers grant permissions.
The proposal
============
The end state
-------------
We use 'outside collaborators' for the vast majority of permissions management.
This includes all bot-assigned permissions. This will align bot use with what
repo admins do already, and remove the additional layer of indirection.
Teams are only used to facilitate interaction (e.g. "Code Reviewers") or manage
permissions across repo boundaries (for example Core, Blue Ocean, Pipeline, and
similar larger-scale projects involving multiple repos).
How to get there
----------------
We delete the majority of teams and convert their members to outside
collaborators, preserving effective permissions. I expect that this will remove
almost all of the 1200 teams we have, probably retaining 10-20 or so.
Since this won't affect permissions (unless I clean up the leftovers from [3]
first), it shouldn't disrupt work to a notable degree. Contributors who were
able to add/remove outside contributors before will still be able to do that.
I'll make sure not to delete teams with conversations, without discussing it
with the team members first, but I don't expect that this will affect many
teams. Effective repo permissions will be retained. Teams for cross-repository
permission management by project teams like Blue Ocean can be recreated on
request.
Dealing with org membership
---------------------------
This is admittedly of secondary interest to me, as membership does not grant
permissions, but I think you should be able to an org member iff you're a
contributor to Jenkins or its plugins.
This means that…
- we invite people to join the jenkinsci org when we invite them as a
collaborator to a repo via the bot. I think these invitations are independent.
- we periodically invite people to join the org if they are currently outside
collaborators (e.g. manually added) and aren't already invited to join.
- we periodically remove people from the organization that are not members of
any team, or outside collaborators to any repository.
If these points are contested, I'd be happy to exclude this from the current
proposal. This would just mean that future newcomers to the project would
probably get no opportunity to join the GH organisation, however.
1: https://groups.google.com/forum/#!msg/jenkinsci-dev/ksKAsmsmVng/lG2lNEaJBQAJ
2: https://groups.google.com/forum/#!msg/jenkinsci-dev/p1QEin62S7M/v2ALl9A5BQAJ
3: https://groups.google.com/forum/#!msg/jenkinsci-dev/UMzB3DMiyrs/UgMXfq-1BQAJ
4:
https://help.github.com/articles/adding-outside-collaborators-to-repositories-in-your-organization/
5: https://help.github.com/articles/about-team-discussions/
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/39D18ABD-ADA2-44A4-9872-0FB3284BF2C4%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
