RFC-0039: unprivileged maintainer team

[grahamc]

Package maintainers who are not able to commit directly to Nixpkgs
don't have adequate tools to attentively maintain their package.
OfBorg requests reviews of maintainers it can identify. GitHub only
allows requesting a review of a Collaborator of the repository.

This RFC bridges that gap, and allows OfBorg to request reviews of
maintainers.

---

Todo:

• add GitHub IDs to the maintainer list (maintainers: add github user IDs in service to NixOS/rfcs#39 nixpkgs#66361)
• Create the GitHub team: https://github.com/orgs/NixOS/teams/nixpkgs-maintainers
• Create a tool to update a team's members based on the maintainer list
• Write an explanatory post on Discourse about the what-and-why of this plan.
• Select a small group of maintainers who are not committers to be part of the first round, and manually run the tooling, and pause half a week to see what changes.
• Automate the tooling on the infrastructure.
• Expand the group to one quarter of the maintainers, and pause a half a week to gauge response.
• Expand the group to one half of the maintainers and wait one week.
• Expand the group to all of the maintainers.

---

Rendered: https://github.com/NixOS/rfcs/pull/39/files?short_path=68b0938#diff-68b0938e7e9a24cb0cc24ac6a70950b9

[7c6f434c]

Do we want to remove people automatically or by request?

[grahamc]

I think automatically. If they are removed from the maintainer list, they either are being forced out, or have requested removal.

[timokau]

I realize there are infrastructure difficulties preventing this, but ignoring those:

ofBorg could aggregate all its information into one comment. So after its done with eval and builds, it posts a comment like this:

I have successfully build on linux and darwin. Aarch64 was not attempted because it is marked as unsupported.
@MaintainerXYZ, you are listed as the maintainer for this package. Please review this change.

That way the "spam" is contained. In fact I would prefer it to no message at all. It also scales well for future ofBorg improvements. It could also add messages like

!Warning!: I have determined that this change will result in more than 500 rebuilds on linux but is targeted to the master branch.

[grahamc]

I don't think this is on topic for this RFC.

[alyssais]

How important is the GitHub UI for requesting reviews? Addresses most of the drawbacks, and I'm not sure the UI is that valuable in comparison.

[vcunat]

Creating the team seems fairly cheap to me. /cc comments will create unnecessary noise every time (e.g. e-mails), similarly to what borg did before being moved to the "checks" tab.

[alyssais]

Another alternative, not mentioned here, is to just automatically send mail to maintainers. This would require a custom program to be written, but so would the proposal here. No GitHub features required.

[Ekleog]

Additionally, it'd work for people who are not using GitHub. The only drawback (compared to this RFC) would be that reviews from maintainers wouldn't show up in color, but in gray -- but if ofborg adds approved-by-maintainer anyway that's likely not an issue ; esp. as otherwise reviews from maintainers of one package would appear in color for other packages too.

[7c6f434c]

Is it realistically bearable to be an active Nixpkgs package maintainer without Github account? I don't see many patches posted to mailing list, at least.

[Ekleog]

While a page listing PRs where one's review is requested without answer yet is an argument, I don't think we should choose our workflow based on hypothetical improvements GitHub could do later on. First, make the tooling, then decide the workflow accordingly.

Now, whether a page listing PRs where the review is requested and/or third-party dashboards are an advantage enough to warrant this change is another question. I personally don't use them and would assume people who maintain just one or two packages would see even less use to these, but may be wrong here :)

[7c6f434c]

I think given:
(a) various interesting corner cases in Github behaviour we hit from time to time,
(b) our story of migrating basically everything exchanging one featureset to another one
we shouldn't really look too much at what Github intends things to mean and we can ask which set of the side-effects we like better.

(I do probably like side-effects of review requests better than of a comment, unless there is a unified comment with everything ofBorg wants to say about the PR)

Separately, I think that making maintainership mean much more (even if desirable) has time horizon larger than replacing at least one part of the tool collection; so discussing how multiple tools (Github, ofborg, this team maintenance bot) interact can assume nothing big changes in the process for low-impact packages.

[grahamc]

I agree we shouldn't bank on GitHub making big changes. I do think the existing tooling is very good already. I think changing behavior is much faster than you say -- small nudges have far reduced direct pushes within a short period of time of having ofborg do reasonable checks and validation.

[7c6f434c]

I think that works for tooling adoption — and high standards you uphold for ofborg help — better than for shifting general notions (especially in the direction that creates more single-person-of-delay situations).

Anyway, I agree that in the current situation review requests make the most sense.

[alyssais]

Having thought about this more, this isn’t actually mutually exclusive with an option that did not depend on GitHub, especially since implementing an email-based system would require no priveleges whatsoever, and could be done as an opt-in system by any community member. While I’m among the (probable) minority of community members who would like Nixpkgs development to move away from GitHub, this doesn’t actually increase our lock-in at all, and would be strictly better than what we have now.

[7c6f434c]

Do we want to phrase it this way as opposed to «non-constructively aggressive in project discussions» or something?

Both from the point of view of not using vague insults, and to put the focus on interactions where the maintainer status actually comes up.

[Synthetica9]

It could also be relevant in other places on GitHub, since one could display the NixOS badge under their name

[7c6f434c]

Not sure I have ever seen it done with NixOS badge, even where it would be constructive and relevant (as we are not writing the rules for banning for behaviour while pretending to represent NixOS organisation, I think focus should be on what happens usually)

[grahamc]

I'd like to keep this case vague, as it isn't intending to side-load a code of behavior. The first time I brought this up people were concerned with what if a real jerk is part a maintainer, and I think the general solution is we'll handle it however we handle it, and them being a member of this read-only team doesn't really change anything.

[benclifford]

to be clear (I think the later context says so) you mean, on-github reviews of PRs, not some other review mechanism?

and so if I am a maintainer, I'll get a regular looking github review and I can hit approve/request changes just like on any other project i'm a full super-full-powers member of?

[grahamc]

Right.

[benclifford]

this is weird phrasing for what i think you mean is that a github handle doesn't, over time, uniquely identify a user and might be reused?

[zimbatm]

yes, if you decide to rename @benclifford to something different then anyone can take back that old name

[alyssais]

Should we perhaps use user IDs instead?

[grahamc]

I think that is what this paragraph is saying we should do?

[7c6f434c]

Just for fun I tried to find out my own user-id on GitHub via UI and failed; I guess it is only available in some API query…

[grahamc]

https://api.github.com/users/7c6f434c you're #1891350 https://github.com/NixOS/rfcs/pull/39/files#diff-68b0938e7e9a24cb0cc24ac6a70950b9R78

[7c6f434c]

Thanks, indeed API-only, but at least easy to access.

[benclifford]

Someone who is banned from the NixOS GitHub organization is not allowed to be a package maintainer.

i don't understand quite what this means?

If i'm a jerk, you will ban me from the github organisation and then I will have to maintain my packages in the same way as: "Package maintainers who do not wish to have a GitHub account will not benefit from this change." - i.e. jerks will not benefit from this but will not otherwise be harmed?

[7c6f434c]

Well, they will also not be able to participate in GitHub discussions, and submit PRs (which are the main way of non-committer maintainers updating their packages)

[kragniz]

I think this would work better as an opt-in process.

[alyssais]

I think it's reasonable to expect people who sign up to maintain packages to receive notifications about proposed changes to those packages. That's really all the maintainer role is for, isn't it?

[grahamc]

This unresolved question is really will github let us spam a user with invitations, or will it protect the user from an automatic process trying to be a nuisance. Also, yes, I think it is reasonable to say people who are maintainers should get pings for their packages.

[7c6f434c]

A reasonable amount of state should prevent this spamming from happenning on our side, so maybe this is not too important.

[timokau]

@alyssais the maintainers may think bothering with 2fa isn't worth the benefits. In that case they may still do their maintainer duties but shouldn't be spammed by invitations.

[grahamc]

Any spamming of invitations is a bug, probably on both GitHub's side, and definitely on our side.

[7c6f434c]

Given that GitHub allows spamming with review requests for same changes, I would say we cannot expect any extra line of defense…

[lheckemann]

One potential side effect of "spamming" could be that people remove their maintainership to avoid the notifications. I'd consider this probably a good thing, as it promotes "freshness" of maintainership info and packages actually being maintained.

[7c6f434c]

Spamming in my comment meant asking me to review the exact same commit I had previously approved (I evaluated it faster than ofborg, I guess). Spamming in this thread is about resending team invitation before the person in question reacts.

One mention per actual change is not spamming and makes sense etc.

[ckauhaus]

A certain amount of races will be inevitable. We should, of course, try to minimize time windows where eager human action is not detected.

[Ekleog]

Does GitHub allow credentials to be limited enough to only add/remove members to a read-only team? I would have guessed it required Owner access to the organization.

[7c6f434c]

I think «Team maintainer» for «Maintainer team» might be a bit lower; it still seems to be able to give the team write access, though.

[grahamc]

I think API tokens can be created specifically for modifying teams, but maybe not a specific team. I tried to make this vague enough to say "as limited as possible, but still able to do the job."

[Ekleog]

My concern is: if the credentials given to the automated system have the ability to write to NixOS repos, then it becomes attack surface in our threat model that currently assumes the state of the GitHub NixOS repos is trusted.

[grahamc]

The minimum authority we can grant to a token is org:admin, unfortunately. This means it can add anyone to any team.

[shlevy]

@grahamc In this case I think we should make the code/node that has access to the token separate from the rest of the code and manage its lifecycle independently, exposing just the team managemnt as a locked down interface.

[Ekleog]

Can this go into the drawbacks section? It's more or less present with “a mistake in the automation”, but the offensive security aspect (ie. people willingly trying to break it) are only suggested here.

I was personally ambivalent before this information (unsure of both the advantages and the drawbacks), so adding potential attack surface for it makes me half-heartedly opposed to the change.

Maybe an option would be to have a cron mailing nixos owners when an invitation/ejection is required, and this could work without granting automation too much rights? If there are not too frequent changes to the maintainers list, then I think this could reasonably work.

[7c6f434c]

I think it is enough if in the 72h after adding the first maintainership it is rare that any packages maintained by the new maintainer receive a non-maintainer change…

[grahamc]

I think it would be an option to run it manually, but I think it is less good.

[7c6f434c]

About the frequency of maintainer list changes, just in case the tradeoff discussion turns to estimating the amount of effort: git log reports ~1–2 commit/day on normal months (of course, there are merge commits in the count, so I would estimate the number of additions as half that):

     50 Date:   2018-04
…
     32 Date:   2018-09
     41 Date:   2018-10
     27 Date:   2018-11
     14 Date:   2018-12

[7c6f434c]

Intuitively, there are committers, maintainers in the team, maintainers not on GitHub, and maintainers who have received but not accepted the invitation. If such lists are kept and re-synchronised, for the people with invitation sent the bot should simply wait for acceptance? If someone rejects and then changes the mind, we can probably handle it manually.

[LnL7]

Should membership be based on just master or also other branches like the active release?

[grahamc]

a great question!

It should probably be the sum of all the maintainers in the branches we release channel updates for: https://github.com/NixOS/nixos-org-configurations/blob/33967236a51f41fe4af1d1a321b505f61ed4f246/nixos-org/hydra-mirror.nix#L44-L57

any other release-branches should probably no longer accept PRs.

However, the new maintainer format was introduced in 18.03, so I don't think we can include 17.09. Additionally, the old branches should receive a patch including the user IDs of each maintainer.

This is also pretty complicated if a user changes their name, hmmm...

[Synthetica9]

Maybe ping based on the branch that the PR is against?

[grahamc]

OfBorg already does that, I think the question is what branches does the team's member list comprise of?

[timokau]

Realistically I would say just master is fine. If someone removed themselves as a maintainers since the last release, they probably won't be willing to review anyways.

[LnL7]

I can't think of a good argument to query multiple branches, just asking in case somebody does.

[grahamc]

I have addressed several questions in the latest push.

[shlevy]

Seems good to me.

[Zimmi48]

FTR, in the Coq organization, we invite lots of external contributors (in practice to a team granting write access, not just read access, but our branches are protected, so this is just about giving them rights to triage issues), but we wish that only the core developers are shown as members of the organization. Therefore, as an administrator, I can change the visibility status of these members from Public to Private (and not the converse). This could be automated by the bot.

[7c6f434c]

I think in case of Nixpkgs it is also convenient for members to see if the person commenting is a committer or not (basically, should I say «nice, mention me when this is ready to merge») — but yes, as a partial solution it might be better than nothing.

Of course, it creates a question whether we want to enforce public visibility of membership for committers.

[timokau]

I would actually like if there was a way to highlight maintainers. Gives a sense of membership and responsibility and gives their reviews more weight.

However making it completely indistinguishable from committers might be a problem. That information already is hard to get for nixpkgs.

[alyssais]

fwiw, unless you're already a committer, you don't even see "Member" on people's comments unless they've manually set that to be Public, so if you want to know if the person reviewing your PR will actually be able to merge it you have to poke through git to see if they've made a merge commit before.

[Zimmi48]

Actually, there is another way to know if they have write-access: whether their approved request appears as a green tick or a gray one (you have lots of examples of gray ticks in this very PR).

[grahamc]

Therefore, as an administrator, I can change the visibility status of these members from Public to Private (and not the converse). This could be automated by the bot.

This can be done, sure, however there is nothing preventing them from marking themselves publicly immediately after.

[alyssais]

I think having it public would actually be a good thing. It gives people a stake in the community, and it probably puts even more impetus on us to remove bad actors from our community.

[7c6f434c]

I don't think we can enforce public vivisbility anyway.

(And if we could, in a tradeoff between community-building «stake and visibility» and technical «visibility who can merge» I would argue for the latter, but I do recognise that different people have different opinions here)

[7c6f434c]

I would like to ask @ckauhaus for permission to nominate.

If that permission is granted, I want to nominate @ckauhaus as a person with an ongoing experience of both running an important part of semi-automated Nix*-related tooling and being a non-committer maintainer.

[grahamc]

This link is now visible: https://discourse.nixos.org/t/new-rfc-39-open-for-shepherd-nominations-unprivileged-maintainer-team/1933/1

I'd be interested in nominating @alyssais, given her being a fairly new member.

[grahamc]

Remember self-nominations are fine :)

