Accessibility and obstacles to community contribution

1

hi all! as we all know, community participation is hard. it’s also harder for some people than for others due to disability, life stuff, or any number of other reasons. these are all voices we should want to and would benefit from hearing, but we’re just not hearing them because it’s too dang hard to participate!

this is meant to be a low-energy thread where everyone can share what makes it hard for you, personally to contribute to nix/nixos. be real and honest! if something is hard then it’s hard, no matter how easy you think it “should have” been. you don’t need to know how to solve it!

in order to collect as many viewpoints as possible, i’d like to establish some ground rules for participation in this thread.

ground rules

  1. we’re here to listen, not judge. everyone has their own reasons for certain things being hard for them! that’s what we’re here to find out, not to make them justify their own disability. absolutely do not invalidate what someone else finds difficult, even if it’s not difficult for you.

  2. we’re not setting out immediately to find solutions. i want to give space for everyone to be heard, and that means not talking over them. it’s hard enough for a lot of folks to even find the energy and words to express themselves; let’s not add on the effort of explaining to someone who doesn’t share your situation why their suggestion isn’t actually helpful.

  3. let’s not make it personal. if a specific someone is presenting an obstacle to your participation, then talk about what’s preventing you from resolving that situation; don’t name names.

  4. if you don’t have anything to share about obstacles in your experience of learning about or contributing to nixos, congratulations! this thread isn’t for you.

20 Likes
2

A contribution from a fedi user:

I find interesting that they use discourse.
Which yikes is bad.
It tells me that it doesn’t support my browser (palemoon, latest version, less than 1 month old; maybe they forgot rule 1 of accessibility: let the user pick what software works for them), disables scroll bars to make it harder to follow discussions, and generally is quite bad for accessibility.

As an aside, since I know somebody will jump and say use firefox or chrome: neither work for me due to the way they do things

5 Likes
3
Hidden

Nix or the full ecosystem around it?

4
Hidden

i’m using nix/nixos here interchangeably to refer to official projects

1 Like
6
Hidden

don’t make me tap the sign

2 Likes
8
Hidden

whether or not you were trying to talk over them, were only trying to add context, etc. the ground rules of this thread should be clear. we are here to collect personal anecdotes about what makes it difficult for you to participate. if you are not here to share your own difficulties, then take it somewhere else.

9

I’m not sure whether this is simply perception on my part, or an actual reflection of reality, but from watching others maintain packages via PR, it seems rather onerous to be a package maintainer.

My point of reference: I maintain a number of packages in gentoo’s guru user repository. This is a second-tier of packages, not part of the core package set, but still an official gentoo project. There’s no real analog in Nix. I tend to describe it as “if the arch linux AUR had a core team of code reviewers merging things in”, but I don’t think that captures the culture of it either.

At any rate, as a contributor, I commit directly to the dev branch. I had to apply for commit access to the dev branch, but it was a one time thing, and it was as simple as copy pasting some commands to generate some keys in a format they liked, and attaching them to an issue requesting access.

A project lead peridoically merges everything into the master branch if things look fine. If they don’t look fine, they either leave me a comment on my commit asking me to change things, or they just make the changes themselves- no need to wait around for me. Other contributors can also directly make changes to fix my stuff, or I can fix theirs. It’s easy to see when I make a new commit to fix the problems they brought up since it’s all in the dev commit log stream.

They also will sometimes suggest changes but merge my build scripts anyway because they work fine, and the suggested changes are just nitpicks. I can go back in afterwards and implement those changes if I want, though sometimes I wait until the next version bump I do because I don’t have the energy at the time.

Committing to dev is the preferred method for contributing to that project; PRs are discouraged due to the additional overhead they introduce for the project leads, and the increased incidence of drive-by packages that come from PR with no extended maintenance to follow.

I’m not suggesting to apply this model to nixpkgs; I don’t think it aligns with what nixpkgs wants to be, but I want to compare it against my impression of contributing to nixpkgs.

From talking with friends who contribute, it’s my impression that maintaining packages in nixpkgs requires a lot more back and forth during the PR process to get a package into a state of sufficient correctness, even for version bumps. That it often requires pinging various people with commit access. That it can lead to duplicated effort when multiple people open separate PRs to bump the same package. And that what the state of “correct” is can seem unclear, and shift over time.

This impression has put me off from attempting to contribute to nixpkgs, so I do not have personal experience to go off here. In particular, I’m not interested in contributing a package and then leaving it to rot; I want to continue to maintain it. But I only have so much energy to put towards that. So while I’m fine with a high degree of friction introducing a new package, I’m put off by the notion that I might have to interact with that same level friction every time I update the package too.

