PR shepherds team?

We have a lot of PRs, and we’ve spawned a couple of techniques for getting them merged:

  • The recent “PRs ready for review” threads.
  • Users (notably @worldofpeace ) manually scanning through PRs to find things that need attention.
  • People often mention random committers who’ve been helpful in the past if things get stuck.

All of these are attempts to get active committers to look at PRs and get them through the final steps to being merged. I wonder whether we could ease this by adding a pr-shepherds team.

  • People can be added to pr-shepherds if they’re committers and they’re keen to help out with other people’s PRs.
  • Users can mention pr-shepherds if their PR is languishing (equivalent of posting in “PRs ready for review”).
  • We can add a line to the issue template telling people about this and especially recommending it for newcomers (hopefully alleviates the need to manually look through lots of PRs).
  • I think it should be “shepherds” rather than reviewers, since often the most useful reviews are giving by unprivileged maintainers or other users, and the shepherd just does a final check and merge.

This overlaps a bit with RFC-0039, but that’s about expanding the number of people who can do maintainer-y things, this is just about connecting existing keen maintainers with places where they can help.

Thoughts?

1 Like

Bots and automation is definitely the way to go long term, but in the meantime this sounds like a worthwhile experiment to me.

Another dimension to the problem is that issues don’t get assigned to maintainers. This would help shift the load considerably and also call onto the domain experts that have worked on that part of nixpkgs.

That’s why I added this block to the new issue templates:

```yaml
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:
```

I am not super happy with the usability of it but the idea is there. It allows the PR triage team to assign the issue to the right maintainer, and hopefully to develop tooling to automate the task later.

3 Likes

This is somewhat off the topic of the OP, but I was wondering if there is any good way to be notified about issues/PRs affecting a given part of nixpkgs.

For instance, I’d be willing to review issues/PRs for Haskell-related things, but I don’t know of any way to get notified only for Haskell stuff.

I don’t want to set the whole nixpkgs repo as “Watching” on GitHub, since I don’t want to get notified for every issue/PR.

If there was a way to only get notified for changes in the pkgs/development/haskell/ directory, I’d be happy to do more reviews.

How are other people managing this?

One way is that you can add yourself to CODEOWNERS. Unfortunately, the CODEOWNERS feature does not work that great with nixpkgs, because people are often changing their target branch from master to staging, which basically notifies every code owner.

1 Like

I’ve been essentially building this team without even knowing it :exploding_head:
I think this is a fine idea that I might even pick up, the part about newcomers especially interests me.

3 Likes

Yeah, I just think it’s a bit better to tell people to mention pr-shepherds rather than @worldofpeace. It looks a bit more professional, it doesn’t put all the work on you, and it’s keeps working when people’s level of interest waxes and wanes.

3 Likes

Indeed, I definitely need some help in this regard. I often have difficulty following up on the final phase of things as I constantly move through PRs.

Unfortunately, the CODEOWNERS feature does not work that great with
nixpkgs, because people are often changing their target branch from
master to staging, which basically notifies every code owner.

A thought I had about this recently was that OfBorg could, if it noticed
a large amount of rebuilds, post a comment encouraging people to
retarget their branch, including the instructions for how to correctly
change the base without notifying everyone.