[ckauhaus]

To me, implementing the changes suggested in this RFC would be definitely an improvement.

Possible add-on: would it be feasible to let non-committers have ofBorg set ticket labels? This is a capability I'm missing regularly.

[timokau]

@ckauhaus see NixOS/ofborg#216

[7c6f434c]

@ckauhaus I also hope that your being on the record as Caring About Security and Caring About Tooling will be useful whe co-moderating the security-vs-usability tradeoff discussions.

[lheckemann]

I'd like to self-nominate for shepherding this RFC.

[globin]

Per meeting of the @NixOS/rfc-steering-committee: Shepherding Team is @lheckemann as leader, @ckauhaus and @alyssais.

EDIT: Also shepherds, please be reminded that it could make sense to have a chat on IRC or by videoconferece, to discuss your opinions and with the author to move this forward in an orderly and constructive way!

[nixos-discourse]

This pull request has been mentioned on Nix community. There might be relevant details there:

https://discourse.nixos.org/t/shepherds-chosen-for-rfc-13-17-and-39/1964/1

[globin]

I think this RFC is a nice example of bringing our tooling forward to improve the use of features github can provide, without impeding current workflow and also enabling a wider audience to help review pull requests, which as I and other release managers have pointed out previously, is rather necessary!

I very much welcome this and would like to encourage anyone opposing this or having doubts about this to step up and voice their opinion, as otherwise if I haven't missed anything all issues brought forward earlier have been addressed.

