This is definitely true, and I don’t think we should point at that graph when trying to ‘sell’ Nix/NixOS to them.
However, here it was used as an (IMHO convincing) argument that even though there are ‘many’ open PR’s, this definitely does not mean we are ‘lagging behind’: we’re just “active”.
I think that the graph is an excellent selling point of NixOS. Perhaps it should even on the website. That was the main argument that led me to use NixOS - seeing that so many packages are available, that GitHub is in use (no mailing lists!) and that there’s a guy who runs a bot that updates them all (
@ryantm) 1.
Agreed,
But you could also say that nix allows for us to do more with less resources. The declarative style is a “force multiplier” in terms of man hours.
Still blows my mind that I’m able to use the power of git to review changes, which are usually identical to the changes intended by the author.
The specifics of the PR template (and review process) do sometimes mismatch with the specifics of a particular change. I can remember a case, where this introduced “burocratic overhead” in the likes of somebody manually checking a macos build for some go tooling (or something of that kind). If I’m not mistaken, a variation in mac build compatibilitiy does not depend on variation of the proposed changes to nixpkgs as far as go is concerned.
I think nixpkgs-review is a promising project (and a low hanging fruit!) to lower the friction.
nixpkgs-review should be arranged for self-handling all non domain-specific aspects of a review in the hands of the proponents themselves. For the domain specific aspects, the proponents are anyway mostly the best available experts on any specific tool.
Positively nixpks-review’d changes should enjoy a trust bonus, e.g. via a label. → Arrange for nixpkgs-reviewed label with ofborg · Issue #137 · Mic92/nixpkgs-review · GitHub
I also think a stalebot should up the pressure and triage serious commitments from less serious ones by introducing the notion of time constraint and thereby revealing contributor’s true priorities. (If finding a reviewer is part of the game, so be it!) — that would also put soft constraints on reviewer’s deliberation to not exceed reasonable conern.
Addendum: maintainers should be allowed to become teams, akin to what github’s research department figured in CODEOWNERS — together with ofborg requesting reviews from those people.
For this to become somewhat near to effective some semantic reorganization of the repo that roughly fits interest-conform review teams would be necesary together with such folder level overrides for default reviewers per folder.
That would make ist so easy for people to jump on and off the train as a reviewer by simpliy PRing discoverable and well known places, and also encourage narrowly scoped entry-level reviewer “positions” on topics of their interest and expertise. — divide and conquer!
@timokau When combined with github’s own notification system, wouldn’t that lift the need for (maintaining and promoting) marvin?
Is this an RFC-worthy proposal?
Wouldn’t that encourage contributors to ‘pressure’ maintainers for reviews? I’m not sure that’s healthy. I have some pretty old PR’s that I’m definitely still serious about, but on the other hand I don’t want to burn out the maintainers by nagging them…
I like that idea - we can get partly there today by simply encouraging non-maintainers to test and review PR’s in fields they are interested in (even though they won’t be able to merge).
Also not a fan of this idea. Open source work should not be made any more stressful than it already is, for both parties. People are volunteering their time, we should try to be respectful of that. The proposal doesn’t sound very welcoming to new contributers, I’m not sure I would ever have gotten involved in the project if that had been the process at the time.
I don’t think it does. It does not distinguish between PRs that are blocked by the author vs PRs that are blocked by review. It does not check up on PRs gone stale, finding a new reviewer. It doesn’t give the reviewer control over the volume of PRs they will have to review.
I’d happily be proven wrong though, if your proposal works better I certainly wouldn’t mind giving up the additional responsibility 
Well (temporarily) stale PRs, even if closed are still PRs and one can happily be serious about them. But at the very least they do not add up to marginal complexity towards to the set of non-stale “LastMile/LastMeter” PRs.
The dynamic usually is as follows:
needs-reviewer). Riviers get notified accordingly and semantically rich directly through github.Argument 1 alleviated. 
If there is exactly one team “responsible” of reviewing a particular subfolder, they are all pinged by github. Anyone can approve or request changes. There can be a policy for a merge (eg. two approvals). This policy can even be enforced directly through githib on protecred branches. If non of the “responsible” reviewers get’s to review an assigned PR, that’s an inherent problem with this particular team that no bot can ever solve. A stalebot would just put in place the right incentives for the contributor to escalate the situation, for example here in this forum. (Stalebots can be made very friendly and can always be blocked).
Argument 2 alleviated
I’m not sure if this function will actually be properly working. A lot of people will have time one week but no time for three weeks in a row, and it should be pretty unpredictable how much time each one can afford to review. With sufficient division of labor (in this scenario: folders!), Github would suggest some PRs for review which are guaranteed to be in your area of interest and where you can pick as you like.
Argument 3 also alleviated?
I strongly feel, if not absolve, this would largely simplify marvin and make it a friendly nudger (as a stalebot subsitute) — if that promotes effectiveness.
Unfortunately, I think it is not very realistic for this UX to have any effect at scale. 
It is similar to what @timokau suggest with delegation in marvin’s documentation. But delegation can never unfold the same levels of engagement as opt-in/opt-out.
I was the stalebot here:
https://github.com/NixOS/nixpkgs/pull/83630#issuecomment-705759095
In a stalebot scenario I would have written:
/stalebot unstale re-open
... explanation ...
I don’t have time/energy to argue this in detail right now (and its a bit off-topic for this thread anyway), but we mainly seem to differ on how much work/expectations we want to put on PR authors. I don’t think its reasonable to expect them to move their PR forward on their own, especially if its one that is not “sexy” to review. It can be draining, it can feel wrong to ping someone over and over.
But again, I don’t mean to discourage you. Might be that you are right, and I would gladly be proven wrong if you want to implement such a system.
Your explanation (in terms of backlog size in months) is already sufficient, thanks for that.
Another threshold to contributing (at least for me) is that I’d like to contribute ‘small’ stuff without becoming a true ‘developer’. Sometimes I create simple default.nix to package something this is not yet in nixpkgs, and I would like ‘give back’ to the community by sharing it, but without creating a PR (with a Github account I don’t have because I’m not a dev) and becoming an official maintainer.
Sometimes I post the code on reddit (in the public domain) and hopefully someone else can use it.
It could be that the Nix community does not favor ‘contributer light’ style contributions (because I don’t commit to creating a PR every time there is a new upstream version), that’s also fine, then I’ll just continue posting code on reddit.
You could make your own NUR repo to make your packages findable.
Maybe flakes is another option, but I don’t know much about that yet.
NUR: GitHub - nix-community/NUR: Nix User Repository: User contributed nix packages [maintainer=@Mic92]
I consider myself a ‘casual contributor’, and my impression is that nixpkgs can benefit from those a lot.
To be honest if you’re comfortable writing derivations I would consider you ‘a dev’ and encourage you to create a github account. Of course there can be other reasons you might not want to. I think it’d be nice to accommodate such would-be contributors, i.e. by allowing them to upload/push their patches elsewhere and looking for a ‘sponsor’ to forward them to github. But that’s getting way off-topic.
I don’t think listing yourself as maintainer comes with such a commitment - I see plenty of maintainers that don’t appear to be very active, and while it’d be good to clean those up at some point so other contributors know what to expect, I personally don’t mind.
It might be helpful if we write down somewhere what it means for us to list someone as ‘maintainer’, and make clear what you’re signing up for when you add yourself as such?
If I see a <package>: fix <foo> PR, I will usually prioritize those over package additions and bumps.
Just having users tracking unstable and reporting or fixing issues is extremely beneficial. You don’t “have” to do a deep dive into maintainer-ship if you don’t want to.
Might have a relatively small impact to the root causes discussed here, but it might bring some educational benefit slowly over time …
https://github.com/NixOS/rfcs/pull/77
Also, this might be appreciated:
I’m somewhat in the same boat as user:kvtb. So if I might give an unsolicited suggestion, repeating user:cdepillabout’s points in the dictatorship thread-
I sense that there is
emphasis on perfection. Take
fcitx: Add test (Unicode input, table input, m17n) by asdf8dfafjk · Pull Request #96371 · NixOS/nixpkgs · GitHub
I spent at least 15 hours writing a robust test (I was planning on writing tests for multiple software so figured investment would be worth it) discussed on discourse with no help, nor pointer on what the absolute perfect way was, then decided to follow the route of other tests and then finally someone comes and says no this isn’t absolutely perfect.
easy for reviewers to mention something that is a problem but not say- I will merge after this. I’ve had, eg, the onedrive PR where I only received negative comments. The point of contention in that PR was that onedrive doesn’t belong to nixpkgs but all other sync services do solely because I added a way for users to control their own instances without touching a .nix file. Even that is fine so long as it doesn’t take the third reviewer to point this out while I faithfully spend time to address comments from first two.
Finally @peterhoeg, (who by his own admission on discourse, ignore nitpicks so long as general PRs are okay, .) who still didn’t agree with my approach over IM merged it with the comment- it doesn’t make things worse, and adds a feature. Simple.
IMHO, a project on GitHub should follow simple guidelines, does this commit improve things or maintains status quo on all dimensions:
package and related packages working: will the package work better?
code quality : spahgetti code with no clear architecture. Negative. Indentation mix? Unreadable and mildly negative. Extra whitespace at line end though… seriously? It’s an automated test now that fails blocking PR.
documentation: currently documentation says do a to achieve x, commit changes a to b , then the PR needs documentation changes to proceed. If no documentation exists already then it’s fine to not add it.
Maintenability: commit message not in the exact format (makes hard for tools to guess what’s upgraded). But there should be concrete points on a good/bad spectrum.
Automated testing.
Just like there are guidelines for contributors perhaps there should be reviewer guidelines too?
What not to do:
You raise a number of valid points. Thanks for sharing them. I think a written set of guidelines for comitters would be valuable in addressing your feedback, as you suggest.
You raise a number of valid points. Unfortunately, there’s no set requirements yet about acceptable criteria in a PR. There’s the RFC for defining a PR workflow, however, I think that suffered from trying to be too opinionated about the implementation and failed to be ratified. There was also a previous issue How to ease/improve PR reviewing process · Issue #11166 · NixOS/nixpkgs · GitHub .
In our current process, communicating standards through PR reviews doesn’t really scale well, it takes a lot of time scan the changes, type a response, then iterate. This time investment often disallows me from getting to PRs which may be in a “ready-to-merge” state, I just didn’t have the free time to get around to them (I currently have 300 github notifications, and get 20-120 a day).
To help scale with community growth, I started making some videos:
I received some new recording gear, when I have some free time and the desire to record again, I’ll probably make more “polished” videos. Having the keyboard clack in the background is very distracting. Also having to type + think + talk isn’t the easiest thing todo, so I’ll probably change it so that I do the final voice edit after the screencast has been recorded.
But seeing as some of the videos have 800+ views, I’m assuming that some people find the scenario-specific videos valuable. And maybe having some polished: ‘Getting started’, ‘Using NixOS’, ‘Using nixpkgs’, ‘Contributing to Nixpkgs’, ‘How to do <language> packaging in Nix’. Would go a long way for people to “learn” about the best practices. If they are of sufficient quality, maybe we can make them semi-official at least make a reference to them from the official docs.
Documentation and resources scale well, however, NixOS/Nixpkgs documentation suffers from three different issues: discoverability, relevance, and death-by-details.
Discoverability: I didn’t even know that Nixpkgs had it’s own manual til after I became a committer. There’s https://github.com/nix-community/awesome-nix which is helpful, but I only new of it after i was added to the NixOS organization and had a PR opened against it.
Relevance: Most ecosystems have a nice “system of effects” when people have issues, there’s usually some stack-overlow, blog posts, or similar issues in github. Generally all I find are github issues, and hopefully this will be less of an issue in the future.
Death-by-details: We generally send people over to nix-pills to get their feet wet with nixpkgs. However, nix-pills goes through the process of essentially creating a stdenv which is way more than someone probably cares for if they are coming from a, “read an article about nixpkgs and just wanted to test drive it in this repo of mine”. It reminds of trying to learn haskell, where I just wanted to know how to “read from stdin”, but found myself hours later reading about Monads and category theory. I just wanted to read in a number.
EDIT: the revamp to the homepage I think helped with the discoverability. There’s now a “Learn” tab on https://nixos.org/
I’ve created this topic for casual contributors, hopefully it helps in being able to contribute lightweight style (which is already much more than not being able to contribute at all)