Code change:
The file seems to be randomly edited by committers who feel like doing so, thereby ignoring data protection laws governing some regions where our contributors come from (e.g. , , as of before the force-push) guidelines our community gave to itself (e.g. , ). Having our community guidelines ignored at random lets NixOS look unprofessional and can scare away contributors and supporters. Having data protection laws ignored might even lead to expensive liabilities for the NixOS foundation, meaning that the money would be missing when paying for servers or incentivizing contributors. Therefore, there should be some QA when editing that file. A straightforward suggestion regarding this would be to install one or more maintainers for that file itself. These would have to review any PRs touching it before merging would be allowed. The maintainers should provide evidence that they are aware of laws governing personal data in the different jurisdictions we work with, and aware of our community guidelines. commits happening where laws and/or community guidelines are being ignored Not applicable.
Hi, on GitHub and more specifically the nixpkgs repo we almost exclusively handle the technical side of things, so keeping moderation and foundation related discussions low would be greatly appreciated (yes there is some exceptions). We have for general commmunity disscusion. I generally understand your issue, and I'm fearly certian that the foundation takes gdpr serious, and if you actually want to send a gdpr deletion request send it to one of the listed contact methods on If you have a problem with the way someone in a nix* project bevhaves then please message one of the mods privatley or report it in the matrix room. Please keep in mind that Nix, NixOS, Nixpkgs and almost any other Project under the foundations hat are community first Projects and most people particpating do so in there spare time. And that the way you are currently behaving comes across quite childish. And you might also want to note that your github handle, even if we don't track it in the maintainers file, still ends up in the git history anyways because github puts it in the commit messages of pr merges, so not having it in the list basically doesn't matter. The point aobut Lack of QA for changes to maintainers/maintainer- might be valid and if you want to persue the issue I would suggest you do a discourse post to raise awrness and try to convince one or two well-known community mebers to put them selfs as code owners for the file.
Let's please keep this scoped towards only discussing a QA process for the maintainers file, and not go into other points of disagreement from the issues that sparked this discussion. Proposal in .
Seems like the default mechanisms for maintainers who get pinged on file changes won't work well here. Most commits are probably contributors adding themselves to the file. If we assume that the TOFU model works for these, only exceptional commits would have to be checked manually, thereby reducing the workload. But this would require a smarter ...
Well, the maintainer list is currently maintained in code, so the platform where the repository resides should be an appropriate place to discuss how that's done. Of course, one might argue that this is a mistake in the first place considering the unclear situation regarding how to comply with the GDPR with such a setup. If we go that route, then yes, maintenance of the list should also be discussed somewhere else.

Related discussion:
text: /nixos/README.md @infinisil /pkgs/README.md @infinisil /maintainers/README.md @infinisil <ins> /maintainers/* @piegamesde @Janik-Haag </ins> # User-facing development documentation /doc/development.md @infinisil