 | Staging | 391 Members |
| Staging merges | Running staging cycles: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+head%3Astaging-next+head%3Astaging-next-25.11 | Review Reports: https://malob.github.io/nix-review-tools-reports/ | 125 Servers |
| Staging | 391 Members |
| Staging merges | Running staging cycles: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+head%3Astaging-next+head%3Astaging-next-25.11 | Review Reports: https://malob.github.io/nix-review-tools-reports/ | 125 Servers |
| Sender | Message | Time |
|---|---|---|
| 28 Jun 2026 | ||
 emily | yeah, the ideal would be presenting the high-level principles and most important requirements upfront in a screen or two of text, with links to more detail | 21:25:56 |
 Grimmauld (any/all) | The people with whom i talked about starting out contributing mostly were willing to learn/read a lot, just intimidated by the amount of shit we have, scared to overlook something. Which, admittedly, it is quite easy to overlook something. When i review things, i try not to waste my or the reviewees time. Our documentation is currently NOT structured in a way that attempts to not waste time. Its dumped in random places, and even just getting an overview is a significant investment we expect new contributors to do. I don't think this is idea. | 21:26:22 |
| Grimmauld (any/all) | * The people with whom i talked about starting out contributing mostly were willing to learn/read a lot, just intimidated by the amount of shit we have, scared to overlook something. Which, admittedly, it is quite easy to overlook something. When i review things, i try not to waste my or the reviewees time. Our documentation is currently NOT structured in a way that attempts to not waste time. Its dumped in random places, and even just getting an overview is a significant investment we expect new contributors to do. I don't think this is ideal. | 21:26:26 |
| emily | can't avoid writing down specifics, but right now you have to wade through lots of tl;dr detail just to learn all the basic expectations about patching, commit messages etc. | 21:26:34 |
| Grimmauld (any/all) | And even then its a mess. I think we still don't have consensus about the fetchpatch2 situation... | 21:27:53 |
 Sapii/Saperson | maybe these can be moved up in the contrib.md so its the first thing seen? | 21:28:22 |
| emily | I think it's more like even with consensus we don't have people putting the effort into fixing things | 21:28:33 |
| Grimmauld (any/all) | if documentation were all in files, that'd be one thing. But sending newbies to years-ongoing technical discussions is bad | 21:28:33 |
| emily | myself included, it's just a rabbit hole I don't have time for | 21:28:45 |
| emily | and nobody owns our contributing docs really | 21:28:52 |
| Grimmauld (any/all) | sure | 21:29:01 |
| emily | it would be very high-value work if people wanted to improve them | 21:29:18 |
| Grimmauld (any/all) | everyones workflow is different. I have ideas how i would want contributing docs to be structured, but collecting all the things that need to be documented is tedious and making it work for everyone is basically impossible | 21:30:37 |
| emily | well, right now they work for nobody :) | 21:32:39 |
| Grimmauld (any/all) | I'd want:
git-merge-base master staging- tell people to STOP WASTING COMPUTE with nixpkgs-review without thinking- tell people to think? XD
- a new package/module - exiting packages/modules - existing contributors/committers - how to do (good) reviews that are useful, even if the reviewer is not a committer - includes security considerations
- examples - "inspiration" from how other distros do things (and how that translates to nix)< | 21:37:37 |
| Grimmauld (any/all) | I'd want:
git-merge-base master staging- tell people to STOP WASTING COMPUTE with nixpkgs-review without thinking- tell people to think? XD
- a new package/module - exiting packages/modules - existing contributors/committers - how to do (good) reviews that are useful, even if the reviewer is not a committer - includes security considerations
- examples - "inspiration" from how other distros do things (and how that translates to nix)
| 21:37:56 |
| Grimmauld (any/all) | okay formatting got butchered in my matrix client.... | 21:38:08 |
| Grimmauld (any/all) | I'd want: | 21:38:19 |
| Grimmauld (any/all) | ther,e thats a bit less awful+ | 21:38:34 |
| Grimmauld (any/all) | * there, thats a bit less awful | 21:38:39 |
| emily | I somewhat like having the contributor docs "right there" on GitHub in a way but I also feel like it might be more discoverable if we just had a "Nixpkgs contributors manual" alongside the others | 21:38:58 |
| emily | I get the sense that people are often surprised that we have a bunch of relevant docs that don't appear in the manuals at all | 21:39:09 |
| Grimmauld (any/all) | manual is just markdown anyways | 21:39:15 |
| Grimmauld (any/all) | it'd be in github, in some sense | 21:39:22 |
| emily | I think these ideas are good, I honestly think the top challenge is just organizing things hierarchically in a way that's useful. you ideally want a top-level document that covers "if you only have 5 minutes to read things, here are the most important things to know", and then you can drill down from there to "if you only have 10 minutes to read about this specific task, …" and so on | 21:40:41 |
| Grimmauld (any/all) | I'd want: | 21:40:53 |
| emily | delivering the core principles upfront and then getting into rules-lawyering further down | 21:41:01 |
| Grimmauld (any/all) | i suspect if i start working on something like this, i'll just end up strongly suggesting my own preferences to everyone XD | 21:42:05 |
| emily | sounds like you have the drive and the vision, you're hired :p | 21:45:29 |
| Grimmauld (any/all) | In reply to @emilazy:matrix.orgIf only it were that easy to actually do it | 21:48:35 |