As for who gets banned and for what, it seems like there is no problem right now. There is (hopefully) no doubt the ban of 0xABAB was absolutely reasonable. At least after reading how he responded to the warnings given to him. So if there would’ve been a short guideline telling that people will be warned directly (e.g. per mail) and banned if they don’t change, this Post here would’ve probably been closed in a single answer.
And like @lukego, I also had the problem some times that I didn’t know what I have to do in order for a PR to get merged. I’m very glad I only got very nice feedback on my PR’s and I could just fix the issues to get somebody merge it at some point. But I’m sure getting a harsh feedback at the beginning could’ve made me turn away from NixOs.
I guess we could add those four points in short to the contributionguideline at https://github.com/NixOS/nixpkgs/blob/6dce69e47536568700951a71e417a9c93f8c9448/.github/CONTRIBUTING.md
- how different mechanisms like a PR work (maybe there are more mechanisms that could be explained?)
- what the different authorities are (contributor, maintainer, etc.) and what their “rights” and responsibilities are
- do’s and don’ts (a do is already described by telling how a PR should look. Maybe link to the CoC of @zimbatm )
- how to get help
I’m aware that there are some RFC’s which will improve the PR process (e.g. [RFC 0030] Formalize review workflow by timokau · Pull Request #30 · NixOS/rfcs · GitHub which has sadly been closed for now) and making sure those RFCs will be well documented might already be enough.
I also realise there are already documentations like Nixpkgs 23.11 manual | Nix & NixOS but they don’t really answer those four points (and in my opinion such a massive onepager was and is still quite overwhelming sometimes, but this is probably personal preference).