Removal of a committer only requires agreement of a single delegation team member?

[sg-qwt]

Addition of a committer must be agreed upon by all delegation team members
Removal of a committer only requires agreement of a single delegation team member

I'd like the org to clarify why Removal of a committer only requires agreement of a single delegation team member. Isn't this giving too much power to any single delegation team member when it comes to the removal of a committer? Since addition of a committer must be agreed upon by all delegation team members, it seems fair to me that removal of a committer must require agreement of at least majority of delegation team members.

Any change in the list of committers must be publicly documented

Also this docs is not clear as well. I'd suggest to add a link to where it's publicly documented this case.

[infinisil]

Motivation was given in #108: It's so that all commit delegators can be comfortable with all committers at all times. Think of it as the endorsement of all commit delegators being necessary to have commit access. I think this is reasonable given the nature of Nixpkgs.

[sg-qwt]

Motivation was given in #108: It's so that all commit delegators can be comfortable with all committers at all times. Think of it as the endorsement of all commit delegators being necessary to have commit access. I think this is reasonable given the nature of Nixpkgs.

I raised this concern in direct link to the recent event of @domenkozar being removed from committers, which again created some drama and division among the community.
NixOS/nixpkgs-committers#50 (comment)

It'd be good to have at least majority agreement from delegation team members instead of just one. Also from above comment, I can only see it says discussion amongst the commit bit delegation team, which isn't very clear to me. Was that an unanimous agreement among delegation team members or A agrees but C/D disagrees, etc. Those things in addition to the final decision also worth to be documented in public I think.

[pbsds]

I want to believe that the commit bit delegation have reached out to domen before opting to revoke his commit bit, but just in case we probably should amend the rules to something of the effect of:

• Removal of a committer only requires agreement of a single delegation team member, but all other delegation team members must be convinced that reasonable due diligence in contacting and discussing the problems with the committer in question has taken place before resorting to removal.

Maybe even with:

Failure to gain this sense of due diligence is grounds for removal from the nixpkgs committer delegation team.

[philiptaron]

Thanks Silvan @infinisil; I understand the motivation. The "comfort" of commit delegators as the metric seems off to me, considering the impact that removal of privileges has on us as creatures that perceive the loss of status with far more weight than the gain of status. The impact of a decision to revoke long-standing privileges is a weighty one, and the current rules do not acknowledge that weight and the implications on the total community.

I would advocate for an equal standard for gain and loss of status, at the very least. As with Peder @pbsds's message above, I also advocate:

1. The addition of a "due diligence" standard in removal of the committer privileges.
2. Guidelines to the committer team to attempt at causing a change in behavior with the individual.
3. A stated ethic of reconciliation and restoration upon demonstration of changed behavior.

My belief is that this would go a long way towards setting an appropriate tone with removal of committer privileges, while being practicable by the delegation team.

I hope it goes without saying that I:

1. Support removal of commit rights as a consequence of consistent behavior that violates Nixpkgs norms
2. Support restoration of commit rights upon demonstrated willingness to conform to those norms
3. Understand the difficult and often thankless task of being the moderator tasked with enforcing those norms
4. Want to be part of making Nixpkgs an exemplar project with respect to kind, generous, and effective norms that promote a transformation of how humanity builds and consumes software.

[pbsds]

An additional problem with the current rules as well is how it diminishes public trust in the process of the nixpkgs committer delegation team. With the current public information one possible narrative becomes "a new member asked to join the delegation, and then used their position to publicly eject a committer". In such a scenario the other delegation members are effectively forced just take the social recoil in silence to not further diminish trust.

[JohnRTitor]

commit bit delegation have reached out to domen before opting to revoke his commit bit

Doesn't look like so.

[drupol]

And now this NixOS/nixpkgs#415576

It makes me question whether the person(s) responsible for this decision understood the full implications and whether a different approach could have avoided this outcome.

[piegamesde]

It makes me question whether the person(s) responsible for this decision understood the full implications

I am pretty certain of that. This is absolutely not the first time that people who have their commit bit removed retire from Nixpkgs altogether as a response, despite there being no technical need.

whether a different approach could have avoided this outcome.

We too have a precedent for that: People who lost their commit bit and took the feedback to heart, improved, and eventually asked it back.

[wolfgangwalther]

commit bit delegation have reached out to domen before opting to revoke his commit bit

Doesn't look like so.

That's only one side of the story, though. He also claims to have "clarified the context and replied in good faith that I would wait for CI going forward" in NixOS/nixpkgs#402812 - but I can't find any of that in there.

And now this NixOS/nixpkgs#415576

It makes me question whether the person(s) responsible for this decision understood the full implications

This should not play a role in the decision itself, otherwise it'd just create a system of pressure. "Keep my commit bit, or otherwise I'll quit" won't be good.

and whether a different approach could have avoided this outcome.

It's a really sad turn of events and I really hope that this can be cleared up between all involved with some more and better communication.

Could this be a case for https://discourse.nixos.org/t/introducing-nixos-mediation-a-new-conflict-resolution-service/61614?

[pbsds]

Please avoid fueling further tensions and at least wait until both sides have put together a response. This is most definitely on their radar.

EDIT 2025-06-14: NixOS/nixpkgs-committers#50 (comment) may not be in the format I was expecting but a response is a response

[wolfgangwalther]

I would advocate for an equal standard for gain and loss of status, at the very least.

Given that we currently have Addition of a committer must be agreed upon by all delegation team members, the same for removal would be, that all delegation team members must agree on removing a commit bit. But with that rule, the hurdle to actually become a committer would be much higher - because suddenly any team member of the delegation team would need to be sure that this person will be a good committer for a long time. By raising the bar to be removed as a committer, you're also going to raise the bar to become one.

I don't think we want that, right?

Also, with NixOS/nixpkgs-committers#50 (comment) there is a clear indication that the "1 team member rule" is not what has happened here.

I think the reasoning given in #121 (comment) makes sense.

What really puzzles me, however, is, the lack of communication around this issue. There are two very short comments in the committers issue about this whole thing from the commit bit delegation team. A massive number of reactions to them - and just silence on top of that. This strikes me as a bigger problem. Is this really something that must be put in a "rule" to make it happen?

[philiptaron]

The other way to read that equality suggestion, @wolfgangwalther, is that the standards should be adjusted so that any two members of @NixOS/commit-bit-delegation can raise and and any two can lower. But you can't just do it on your own -- it's a variant of the two-person rule, common in situations of high importance.

I agree with your puzzlement about the lack of communication. I'm hopeful that waiting just a little bit more will yield some statement from the folks with the official hat on.