From a technical perspective, I also find that bumping a package with a lot of hashes that need changing in the nix file can be incredibly taxing, as I need to re-run the build and update them one by one, hash by hash. I’m not aware of whether others have scripted this away into something I can run to update everything (would need to support language-specific things like cargoLock.outputHashes since that’s where I have the most trouble). I think this is a lower barrier for me than the rest, but it is a factor.

I do contribute in other ways, primarily through blogging, as well as existing ambiently in the exotic targets channel and working to be thorough when investigating bugs with others there.

8 Likes
10

I’m also thinking of bringing this kind of development model to nixpkgs, but for slightly different reasons.

As a nixpkgs committer myself (and I suppose other committers also find it the same way), I’m reluctant to merge large and potentially breaking pull requests, as nixpkgs has a lot of users across many platforms (as well as out-of-tree users), merging these potentially breaks the setup of a lot of happy users, even driving them away from nixpkgs. Another issue is, although being a committer, I’m still not familiar/confident enough with a lot parts of nixpkgs, a huge codebase, and would rather prefer getting some opinions from real users of these.

But if we postpone merging these, or even refuse to review these PRs, it would certainly not be a satisfying experience for new contributors, and those who had spent a lot lot of time on these structurally complicated PRs.

The reason behind all this is clear: PRs are not getting the visibility they deserve. I don’t think anyone would watch the nixpkgs repo, getting thousands of notification per day is the opposite of being productive, and not everyone apart from committers would look through the new PRs reviewing the ones they are interested in. So in many cases, only after the PRs have been merged and shipped to everyone on the unstable channel would random folks jump in and comment: hey this breaks my system, we need a fix ASAP (This is an especially stressful situation for me).

So we need more visibility before the PR authors put too much effort into a likely to be reverted change, before committers make the wrong call of merging, and get earlier feedback from real users.

A potential approach is, as you mentioned, creating a dev branch, where PRs are merged casually without having to go through a thorough review (or just give the access to all nixos org members). But I’m skeptical whether a representative number of users would opt into using it, that would need some fresh ideas.

Sidenotes: speaking of automatically bumping packages (or even creating packages), nix-update and nix-init are helpful tools, and they can already handle many language specific fetchers. For the style consistency part, there is nixpkgs-lint and nixpkgs-hammering but they don’t seem to be gaining popularity.

12 Likes
11

These are some issues I’ve experienced.

There’s some documentation for how to format your commits and code in CONTRIBUTING.md, but most of that information is communal knowledge. I’ve gotten feedback that I need to organize my derivation and its arguments a certain way based on an old thread here. That stuff should be in the contributing documentation. If it’s not because no one can agree, then we need to look at our basic governance processes because they’re not working.

If you’re trying to contribute a fix, and it’s for a particular language, you might step on the toes of language-specific workflows. Some of them are quite different compared to the standard contributing workflow (targeting different branches, etc), and it’s not always obvious what you should be targeting when you’re contributing a fix outside the usual update cycle.

I hate to say it because I’m primarily a contributor on the Darwin side, but cross-platform support is also an issue. I expect very few people are able to build and test on aarch64 and x86_64 for Darwin and Linux. Linux contributors can sometimes get away with not bothering to support Darwin, but I don’t think it’s quite as easy going the other way.

Somewhat related to the above, but I wouldn’t be surprised if the existence of other packaging ecosystems makes people less likely to contribute. Honestly, I find the existence of Homebrew integration dismaying. Instead of fixing and improving nixpkgs, it’s like people have given up on making it work. If you do the work anyway, you might end up being the only one using it.

Finally, flakes. Instead of bothering with nixpkgs, you can go do your own thing. I’m guilty of this. I have a flake with some Mac apps I’ve packaged that I probably should contribute to nixpkgs, but I don’t really know whether more binary-only Mac app packages would be wanted (especially if you could build them from source, but they’d be effectively broken due to the lack of support for code-signing with entitlements in nixpkgs).

11 Likes
12

The amount of time, energy and seemingly never ending bikesheding that the RFC process is.

20 Likes
13

Nixpkgs is too fast. There is too much stuff happening, everywhere all over the place, too quickly. And I think that this is an obstacle for contributing and has significant negative effects on mental health. Some aspects of this are:

  • FOMO, constantly checking mails or discussions to not be left behind or to not miss anything potentially important. The “important” things are often times hidden in a lot of noise, which contributes to that.
  • Similarly, there are a lot of situations that create a sense of time pressure. The project will move on, with or without you.
  • High mental load due to the frequent context switching between a lot of small tasks across wildly different topics.
  • The “there is always something to do” feeling can be pretty addictive, and the many small rewarding tasks feed in to that.

In short, being an active contributor in Nixpkgs constantly requires pouring time and energy into it, all the time. And not being able to expend that kind of energy for a while may not have any serious negative consequences. But it does feel bad, which implicitly creates pressure to keep going.

