# My experience of contributing to Nixpkgs
**URL:** https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660
**Category:** Meta
**Created:** [June 29, 2026, 8:03pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660 "2026-06-29T20:03:58Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@some](https://discourse.nixos.org/u/some)
#### Post date: [June 29, 2026, 8:03pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/1 "2026-06-29T20:03:59Z")
Nixpkgs is an interesting beast. It is massive and sprawling. The barrier to entry to contributing is quite low compared to many distros, just open a PR on GitHub. I drive multiple NixOS machines every day at work and home. I also contribute to Nixpkgs quite frequently. I review PRs, add packages, clean packages up, remove packages, add new tooling, and so on. Nearly every day.
The experience of contributing to Nixpkgs is probably most like Sisyphus pushing his boulder. Once you open a PR, it is up to you to get anyone to look at it. Beg. Plead. Bargain. Scream. I don’t know. Getting anyone to even glance at a PR is a task that is the first hurdle. And it is truly one of the hardest.
Nixpkgs has zero systems for ensuring anyone actually looks at PRs, nor any incentives at all to do even do so. If someone does it is because of luck, your PR is an “easy one”, or because it aligns with someone else’s goals. There are about 5 people who regularly look at PRs from the unwashed masses. Sandro is the most obvious one, and most likely one to look at a given PR. It is truly thankless work.
There are several issues with this.
1. Very few people actually look at PRs, this is quite obvious if you’ve spent time here. “Very few” is relative to the number of maintainers.
2. If a PR is not an “easy one”, good luck getting nearly anyone to look at it. Easy is: updating a version & hash, or adding a new package. If you add a new Nix function, modify one, touch any Bash GOOD LUCK.
I have experienced this many times. You just have to beg, and beg, and beg, and beg, and beg, and beg, and beg, and beg, and beg, and beg, and beg for someone to look at your PR. For months, or even years! Then someone will come along, say “you misspelled the word ‘attribute’,” or “that doesn’t match how I would do it,“ and there it is. Your review. Nothing of substance said about the content.
Ok so you begged for a few months, and someone reviewed your PR. Congrats. What’s next? Well next is getting it merged. This is the other barrier. Nixpkgs has this funny system where the final say on a PR is often up to “committers.” This is a group of people whom have been deemed “the best of Nixpkgs maintainers.” And are allowed to dictate what goes in. I hope you haven’t gotten tired of begging. Get on your knees and make sure they hear you! If a committer requests a change, good luck getting it merged. The nominal policy is “no reviews are blocking reviews,” but I’ve not seen a single instance where that was followed.
Committers are an in-group that get to decide which nitpick you get today. “Your function name is not what I would’ve written,” “I think there’s a better way to do this [I will not tell you].” And also you get a single review every few weeks. That addresses one thing. Then another review about a completely separate thing the next month. Why not all at once? Well committers are too busy to interact with you. Or something. I’m sure it’s important. I do recommend looking at what the average committer actually does, it is quite interesting. The best way to get their attention is to do something with their pet project. But almost many of them just self-merge their own PRs and not much else. Maybe merge a fellow maintainer’s PR on a package they maintain. A large amount of Nixpkgs processes are contingent upon committers actually looking at PRs, yet it is very similar to pulling fingernails to actually get that to happen. If you were to ask me how many committers there were, I would guess like 30-50. Instead there’s over 200. What are they doing? I’m sure its too important to give time to look at the PRs people have written. Or at least I hope it is, since that is what they have shown is the case, regardless of what is said.
This is not necessarily their fault, as annoying as it is. Nixpkgs is a volunteer project and you cannot force people to do so. But there is also negative incentive for any other above to occur. Why review anything when you can just not? Why merge anything when you can just not? There’s absolutely no reason some Jane Commit should every look at anyones’ PR. In fact it sounds quite annoying to do so when she has been at work all day. Luckily to keep her commit bit all she has to do is merge one PR a year. So she merges an update for a tool she uses at work. “Great, I did my part for the year. See you next.”
Taking a good look at projects that are quite nice to contribute to, what do they do? They have accountability and responsibility for PRs. Nixpkgs already has some in terms of `meta.maintainers`. How to make someone feel accountable or responsible for PRs from the peanut gallery? Take a good look at the Rust Project.
And then there’s just the attitude. I’m not going to call the moderators every time someone is rude to me, that’s a waste of everyone’s time. But wow. I spent hours building something to try and make a process easier. But sorry for wasting your time for asking you to look at it.
Overall I really want to help Nixpkgs. I think it’s a really cool project. But what is the point of doing anything for Nixpkgs if it is just a stalled PR generator. “Oops your PR went over the limit, and is now deemed to be too hard since I cannot click on it, scan it, and say ‘well that looks right.’ You are now sentenced to six months of begging.” What a nice experience I really wish everyone had the chance to live it.
---
### Author:  [@fzakaria](https://discourse.nixos.org/u/fzakaria)
#### Post date: [June 29, 2026, 9:21pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/2 "2026-06-29T21:21:00Z")
I share your pain in [docs: add AGENTS.md and symlink CLAUDE.md by fzakaria · Pull Request #534657 · NixOS/nixpkgs · GitHub](https://github.com/NixOS/nixpkgs/pull/534657)
1 new file to just ask AI agents to read `CONTRIBUTING.md`.
No changes to the file otherwise to [bike-shed](https://en.wikipedia.org/wiki/Law_of_triviality) about… and yet impossible to merge 🙃
Such is life.
---
### Author:  [@niklaskorz](https://discourse.nixos.org/u/niklaskorz)
#### Post date: [June 29, 2026, 9:26pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/3 "2026-06-29T21:26:27Z")
I’m hoping to write a more thorough reply tomorrow, but I’d kindly ask to refrain from hijacking this topic for the ongoing AI push. This has its own topics already, no need to continue here.
---
### Author:  [@domenkozar](https://discourse.nixos.org/u/domenkozar)
#### Post date: [June 29, 2026, 9:27pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/4 "2026-06-29T21:27:07Z")
Thanks for writing this up. I agree with the points raised here.
My commit bit was removed after around 10+ years of contributing, and now I often have to plead to get things merged even for packages I maintain. That has made the problem much more visible to me: without a clear path from “this PR is ready” to “this PR can be merged,” contributors end up depending on personal attention, persistence, and luck.
For what it’s worth, I also tried raising this with the Steering Committee, but I have not received an answer after a year.
I think a lot of this could be improved with better automation and, these days, AI-assisted tooling: triage, stale-state detection, reviewer routing, summarizing PRs, identifying likely maintainers, detecting whether feedback is blocking or optional, and helping move ready PRs forward. But too often review is used to police contributors rather than to reduce gatekeeping and help contributions land.
At the scale of Nixpkgs, I don’t think the current model can keep working. We need a new contribution model. Something closer in spirit to the Linux kernel, where ownership, review responsibility, subsystem boundaries, and escalation paths are clearer. Nixpkgs is too large to keep relying on contributors manually begging the right people until something happens.
---
### Author:  [@some](https://discourse.nixos.org/u/some)
#### Post date: [June 29, 2026, 9:36pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/5 "2026-06-29T21:36:04Z")
LLM contributions only make the problem worse. Now there’s a sea of PRs that were not ever written or tested by a human, and you must filter them out. Being asked to review LLM PRs is honestly exhausting. Why should I read a PR that the author couldn’t be bothered to write.
Rather than adding more LLM noise, making the contribution docs better is extremely higher value. And if LLMs are so good at what it is claimed they do, this would elevate them the same.
---
### Author:  [@rhendric](https://discourse.nixos.org/u/rhendric)
#### Post date: [June 29, 2026, 10:21pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/6 "2026-06-29T22:21:42Z")
> [@some](#):
>
> I have experienced this many times. You just have to beg, and beg, and beg, and beg, and beg, and beg, and beg, and beg, and beg, and beg, and beg for someone to look at your PR. For months, or even years!
This whole thing would be easier to take as constructive feedback if it were less hyperbolic. I’ve had a look at your PR history (I will respect your desire to make anonymous complaints in public, but I’m pretty sure I know the account you’ve been using on GitHub). Your longest-open PR was about 11 months (you closed it yourself). So unless there’s some glitch in the data (possible!), you’ve never had the experience of begging for ‘even years’.
I then tried to look for instances of repeated begging, and couldn’t find too much of that either. How are you doing this? You’re not posting on the Discourse thread (not that this is all that effective, given how people use it; but at least it’d explain to me where this is coming from). Your typical PR consists of you pinging a maintainer once or twice (by which I mean requesting a review or @-mentioning someone) before you get what you need (a review or a merge) or quit.
I think the thing you’re pointing at is worth discussing, but we should be discussing it at the scale at which it actually happens. I understand venting frustration with hyperbole but it makes it much harder to look at the situation and make reasoned decisions about what to do differently.
---
### Author:  [@coolcuber](https://discourse.nixos.org/u/coolcuber)
#### Post date: [June 29, 2026, 10:28pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/7 "2026-06-29T22:28:26Z")
To an extent, I hear where you’re coming from, but I think that this is an especially cynical take on the nixpkgs system. To go over a few points:
- It’s hard to get anyone to look at “hard” PRs
- Getting merges is hard
- Committers are an in-group prone to nitpicking
- Accountability
- Attitude
I don’t want to come across as an apologist here. I appreciate that you’re taking the time to note that we all have lives outside of Nixpkgs, and I think that’s probably a driving force for a lot of the issues we’re discussing. It also sounds like you have a good bit more experience as a contributor than I do, which is worth noting. I hope I haven’t misinterpreted any of your points.
---
### Author:  [@crertel](https://discourse.nixos.org/u/crertel)
#### Post date: [June 29, 2026, 11:14pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/8 "2026-06-29T23:14:11Z")
Thank you @some for your feedback–it’s something I think a lot of us go through to one degree or another.
The current solutions (such as they are) seem to be:
- Open a PR and hope for the best
- Open a PR and use the [PR thread](https://discourse.nixos.org/t/prs-ready-for-review/3032/6850)
- Open a PR and find a sympathetic person (the clique thing you mentioned) to continually route through
- Use a flake (imperfect as they are) and just don’t mention it (I suspect this is the _de facto_ most common answer for unpackaged stuff).
I agree that this is not an ideal situation.
Things we could consider to improve the situation:
- Find some way of having a review queue or tooling for “I have a few minutes, grab me something I can review”
- Find some way to increase the number of folks with a commit bit (the bar is a bit high right now and we’ve lost/ejected folks who previously were helpful in this regard)
- Open up yet another channel that’s “untrusted” or “optimistic” or whatever that proactively merges with a passing review (and then figure out how to promote PRs and figure out CI load and whatnot)
- Revisit our processes so that signing off isn’t such a burden for folks with a commit bit
We are going to need to find a way of helping solve this as we continue growing.
---
### Author:  [@coolcuber](https://discourse.nixos.org/u/coolcuber)
#### Post date: [June 29, 2026, 11:23pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/9 "2026-06-29T23:23:40Z")
To be fair, I think that you just tripped over a hornet’s nest with this one. The only thing regarding gen-AI this community can agree on is that it’s controversial. Every discussion on this topic seems to quickly become heated. 99% of PRs aren’t going to get even 1% of that much heat.
---
### Author:  [@crertel](https://discourse.nixos.org/u/crertel)
#### Post date: [June 29, 2026, 11:26pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/10 "2026-06-29T23:26:48Z")
You do raise an excellent additional opportunity for improvement: people could be fixing the PR backlog instead of arguing about AI on Discourse.
---
### Author:  [@fzakaria](https://discourse.nixos.org/u/fzakaria)
#### Post date: [June 29, 2026, 11:39pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/11 "2026-06-29T23:39:16Z")
I always try to keep in mind “what type of door” am I discussing
> Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.
reference: [https://s2.q4cdn.com/299287126/files/doc\_financials/annual/2015-Letter-to-Shareholders.PDF](https://s2.q4cdn.com/299287126/files/doc_financials/annual/2015-Letter-to-Shareholders.PDF)
My own opinion: There is often _too much_ discussion about two-way doors within the community.
We put too much burden on ourselves to try and have the best & correct approach the first time, when often that’s not necessary and causes lots of the pain we’ve documented here.
---
### Author:  [@tbaldwin-dev](https://discourse.nixos.org/u/tbaldwin-dev)
#### Post date: [June 30, 2026, 5:59am UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/12 "2026-06-30T05:59:28Z")
> [@fzakaria](#):
>
> I always try to keep in mind “what type of door” am I discussing
I like this perspective on the issue. Trying not to pull the conversation too far off topic; but, I feel like the nix community has felt flakes were a one-way door that has forever changed the ecosystem in an irreversible way. Regardless of my personal options on the feature, it has very much divided the community and caused lots of discussion because of the feature‘s incompleteness. The community as a whole doesn’t every want a repeat of that so I feel like we are very adverse to making quick decisions to our own detriment.
Coming back to the main topic, I have also struggled with the PR system. It normally takes going to the matrix channel and pinging it after a PR has sat for a week before it gets any activity. The core maintainers have an immense amount of work and it is understandable that it takes a while to get around to PRs; however, I would propose an escalation approach to PRs if it is possible. Something like if a PR has 1-2 reviews it’s prioritized at level 1 3-5 level 2 and so on. This would encourage people to review the packages they want merged to help boost their priority. It gets more eyeballs per PR and hopefully fast tracks features people want.
---
### Author:  [@truh](https://discourse.nixos.org/u/truh)
#### Post date: [June 30, 2026, 12:42pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/13 "2026-06-30T12:42:54Z")
I mean the downside of this is that this incentivises people to approve PRs without having done any diligence.
It risks PR approval becomming the new commenting +1.
Not that I fundamentally disagree, doing an approving review as someone without commit bit feels kinda pointless sometimes.
---
### Author:  [@numinit](https://discourse.nixos.org/u/numinit)
#### Post date: [June 30, 2026, 1:05pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/14 "2026-06-30T13:05:36Z")
> [@crertel](#):
>
> Find some way of having a review queue or tooling for “I have a few minutes, grab me something I can review”
Not even joking with the idea that we ought to add a `nixpkgs-review roulette` command that just gives you a random recent PR to review
---
### Author:  [@truh](https://discourse.nixos.org/u/truh)
#### Post date: [June 30, 2026, 1:06pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/15 "2026-06-30T13:06:32Z")
> [@fzakaria](#):
>
> There is often _too much_ discussion about two-way doors within the community.
Your PR got overwhelmingly rejected and you view that as a discussion to win. That’s very different from some’s experience of many contributions struggling to get attention.
---
### Author:  [@numinit](https://discourse.nixos.org/u/numinit)
#### Post date: [June 30, 2026, 1:09pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/16 "2026-06-30T13:09:09Z")
> [@truh](#):
>
> Your PR got overwhelmingly rejected and you view that as a discussion to win.
This is an incredibly unkind assumption to make.
---
### Author:  [@Ma27](https://discourse.nixos.org/u/Ma27)
#### Post date: [June 30, 2026, 6:38pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/17 "2026-06-30T18:38:06Z")
Don’t you see the irony of suggesting to not argue in discourse all day (or y’know proposing to have meritocracy in nixpkgs) while maintaining 9 packages?
Don’t get me wrong, I do not judge people by their workload, but this is a weird position to be in making claims like that.
---
### Author:  [@marijan](https://discourse.nixos.org/u/marijan)
#### Post date: [June 30, 2026, 6:45pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/18 "2026-06-30T18:45:51Z")
@some you have a valid point, we should all be respectful with the time of each other. But you cannot presume that every AI assisted contribution was never reviewed. We need to improve the process! On my end, assisted with AI or not, I always try to structure a change in a way that people can follow it, I try to put myself into the shoes of someone reviewing it….
---
### Author:  [@nadir](https://discourse.nixos.org/u/nadir)
#### Post date: [June 30, 2026, 8:20pm UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/19 "2026-06-30T20:20:08Z")
Would you say that you meet that standard?
---
### Author:  [@Borgvall](https://discourse.nixos.org/u/Borgvall)
#### Post date: [July 1, 2026, 4:59am UTC](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660/20 "2026-07-01T04:59:19Z")
In my opinion, we need some better tooling, that helps to ping relevant persons, when a pull request has been made. Who appropriate people are, is up to debate but some incomplete ideas are:
- Maintainers of touched modules/packages
- Owners of touched files
- Maybe people, who touched the same files multiple times in the last year or so.
Maybe have a look at this [discussion](https://discourse.nixos.org/t/how-to-find-the-maintainers-of-a-module/78626/5).
To be honest, I don’t know how feasible such a tool would be and if GitHub’s API is flexible enough.
There is still the issue to find a committer.
[Next page](https://discourse.nixos.org/t/my-experience-of-contributing-to-nixpkgs/78660.md?page=2)