Using 'outside collaborators' to manage permissions on GitHub
30 views
Skip to first unread message
Daniel Beck
Feb 17, 2018, 2:49:13 PM2/17/18
to Jenkins Developers
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/
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/
R. Tyler Croy
Feb 17, 2018, 3:10:23 PM2/17/18
to jenkin...@googlegroups.com
(replies inline)
On Sat, 17 Feb 2018, Daniel Beck wrote:
> 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.
This proposal seems quite sane to me.
From my recollection of INFRA trivia, I don't think that there is any tooling
except the irc-bot which is reliant on the diaspora of teams in the jenkinsci
organization.
> This means that???
> 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 jenkinsci-de...@googlegroups.com.
> 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.
- R. Tyler Croy
------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>
xmpp: rty...@jabber.org
% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------
On Sat, 17 Feb 2018, Daniel Beck wrote:
> 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.
From my recollection of INFRA trivia, I don't think that there is any tooling
except the irc-bot which is reliant on the diaspora of teams in the jenkinsci
organization.
> - 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/
>
> --
> - 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 jenkinsci-de...@googlegroups.com.
> 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.
- R. Tyler Croy
------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>
xmpp: rty...@jabber.org
% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------
Jesse Glick
Feb 19, 2018, 9:58:00 AM2/19/18
to Jenkins Dev
Would org membership allow people to be requested as reviewers on pull requests to repositories to which they lack write permission, which currently is the only workaround for this missing GitHub feature?
Daniel Beck
Feb 19, 2018, 11:44:21 AM2/19/18
to jenkin...@googlegroups.com
> On 19. Feb 2018, at 15:57, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> Would org membership allow people to be requested as reviewers on pull requests to repositories to which they lack write permission, which currently is the only workaround for this missing GitHub feature?
Baptiste Mathus
Feb 19, 2018, 3:16:55 PM2/19/18
to Jenkins Developers
LGTM.
Same concern/request as Jesse, but ack that it will be processed separately, makes sense.
--
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 jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4B71344F-D4E6-4506-BBFF-13F86357BFAE%40beckweb.net.
Daniel Beck
Feb 19, 2018, 5:19:19 PM2/19/18
to jenkin...@googlegroups.com
> Would org membership allow people to be requested as reviewers on pull requests to repositories to which they lack write permission, which currently is the only workaround for this missing GitHub feature?
>
I've addressed this problem in https://groups.google.com/d/msg/jenkinsci-dev/f2vwDQtEnEs/AvyrxgrOAQAJ
>
Reply all
Reply to author
Forward
0 new messages