I think that the bump packages and review PRs grind exhibits these issues the most, which is the reason I’ve mostly stopped doing reviews and don’t really maintain any packages. (I am maintainer for a couple of packages, but I honestly don’t remember the last time I actually did a package version bump. Feels bad.) I have since moved my focus towards doing other Nix related things like RFCs because of this, but those exhibit roughly the same problematic patterns as well (plus their own sets of issues).

Insert concluding paragraph here; I just lost yet another hour of my day doing Nix things by writing this post, am tired

20 Likes
15

apologies if the necropost here is unwanted, but conversely for me: in some ways, nixpkgs is too slow.

it can take inordinate amounts of time to get simple PRs merged, for no obvious reason. as a maintainer, it sucks massively to have an update PR for your own package sit around for three weeks, or a PR to fix a problem with your own package go a month and a half before being merged. i’ve had a PR to add a new package open for three months now; i got one review with a single suggestion four days ago, which i addressed within 24 hours, and then nothing has happened for the past three days. (maybe the solution to this is “stop adding packages to nixpkgs”? maybe i will investigate flakehub etc. in future)

when it already takes at least a couple of days for merged PRs to reach nixos-unstable, not accounting for the periods when channels are blocked due to build problems, it very effectively decouples the effort of making PRs from the reward of seeing them land and be available to use, which is not particularly useful for motivating me to contribute more.

13 Likes
16
17

I love learning by contributing small “not-so-important” things. And that process is powered by a fast cycle of review / update / merge / etc. GitHub suggests people to review, and upon clicking the button, I often get reviews in minutes. Super fast!

But the merge or re-review side is unclear for me.

First, I tried using the threads in Discourse to ask for merges. (Begging.)

Second, I went onto the Matrix instance to ask people there for merges. (Begging.)

Third, I tried looking through the recent commit-bit holders, picking one, and pinging them directly on the PR. (Directed, annoying begging.)

Mostly this doesn’t work.

Either the way that I’m asking for the merge isn’t compelling, or it’s not specific and directed enough, or there’s something else wrong with the PR that wasn’t called out. Perhaps it was just how low-impact it is! … but that’s what powers me learning to be able to make higher-impact PRs.

18 Likes
18

ADHD makes the docs to read and anything to do with doc reading extremely hard, like a basic to-do guide to Nix Lang itself and packaging for Nix and creating modules for NixOS would be extremely appreciated. There needs to be a better to approach tutorial overall for creating modules, etc, maybe a video series?

4 Likes
21

I am not sure if I have ADHD myself, but I fully subscribe to your point. :slight_smile:

This has been my experience as well. I’d really love to see these things:

  • A basic to-do guide to Nix Lang itself. I’d add: not using just toy examples, but actually useful things many people might want when using nix for its domain specific use case.

  • Packaging for Nix. Very crucial. Most of the times if I want to package something myself for my own system I end up reading existing derivations for apps that appear similar to the one I’d like to package. And then I guess around why stuff doesn’t work.

  • Creating modules for NixOS. And for home-manager I might add. Combined with learning the right selection of nix functions most useful for this task. And where to get them.

  • Also how to set up a functional development environment, including LSP setup and debugging for the most common editors. Most tutorials I have seen, video or text, YouTube or documentation, say nothing to this point.

4 Likes
23

Agreed, I like to add I also had to look for other derivations for apps I wanted to package. Because of the lack of concrete examples in any existing tutorials like that out there, so that would be great to have.

1 Like
27

So much this. It’s not possible to follow anything without being overwhelmed.

What frustrates me the most is that this is a technical problem that was solved (example) years ago, we’re just stuck on a platform that didn’t.

Want to get notified of security issues?

  • github: search periodically for issues/prs tagged “security” or join the matrix room I guess?
  • phorge: write a notification rule
    Screenshot
    image.png1052×417 27.3 KB

Want to know when new RFCs are created?

  • github: enable notifications for the rfcs repo and unfollow every PR after the first notification
  • phorge: write a notification rule

Want to know when packages you care about but you aren’t a maintainer of are updated? When a PR that solves an issue you follow is opened? When a PR that mentions in the diff a specific architecture is opened/merged? When a project of yours is packaged? You can guess the rest…

The end result is that I rarely review stuff unless someone explicitly pings me.

Note: phorge is just an example to show what is possible. it has its own problems and I’m not necessarily saying we should switch to that (though I am in the process of packaging it :wink: )

6 Likes
28

In general, I don’t think GitHub is a powerful enough place to host the nix repos, I think self-hosting should be the way to go. But this isn’t a topic for this thread, I imagine.

6 Likes
29

Hi, a quick reminder to please actually read the rules for this topic, and to follow them. As a rule of thumb, if you are replying to somebody else, you’re likely on the wrong track. If you agree with a post, simply leave a like. Try to make this only about yourself and your experiences.

6 Likes