How many people are paid to work on Nix/Nixpkgs?

[tokudan]

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]

[raboof]

@kvtb

Another threshold to contributing (at least for me) is that I’d like to contribute ‘small’ stuff without becoming a true ‘developer’. (…) It could be that the Nix community does not favor ‘contributer light’ style contributions

I consider myself a ‘casual contributor’, and my impression is that nixpkgs can benefit from those a lot.

@kvtb

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)

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.

@kvtb

and (without) becoming an official maintainer. I don’t commit to creating a PR every time there is a new upstream version

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?

[jonringer]

@kvtb

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.

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.

[blaggacao]

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:

https://github.com/NixOS/nixpkgs/pull/100462

[SRGOM]

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

1. 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.

2. 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.

3. (some) commiters seem worried about signing off on small PRs. Which is okay so long as they don’t “taint” it by posting a comment (see last point of this post for example) because now no other committer can touch it out of courtsey.

IMHO, a project on GitHub should follow simple guidelines, does this commit improve things or maintains status quo on all dimensions:

1. package and related packages working: will the package work better?

2. 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.

3. 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.

4. 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.

5. Automated testing.

Just like there are guidelines for contributors perhaps there should be reviewer guidelines too?

What not to do:

1. you made a documentation change about a flag? This is a very small PR. And that other software-- it’s documentaion regarding this flag is old and incorrect (before this PR) . Go change that too.

[aanderse]

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.

[jonringer]

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:

• Adding a package to nixpkgs unstable
• How to do python packaging in nixpkgs

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/

[kvtb]

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)

Casual Nixpkgs contributions

Referring to the discussion here https://discourse.nixos.org/t/how-many-people-are-paid-to-work-on-nix-nixpkgs/8307 I open this topic to be able do to casual nixpkgs contributions. The idea is to lower the threshold to contribute to Nixpkgs for people like me who are not a dev, do not have a Github account, do not check out nixpkgs via git locally, are merely users, etc. etc etc but still want to share something so now and then. Here is my first casual contribution. A sponsored PR (=someone who…