Nixpkgs committer delegation guidelines

The Nixpkgs core team are currently in charge of Nixpkgs committer delegation due to the previous team’s lack of time. We aspire to follow these guidelines for the process:

1. We will leave applications open for feedback for at least one week before approving a new committer and aim to make a decision within four weeks.

2. The main things we look for in committers are good communication, good judgement, and relevant experience. We will take tenure, contributions, and reviews into account, but won’t use a strict numeric threshold to approve or decline applications. We believe the skills to collaborate with others in the project, provide substantive reviews that go beyond style matters, navigate conflict effectively, and avoid reckless actions are more important than any objective criteria we could write down. We won’t hold an application against a candidate even if we don’t feel they’re ready yet, so when in doubt, please feel free to nominate!

3. We will review concerns about prospective or existing committers that are raised to us, either publicly in this repository or Nixpkgs, or privately through our contact methods. When concerns are sent privately, we will treat the identity of the reporter as confidential, with the exception of involving the moderation team if we believe the report warrants their review.

4. When declining an application or removing an existing committer, we will give at least a brief public summary of the reasoning. We may also reach out to the person privately with more detail to give them a chance to discuss candidly outside of the public spotlight. To be clear, this is not to avoid transparency, and the recipients are free to publish the correspondence if they wish.

5. Before removing an existing committer, we will make an effort to discuss concerns with them and give warning, and will try to reach consensus on these situations, per our usual procedures. Emergency situations where the health of the project warrants immediate removal are an exception, e.g. acute security or infrastructure risk from apparent account compromise or “going rogue”. If we make a non‐unanimous decision to remove a committer, we will publicly disclose who was involved in the decision for transparency.

Start with the issue body and its 14-comment discussion; no source file, test, or implementation entry point is mentioned. Determine whether the proposed committer-delegation guidelines have reached agreement, and treat a documented consensus and adopted wording as the completion criteria.