[grahamc]

I'm delighted to say that the permissions grantable for the new team management APIs are much finer grained than before, requiring a GitHub Application instead. The credentials used for this implementation are now restricted to a much finer subset than we could have done when this RFC was authored. The scope it has can be read about here: https://developer.github.com/v3/apps/permissions/#permission-on-members

[grahamc]

First group has been invited:

with revision d76b4e2eb0f17793b305f746c8fbd8747c6cc46f of https://github.com/grahamc/rfc39/

[grahamc]

So far 26 people have been invited, and 20 have joined. One person contacted me confused about what the invitation was for. We may want to send an email to people before inviting them, but I'm inclined to wait and see how the next ~20 people go.

[grahamc]

As of now there are 30 members of the team, and I just invited another ~~25, with 32 pending invitations.

[grahamc]

There were 41 members with 22 invitations, and I invited more so now there are 43 members and 41 invitations.

[grahamc]

I've gotten cold feet on going in 250 person invitation sprees, so I've been doing 25-person groupings.

[grahamc]

I ended up extending https://github.com/grahamc/rfc39/ (softprops/hubcaps#228) to check pending invitations before adding new users. Users with existing invitations were not being pinged, but the list of users with a pending invitation was long enough to make it difficult to see what was actually happening in the dry run:

$ cargo run -- --credentials ./credentials.nix --maintainers ./maintainer-list.nix sync-team nixos 3345117
warning: dependency (hubcaps) specification is ambiguous. Only one of `branch`, `tag` or `rev` is allowed. This will be considered an error in future versions
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/rfc39 --credentials ./credentials.nix --maintainers ./maintainer-list.nix sync-team nixos 3345117`
Aug 26 21:59:00.500 INFO Loading maintainer information, absolute: /home/grahamc/projects/github.com/NixOS/rfc-39/maintainer-list.nix, from: ./maintainer-list.nix, module: rfc39:109
Aug 26 21:59:00.888 INFO Syncing team, team_id: 3345117, team_name: Nixpkgs Maintainers, exec-mode: SyncTeam, module: rfc39::op_sync_team:34
Aug 26 21:59:00.890 INFO Fetching current team members, team_id: 3345117, team_name: Nixpkgs Maintainers, exec-mode: SyncTeam, module: rfc39::op_sync_team:39
Aug 26 21:59:02.648 INFO Adding user to the team, noops: 1, removals: 0, additions: 1, limit: None, changed: 1, github-id: 302429, github-name: brainrape, nixpkgs-handle: brainrape, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:03.446 INFO Adding user to the team, noops: 21, removals: 0, additions: 2, limit: None, changed: 2, github-id: 7435854, github-name: calvertvl, nixpkgs-handle: calvertvl, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:03.957 INFO Adding user to the team, noops: 26, removals: 0, additions: 3, limit: None, changed: 3, github-id: 5525646, github-name: bricewge, nixpkgs-handle: bricewge, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:04.368 INFO Adding user to the team, noops: 29, removals: 0, additions: 4, limit: None, changed: 4, github-id: 1274409, github-name: brian-dawn, nixpkgs-handle: brian-dawn, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:04.774 INFO Adding user to the team, noops: 29, removals: 0, additions: 5, limit: None, changed: 5, github-id: 1945, github-name: casey, nixpkgs-handle: casey, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:05.190 INFO Adding user to the team, noops: 39, removals: 0, additions: 6, limit: None, changed: 6, github-id: 7716744, github-name: bstrik, nixpkgs-handle: bstrik, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:05.698 INFO Adding user to the team, noops: 41, removals: 0, additions: 7, limit: None, changed: 7, github-id: 33751841, github-name: buffet, nixpkgs-handle: buffet, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:06.111 INFO Adding user to the team, noops: 43, removals: 0, additions: 8, limit: None, changed: 8, github-id: 355401, github-name: BrianHicks, nixpkgs-handle: brianhicks, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:06.516 INFO Adding user to the team, noops: 43, removals: 0, additions: 9, limit: None, changed: 9, github-id: 24193, github-name: callahad, nixpkgs-handle: callahad, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:06.928 INFO Adding user to the team, noops: 56, removals: 0, additions: 10, limit: None, changed: 10, github-id: 82591, github-name: carlsverre, nixpkgs-handle: carlsverre, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:07.337 INFO Adding user to the team, noops: 59, removals: 0, additions: 11, limit: None, changed: 11, github-id: 289492, github-name: campadrenalin, nixpkgs-handle: campadrenalin, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:07.750 INFO Adding user to the team, noops: 68, removals: 0, additions: 12, limit: None, changed: 12, github-id: 2647566, github-name: bzizou, nixpkgs-handle: bzizou, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:08.068 INFO Adding user to the team, noops: 69, removals: 0, additions: 13, limit: None, changed: 13, github-id: 4621, github-name: bradediger, nixpkgs-handle: bradediger, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:08.564 INFO Adding user to the team, noops: 75, removals: 0, additions: 14, limit: None, changed: 14, github-id: 147284, github-name: eraserhd, nixpkgs-handle: eraserhd, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:09.076 INFO Adding user to the team, noops: 90, removals: 0, additions: 15, limit: None, changed: 15, github-id: 2506621, github-name: braydenjw, nixpkgs-handle: braydenjw, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:09.474 INFO Adding user to the team, noops: 109, removals: 0, additions: 16, limit: None, changed: 16, github-id: 91694, github-name: candeira, nixpkgs-handle: candeira, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:09.889 INFO Adding user to the team, noops: 128, removals: 0, additions: 17, limit: None, changed: 17, github-id: 5555066, github-name: canndrew, nixpkgs-handle: canndrew, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:10.408 INFO Adding user to the team, noops: 128, removals: 0, additions: 18, limit: None, changed: 18, github-id: 7214361, github-name: bugworm, nixpkgs-handle: bugworm, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:10.785 INFO Adding user to the team, noops: 128, removals: 0, additions: 19, limit: None, changed: 19, github-id: 86652, github-name: bramd, nixpkgs-handle: bramd, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:11.226 INFO Adding user to the team, noops: 133, removals: 0, additions: 20, limit: None, changed: 20, github-id: 24417923, github-name: c0bw3b, nixpkgs-handle: c0bw3b, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:11.592 INFO Adding user to the team, noops: 133, removals: 0, additions: 21, limit: None, changed: 21, github-id: 1516457, github-name: calbrecht, nixpkgs-handle: calbrecht, exec-mode: SyncTeam, module: rfc39::op_sync_team:115
Aug 26 21:59:12.047 INFO Adding user to the team, noops: 141, removals: 0, additions: 22, limit: None, changed: 22, github-id: 5241813, github-name: cartr, nixpkgs-handle: cartr, exec-mode: SyncTeam, module: rfc39::op_sync_team:115

Anyway, I'm hoping these updates aren't annoying. I figure it is good to document the roll-out somewhere.

The team is at 109 members with 79 invitations.

[grahamc]

At 148 members and 138 invitations I've started to get an error:

thread 'main' panicked at 'Failed to fetch team: Error(Fault { code: 403, error: ClientError { message: "Resource not accessible by integration", errors: None, documentation_url: Some("https://developer.github.com/v3/teams/#get-team") } }, State { next_error: None, backtrace: InternalBacktrace { backtrace: Some(stack backtrace:

[alyssais]

another data point: I heard from somebody who was at some point aware of this RFC that they were confused why they’d received the invitation.

[alyssais]

At 148 members and 138 invitations I've started to get an error:

Is that happening consistently?

[grahamc]

Yes, I've tried a few times and can't invite any more people. I've reached out to somebody at GitHub and am hoping to hear back.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/join-the-package-maintainer-team/3751/1

[grahamc]

Foolish PEBCAK. I changed the team ID by one digit :').

[grahamc]

We're within ~110 people of having everyone invited. Currently at 460 members, 453 pending invitations.

[7c6f434c]

Currently ~700 members (out of ~900 target size?). Is it true that everyone has been invited?

[Zimmi48]

Currently ~700 members (out of ~900 target size?). Is it true that everyone has been invited?

Not everybody decides to accept the invitation. The 2FA requirement in particular could turn off some people.

[7c6f434c]

@Zimmi48 I understand that; and 700 out of 900 is exactly the number where both «not everyone agrees to deal with 2FA/not everyone has got around to accepting» and «the slow rate-limit-fighting process has not converged yet» are plausible

[grahamc]

As of now, all the to-do items on this RFC are complete.

• the code is now owned by NixOS: github.com/nixos/rfc39
• the infra is automatically running the update tooling every 30 minutes: NixOS/infra@ef48be9
• there are graphs for its status: https://status.nixos.org/grafana/d/w8HHOCBWz/rfc39-maintainer-sync?orgId=1&from=1577147422732&to=1577156793325

As of now, the team has 733 members, with 376 pending invitations. About 100 new invitations were sent this evening, catching up with new maintainer entries over the past several months. Several people cannot be invited:

• 166 are a missing a githubId values (note: do not blindly add these, see note later)
• 43 are missing a github value (note: do not blindly add these, see note later)
• 2 people seem to have declined the invitation or blocked the repo or something where GitHub says we haven't invited them, but also we can't invite them.
• 1 person is blocked from being invited by GitHub due to U.S. trade controls law restrictions.
• Additionally, I accidentally removed (and re-invited -- sorry!) about 10 people as they didn't have a githubId set. I added their ID back.

Adding a github or githubId value after the initial addition:

You can't just go look up GitHub handles and assume it is right. Instead:

1. Find a maintainer without a githubId
2. Look in the git blame output and find that section
3. Look up that commit on GitHub and see who GitHub thinks authored it.
4. Find that user's ID (https://api.github.com/users/«username»)

This is because a surprising number of GitHub users change their account names!

[Mic92]

Thanks a lot for all the hard work!

[alyssais]

* 1 person is blocked from being invited by GitHub due to U.S. trade controls law restrictions.

Yikes.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/pull-reviewers-brave/5996/2

[grahamc]

This is requiring more work, as GitHub is now allowing us to send additional invitations after the first one. They have now purgedthe database of invited users twice in two months now. I have stopped the sync until I can add some sort of database.

[grahamc]

A PR using a database of invited people has been created and merged. We're doing automated invitations again. If you didn't want to join, this should be the last invitation you receive. See: NixOS/nixpkgs#107815