maintainers/README.md: clarify maintainer removal

[wolfgangwalther]

The wording on how to lose maintainer status implied that this was per package. While this is true, we also follow the same procedure for entirely inactive maintainers, dropping them from all packages, including their maintainer handle.

I'm a friend of making things shorter, this should leave enough room for interpretation of both.

Came up in #437082 (comment).

Do we need to make it clearer or is that OK?

Things done

• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[pbsds]

While my feelings are conflicted regarding the current common practice of removing people from maintainer-list.nix, I think dropping inactive maintainers from meta.maintainers treewide should be encouraged 👍

[wolfgangwalther]

While my feelings are conflicted regarding the current common practice of removing people from maintainer-list.nix

Could you elaborate? I'd like to understand more.

[pbsds]

My feelings are analogous to scrubbing a name from the end credits of a re-release of a movie they worked on, simply because they didn't also participate in the sequel. Some people may view their entry in the maintainers file as their attribution, as the proof that they have contributed to the project.

But the alternative, which is distributing historical maintainer entries in the nixpkgs tarball is not sustainable either. I think what I want to clearly establish is that this file is not meant to track attribution, but rather serve as the registry of active maintainers.

[wolfgangwalther]

I see what you mean. Imho, the same as in NixOS/org#121 (comment) wrt to committers applies here: The commit-bit, as well as an entry in maintainers, comes with permissions (on GitHub). As such, both of these are the wrong tools for "attribution". We don't have a good replacement, though, I agree with you here.

[pbsds]

I think the difference comes down to

diff --git a/maintainers/maintainer-list.nix b/maintainers/maintainer-list.nix
index 23bb14820650..30e9e5809da9 100644
--- a/maintainers/maintainer-list.nix
+++ b/maintainers/maintainer-list.nix
@@ -1,5 +1,5 @@
 /*
-  List of NixOS maintainers.
+  List of active NixOS maintainers.
    ```nix
    handle = {
      # Required

[wolfgangwalther]

Added that!

[MattSturgeon]

This could also be inconvenient for downstream/out-of-tree projects that leverage lib.maintainers. However that shouldn't mean nixpkgs should keep inactive maintainers just in case they are used out-of-tree.

Such projects can of course vendor the removed maintainers in their repo, when they update to a nixpkgs revision that no longer includes them in lib.maintainers.

---

Regardless of my above musing, the new wording better describes what we actually do in practice. It isn't really an actual policy change..

[wolfgangwalther]

@pbsds since you added the 9.needs: community feedback label - is that still the case or was that resolved with the addition of "active", as well?

[pbsds]

Regardless of my above musing, the new wording better describes what we actually do in practice. It isn't really an actual policy change..

I still do consider this a policy change, even if there is no change to the currently practiced policy, it is a change to what is formally agreed upon.

---

@pbsds since you added the 9.needs: community feedback label - is that still the case or was that resolved with the addition of "active", as well?

I only added that label because i consider the approval threshold to merge policy changes higher than normal changes.

[zeuner]

Just because there were cases where the currently documented process wasn't followed does not mean it's better to extend what's documented. In fact, there are good reasons to assume that the per-package approach is documented this way for good reasons, considering that it seems better suited to the obvious goal of improving package maintenance, or at least getting a more accurate view of which packages are properly maintained:

1. There may be good reasons why maintainer removal criteria are met for one package, while they aren't for other packages of the same maintainer. People often maintain packages they use themselves. Now, if they stop using some of the packages and forget to remove themselves from meta.maintainers themselves, it might be justified to remove them through the documented process, but this alone would not indicate any maintenance issue with the other maintained packages.

2. Contributors with limited time might decide to only maintain packages which rarely need changes, e.g. because the upstream source is rather stable. Think bzip2. This should be perfectly fine as long as they react when they are needed. The per-maintainer approach can easily lead to the situation where committers mistakenly think the maintainer does not meet maintainer obligations even though the maintained packages just didn't need attention. Removing or replacing maintainers in such contexts is expected to be detrimental for nixpkgs quality because the original maintainers can still assumed to have opted for maintenance because they know the maintained package very well.

Switching from a per-package to a per-user process equals a paradigm shift away from "how can we ensure quality in our packages?" towards a "who do we want to be a maintainer?". Such an far-reaching change should involve community consensus, so it would be better to run this through an RFC process if there is sufficient evidence that the change would be beneficial.

However, it's currently not obvious that the change would have any real advantages. The PR also does not state any, it is just built on the observation that there have already been violations of the documented process. It's yet to be shown that the proposed change will also come with advantages. Until then, it may even be considered a disadvantage:

The idea of completely removing a maintainer together with all corresponding references in packages already seems to lead to misguiding incentives. In related PRs, checking whether maintainer obligations have been met sometimes seems to play a minor role. With the help of a script, maintainers are chosen solely based on data from maintainers/maintainer-list.nix, which does not include any data related to reaction times to maintainer requests.

[wolfgangwalther]

@infinisil could you have a quick look at these changes, too?

[infinisil]

Makes sense, let's do it!