The best way to attract attention to issues and pull requests?


#1

Suppose I created an issue on GitHub, or a pull request that improves something. Is there a standard procedure to attract some attention to it, so that it could be reviewed/fixed/merged?

I assume that I need to @mention some core developers that can help. How do I know which ones to ping, if it’s not about a package (and thus there is no clearly defined maintainer)?

If someone already commented on the issue or PR, asked questions, received responses, and then seemingly forgot about it, how long should I wait before I try to send a reminder?


#2

I can relate with this issue and I am sure others can too. I have had several PRs open for weeks while some get merged in less than 1 hour. I think that there are a few reasons for this. Also I want to state that I am sure the maintainers are swamped.

So my question for the maintainers is what can we do for you to make your life easier accepting PRs?

One method that I know of is to add yourself to the ofborg known users. This allows you to build your PRs instead of them having to manually issue the commands. This allows you to “prove” that the package builds properly (making merging simple for the maintainer).

But I think the biggest barrier to PR attention has to do with several factors:

  • complexity: is it a simple refactor, update, or init of new package. If it’s not trivial it will be harder to get attention
  • dependencies: do many packages depend on this package? If so it has the potential to impact many users if not built properly so it need extra attention to make sure it is done right.
  • trust: have the maintainers seen you commit many PRs before? I know that my first few PRs took a long time to get correct due to agreed upon standards (capitalize this, no periods, etc.).

All of this takes time and keep in mind that nixpkgs receives around 20 issues and 50 PRs per day. I wonder if Github is a bottleneck?


#3

How does one get on this ofborg list of known users?


#4

Usually recommended by one of the maintainers. https://github.com/NixOS/nixpkgs/pull/48165#issuecomment-429033700 . If you look at the PRs for that repo it show the same story.


#5

Yeah it’s definitely annoying. If you have any specific ones to list here, I would be happy to take a look at them. There is definitely an ongoing struggle in handling are massive PR load in a robust way. I think we’ve gotten better but we also have had lots of new contributors - which is great but requires more time to go through.


#6

Since a month or two I have not spend much time reviewing and merging PR’s, mostly because:

  • all these tiny (Python) packages that keep being added cause a lot of work and relatively few gain, at least for those that can merge
  • issues with Hydra/staging. Instead of individual Python package updates, I prefer to do a batch upgrade to reduce the amount of work. Often, however, there are transient failures, or there is simply too much load.
  • it becomes work with few joy for those that review/merge.
  • the more packages that end up in Nixpkgs, the harder it gets to perform actual improvements.
  • there are too few people that can actually merge, and too few that maintain the packages they contributed.

#7

From the github statistics in the past week there were 277 PRs merged and 119 created, so if this trend continues, they all might get merged eventually. :slight_smile:

Does getting on the known-users list require a recommendation from someone of the team?


#8

Yes, if you do good work we’ll be happy to add you. There is no formal process so it helps to ask.


#9

There is no formal process so it helps to ask.

Which is a pity, because there may be users out there willing to give a hand but too shy to ask, or not sure to have the required skills. Or just needing the nudge to get started.

Could we consider having a “community manager” or something like that ? Someone responsible to give the required accesses and getting new committers started ? This could surely be discussed live at NixCon.


#10

It would help to have a system to report metrics on every contributors. Then we could create some rules based around that, and even automate it. After N contribution, get access to ofborg, after N+M merge access, …


#11

Does it actually require it? I though being a known-user pretty much just requires creating a PR on the ofBorg repository since there is little to no security risk involved. I think a recommendation would only be needed for trusted user (known user + darwin tests).

As I’ve said on IRC today I think “known user” status could actually be replaced by “has that user contributed to nixpkgs before”.


#12

My review workflow RFC is relevant to this discussion. If you think that is a good idea and want to help, it is currently blocked on this ticket, concretely the implementation of access rights.


#13

I guess we need to recruit more nixpkgs member then to scale with the workload.


#14

there are too few people that can actually merge, and too few that maintain the packages they contributed.

There are even ~1800 packages without a maintainer tag at the moment (some of those pkgs are really outdated).

What does it actually take to get write/merge permissions? I would be willing to review PRs that fall into my area of expertise (HPC/compute cluster related software, scientific software, etc.).

PS: I also have an open PR that sliped further down the list:


#15

We don’t have a formal process for that, but I think you would qualify for a maintainer based on your past contributions. I will ask in the IRC. @zimbatm do we have a list of people that can add members to the nixpkgs organization or is just domenkozar?


#16

Not my own, but the (Python) Tensorflow derivation is currently pretty useless, since it fails to open a shared library when tf.contrib is used. Since many machine learning project use at least some function from tf.contrib, they currently don’t work. A PR has been lingering for 3 weeks now that solves this problem:


#17

A tip from @FRidh is to mention the maintainer of the package in the pull request.
The auto-assigned reviewer is not necessarily the maintainer.


#18

That’s a great tip! I’ll do that the next time a PR get stale.


#19

We should give everyone access who shows to at least two persons from the foundation:

  • their passport from a country with a working legal system
  • can show at least two people from different companies in senior positions that would vouch for them

I can imagine there are quite some people who would agree to such terms. Currently, we have people committing which have less trust than that.


#20

I have had a PR open since April which took quite a bit of work. I have no idea how to get this reviewed as I am the only person in the darwin/GIS intersection.