Recently @edolstra granted me permissions for NixOS/nix, so I started labeling issues and pull requests. Hopefully this will help guiding the work of maintainers, contributors, and initiatives such as the installer workgroup or the documentation team to figure out what would be the most valuable and attainable thing to do.
The general idea is to categorize issues and pull requests by roadmap items and maintenance tasks. Since there is no community-wide roadmap yet, I took the liberty to just do something at all and pick up recurring patterns we discussed in Tweag’s Nix team led by @thufschmitt.
The following proposal is biased towards improving onboarding and optimizing experience for the growing user base of software developers who are Nix beginners, and ordered by impact for that audience.
Roadmap
- installer
- nix-shell (new)
- documentation
- UX
- error-messages
- new-cli
- flakes
- developer-experience
- good-first-bug
- macos
- windows (new)
- performance (new)
- ca-derivations
Maintenance
Priorities
Even with filters the number of issues is still overwhelming. I therefore propose to establish a convention of adding 
to issues and pull requests you find important, and encouraging everyone you introduce to Nix to do the same.
GitHub supports queries sorted by number of . Here is an example for all Nix issues. This should help maintainers and contributors to obtain a first approximation of user needs. It could also raise visibility of the development process, which happens on GitHub, and help us pave ways for enthusiastic users to become effective contributors.
Next steps
I will continue triaging issues in the upcoming days, starting with the oldest. This will take some time.
While there should be as few labels as possible to keep it tidy (for example, we should probably remove improvement, as it does not add information) we may want to add a few more, for example reproducibility (which is a frequent topic).
With more labels in place, meanwhile you can help immediately on topics you care about:
- starting with the oldest, check if issues are still valid and pull requests are still active
- invalid issues: show evidence (e.g. merged pull request, failed reproduction, duplicate issue) and ping the respective maintainers to close them
- stale pull requests: ping author and ask if they want to continue
- vote on active issues and pull requests labelled by topics you care about
- provide or confirm reproduction steps if they are missing
- check auto-closed issues and (ask to) reopen them if they are still valid
There is still some work to do to better formalize responsibilities. It should be immediately visible or easy to find who could take care of an issue or pull request in a timely manner.
There is also more work to do to make possible pathways to contributing more visible, and provide guidance to both users and contributors. Proposals such as this one should eventually end up in authoritative sources, such as the Nix manual.