(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.
> 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.
- R. Tyler Croy
------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>
xmpp: [email protected]
% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------
--
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/20180217201012.5bmdpx3siusso7qt%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
