This is not my personal experience (or rather, it was, but it isn’t anymore), but there’s still an issue I’d really like to highlight as someone who interacts with new contributors quite a bit: people (and changes) often get stuck because we don’t really have an answer for “I made a PR, now what”. Sure, there’s the “PRs ready for review” thread, and there’s random Matrix pings, but neither of those work particularly well for getting the attention of the right people (and in many cases it’s unclear who the Right People even are). I’m not sure what the way out is, but it might be workgroups?
21 Likes
This has been my experience too, and it’s the main reason I stopped caring to contribute back to nixpkgs. Instead, I create my own flakes and share them on my personal repositories, which is sad.
Automation is much needed, so that if you get at least two approvals from maintainers (not exactly people with merge rights), the PR should be automatically merged. But then again, to even try to contribute automation, one would have to deal with a much larger process.
3 Likes
I maintain several leaf packages, and for most of them I’m the only maintainer.
These are some of my experiences. Apologies if this seems a bit ranty, but it can be really frustrating at times.
Outside of r-ryantm updates (which are usually approved relatively quickly), it’s a journey and a half to get an update through.
Sure, I can submit an update PR, test it, etc. But then it sits there for weeks/months because almost no one will look at a package they don’t know about or use (This is just human nature - I’m not accusing or blaming anyone, but it can get annoying).
In the meantime, I’m sitting here wondering if I give up and push the update to my personal flake repo and be done with it, or if I keep going.
Posting in the “PRs ready for review”/“PRs already reviewed” threads sometimes helps, but that usually leads to bikeshedding and/or nitpicking.
Some people are worse offenders than others. So much so, that there’s some people whom I actually dread leaving a review.
Some suggestions:
-
If you’re not going to bother looking at a PR properly, don’t look at it at all. You’re just wasting both of our valuable time. Neither of us are getting paid for this, after all.
-
If you make a suggestion, and I respond with “no, that won’t work because <reasons>”, then leave some indication that you agree/disagree.
Even just a
is fine. Hopefully if you disagree, you’ll explain why.
Otherwise, I’m just left here in the same predicament, except this time with the additional chance that you’ll block the PR. -
Don’t insist on blocking a package update because of something trivial, e.g. a minor formatting issue - get the update through first so people can start using it sooner.
A formatting fix can always be submitted after-the-fact. -
Reviewer/committer time and attention is scarce-enough as it is. Is it really worth doing another lengthy and painful review cycle for a missing blank line?
-
Enforce consistency with automation and tooling, and have ofborg check it. A classic example of this is to enforce formatting with
nixpkgs-fmt. This would nip entire classes of bikeshedding in the bud. -
Have r-ryantm email maintainers if a package update fails. A recent example - this would have been useful for
rpcs3. The update script broke because they upgraded to Qt6, and the derivation was only using Qt5. It was a trivial fix, but it took ages to be discovered because I’m not constantly polling for rpcs3 updates.
Thank you for coming to my TEDx talk.
25 Likes
These are really sane points you make, @vs49688 ! And not only relevant to Nix. So, um… can I quote you in my workplace? Other than the particular names of maintainers or tools, this is good counsel for so many software development groups!
1 Like
Sure, if it helps. Please do!
2 Likes
The splintering of a busy project (and also some local ego maxima, for sure) makes it hard to discern where to consolidate and combine resources (or argue/convince for consolidation to others).
As a result, it feels to be a hero driven project (call it a side effect of meritocracy). No individual contributor (as opposed to an organized group of people; e.g. company) can sustain that without going mad at some point, eventually.
I’ve tried the front-running with my own projects because I didn’t, at the time, find something jointly beautiful that seemed like falling into place just right and needing contribution of my strengths. Now why’s that? I don’t know.
3 Likes
Quite a lot of package update failures happen every day; I could see this getting unpleasantly noisy for people who maintain a lot of packages (either directly or via teams).
But it might be worth doing in some form. If r-ryantm encounters an unexpected error (nixpkgs-update already has several lists of packages it knows are borked) trying to update a package you maintain…
- You would like to be mentioned in a GitHub issue
- You would like a direct e-mail
- You would like to be notified via some other mechanism
- You would only want to be notified if some specific condition is met (and you will comment further)
- You would prefer the status quo over being notified
0 voters
1 Like
Drafting an RFC for nixos (THE cli) and almost getting stuck on every other word for fear of triggering someone for something into a controversy (heck, am I supposed to be a Cicero in rethorics?!?) that would stall the entire undertaking. Discouraged and tired, I’m asking myself: Is it really worth it or should I rather go sledging with the kids?
3 Likes
For me, motivation to participate has gone down quite a bit.
This is mostly regarding contributions toward Nix itself. I think Nix has many UX problems, which are ‘a thousand paper cuts’ for new users. Fixing these require many tiny PRs. Getting maintainers to look at those PRs takes a lot of effort. The feedback loop is weeks/months instead of days, while still needing to find creative ways to get another review iteration.
There are other issues, like the codebase sometimes being confusing, lack of tests or just the lack of familiarity with C++, but all of these problems can be plowed through. The reviewing workflow is what takes up exponential more time.
Regarding nixpkgs and maintaining packages, I have experience that eventually PRs will get reviewed and merged. It sometimes just takes a while. If I want to speed this up, I found the PR threads of discourse helpful and got very quick feedback every time.
14 Likes
Lack of stewardship/leadership in infrastructure & documentation around NixOS deter me. There is a hard-working doc team, and then people randomly come and say “hey I’ve created this new website here where I’m hosting yet another wiki/beginner’s tutorial/…”. Companies come and create 3rd party flake repos, and other stuff, without community consultation. Sometimes it seems like some companies and some individuals see the project as a big pile on which everyone can just throw their latest addition. I know some of them mean well, but I’d rather have coordination and ownership instead of uncontrolled growth.
9 Likes
I’am not sure if this label exists for pull requests but i think it’s a good idea to have a label like simple-version-bump and it’ll be defined as only changing version and hash attrs (also src if needed) in pull request. so the committers can easly see this label and check
- if ofbot checks are passed
- if label was correctly given and pull request fulfills the definition (only version and hash changed)
- optionally and for more confidence if it’s by maintainer or approved by maintainer
then in many cases they can commit
3 Likes
Technically, Nixpkgs is one of the most exciting things I encountered lately, making me motivated to dive into it and contribute. Still, there is one thing that deters me: There is more and more, and increasingly aggressive pressure to make everything GitHub-only. In the beginning, it appealed to me that (at least according to maintainers/maintainer-list.nix) you are free to provide whatever means of communication you prefer, be it E-Mail, Matrix or GitHub. Everyone communicates differently, after all, and it seems reasonable to make contribution attractive for everyone based on their technical skills, not based on their willingness to accept whatever platform seems trendy right now. Still, quite some developers don’t tolerate it if you want to keep GitHub communication to a minimum. This puts me on a strain personally, and I also don’t think it will benefit the NixOS ecosystem to make itself even more dependent on GitHub.
6 Likes
Ey’o! First time poster, long-time Matrix chat enjoyer. Thought I’d weigh in a little bit.
For me, you can’t discuss accessibility without also including usability. The first level of accessibility are things for people who are physically impaired, partly blind, or deaf. But when it comes to like most people, usability is utmost important to sort of “smooth out the ride” so to speak. For some people who are neurodivergent, with learning disabilities (such as yours truly), usability is a godsend. It helps when the applications or the services you use have a focus on UX. It’s a bit sad then that in most cases UX is sort of employed unethically, what with dark design patterns and all that.
Where am I going with this? I think pretty much everyone and their grandma knows that the nix/nixpkgs/nixos documentation has to be made simpler and more clear, because they are quite complex systems and grasping them is sort of like a journey off it’s own. The learning curve isn’t exactly short. For me, things like nixos-options shows what’s functionally working and wish nix options would make it more functional with flakes.
Also, flakes. Why hasn’t it been deemed stable yet? I don’t think I can find consensus on the Matrix chat regarding wether or not they should be used, but everyone is using them. There’s some real cognitive dissonance there in regards to what you should do. You could call it “conflicting messages” and it can be super frustrating.
I think clarity and tooling where UX is concerned is the issue. I’ve definetely been thinking of how to “traverse” nixpkgs lately, mostly by going on github and reading the declarations there, and I haven’t completely gotten the flow of doing it CLI wise. Things like inspecting dependency graphs, getting a grasp over profiles, systems, general clojures, dependencies. Everything’s a bit disjointed.
I kind of like the idea of something like nix-gui/nix-gui. A simple GUI tool that gives you access to the rather large set of options and packages available. I wonder if there’s a better way to visually represent nixpkgs and the nix store, systems and profiles. I could at the very least imagine some sort of web portal for nixpkgs, that contextualizes the repo from the perspective of somebody who’s either going to contribute or just check out how the sausage is made from a more nixified perspective. Github is great and all, GUI wise, I mean it’s github. But when dealing with complex systems like this I always feel like custom GUI tools seem like a good ticket.
I’m still learning, and there’s a whole lot to grasp. I just wish it was easier and less confusing, and I wish the tools available were a little more intuitive, a littler easier and a little more “show, don’t tell” - if that makes any sense.
3 Likes
Of course, for people like me, it’s exactly the UX work being done that is the problem — old CLI has better layering, new CLI is only being improved in that respect now and probably will end up still a bit worse (not that the old one did not have space for improvement)…
The old state of Nix and docs allowed to read as a formal if not always accessible document and reason from the low level down, now there is too much orientation to the expected use case without any thought to unexpected ones, and consistency ends up added as a bolt-on now. That’s even without touching flakes, which I expect to be stuck forever as a framework and never a tool.
1 Like
Id love to find a way to help out but I don’t know where to be of value.
Im pretty new to nixOS (just under a year at this point) - dont see myself jumping to another distro. With that in mind I dont use flakes or any of the newer - sexier tooling people are raving about.
But as just a boring user - I’d love to know where I could help
I am a newbie to nix(os) but a long time open source folk.
What I found for me personally:
- When there is a problem with a package - where is a good place to discuss it? Email the maintainers? write on discourse? open a ticket? As a newbie it’s just not clear.
- Even as seasoned OSS contributor the CONTRIBUTING.md is frightening. It does not make helping easy. It would be good to have a more streamlined version that runs through a concrete change and then branches out for details.
- The documentation is … well, some areas need some serious love. It seems to be heavy on the theoretical and lacking in the practical side of things. Arch seems to set the bar high.
- For the docs it would be good to provide entry points for people knowing e.g. puppet and ansible and see how that knowledge can be translated.
- The “How nix works” needs a lot more detail. It barely mentions “derivation”.
- The duality of flakes and not flakes is utterly frustrating. Could the community just get over it (whatever it is) and define the path forward?
- I have had help from some very kind and patient individuals
but some corners of this community are dark. In some areas there is a strong combination of talking over ones head and survivor ship bias. It’s when an answers is more to show that they know more than you do, rather than helping. This is of course nothing new in communities - but I see a strong dark loom in some areas in nixos land. It took a while to find the right places to ask. It would be good to steer newbies to the good places. - The flexibility of nix is obvious - but some more guidance on good practises would be nice. People: “Yeah, I searched on github for
flake.nixto look at dozens of examples to figure things out. Then I got told it’s not good - but it seems to work.” That’s not great. And I imitated the very same thing.
It think Nix(OS) is an incredible project and effort. It gets me excited. But it seems like it has still a long way to go to reach more people. I would love to use it more in a professional setting, but I am not sure I dare at this stage (as in: my knowledge and the possibility to get help quickly)
8 Likes
One thing that I regularly observe is how inaccessible this entire project is to outsiders. I have brought many people to the project so far, and regularly notice how utterly helpless they would be without the guidance of a person which is already in the community. But also thinking back a couple of years ago to when I started, I would never be where I am now without all those skilled people doing Nix all around me.
I could blame this on documentation, or the tooling, or the ecosystem, but what I see is that the entry to Nix is simply a very bumpy road on all levels. A lot of gotchas and tricks to know, really a lot of them. And sure, figuring them out alone is possible, but it’s a lot more tedious, and I’d bet a lot of people give up on that path (we’ll mostly never hear from them). It’s like, half an hour of frustration and trying stuff out vs being told “just do X” by someone who already experienced that issue and it’ll work second try. And this on every single gotcha.
7 Likes
An addition prompted by recent events: It’s also highly discouraging to have community guidelines on the one side, and on the other side users with commit privileges who happily ignore them and even refuse to rectify what they did when they are made aware of how their commits directly contradicted community guidelines. I think this makes the NixOS community look very unprofessional, and scares away contributors. In my opinion, if we have these guidelines, we should make sure to only grant repository write access to those willing to act according to them.
2 Likes
For context: My Nix skill level is probably “intermediate”. I’m able to (and do) make some contributions. I write a few tutorials, and a small free book, and I do PRs for one or two packages.
If the basic functions were well-documented, explaining in detail what they do, what parameters they take, and so on, then people like me could contribute documentation for higher-level functions. For example, if callCabal2Nix and the standard version of mkDerivation were fully documented, then I could probably figure out the Haskell version of mkDerivation and developPackage do, and contribute some draft documentation for those functions. Others could do the same for the functions used by their language of choice. In this way we could improve the core documentation.
The other challenge I face, and it’s not something that can easily be solved, is that the type system of the Nix language is so limited. It’s often unclear what a function expects as input and what it returns. By contrast, I can look at a poorly-documented Haskell package and figure out how to use it just by looking at the types. It’s just a plumbing problem. I realise this is probably pie-in-the-sky, but perhaps someday there could be a higher-level language (with an expressive type system) that compiles to Nix. Gradually we would migrate package definitions to the higher-level language.
5 Likes