Nixpkgs committers

This repository publicly tracks the current members and changes of the Nixpkgs Committers team, whose members have write access to Nixpkgs.

While the Nixpkgs core team is vacant, the Nixpkgs CI team maintain the member list in this repository, as authorized by the Steering Committee (#129), according to the documented procedures.

Committer Responsibilities

Adapted from NixOS/org#122.

When granted the ability to commit, you are expected to uphold the following:

1. You are responsible for what you merge.
   1. So is the author.
   2. Since you have the power to correct it, you are often more responsible.
2. You are responsible for how you behave in reviewing code.
   1. You are entrusted with upholding Nixpkgs-wide quality
   2. You are entrusted with making Nixpkgs a welcoming and inclusive space.
   3. This means you cannot make up a standard and personally enforce it.
   4. This means you defer to other reviewers if they understand the area better than you.
3. You are responsible for learning.
   1. If you are given feedback by others, take it to heart, or fight it fairly.
   2. If you are given feedback by the commit-bit-granters in particular, they will note whether your privilege is at stake.
4. You are responsible for teaching.
   1. Don't just correct, explain.
   2. Don't just ❌, encourage what to do next.
5. Merging your own PRs is acceptable.
   1. Don't do so to avoid community discussion.
   2. Don't do so and break things. Again, you are responsible for what you merge.
6. You have limits. Please honor them and allow for other's efforts to come in, without gating whole areas on yourself and your review.
7. When you do break things, acknowledge your mistake and apologize.
   1. Try to make it better either by changing your behavior in future or by undoing what has been broken.

What we look for in committers

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.

Nominations

Anyone can nominate themselves or someone else for commit access. This includes first-time applicants and those who have previously had commit access removed.

We won’t hold an application against a candidate even if we don’t feel they’re ready yet. When in doubt, please nominate!

To nominate yourself or somebody else:

1. Before nomination, ensure you have read and understood committer responsibilities above.
2. Check open nominations to make sure the user hasn't been nominated already.
3. Click this link to create a new file in the members directory.
4. Leave the file contents empty and replace <GITHUB_HANDLE> with the handle (without @) of the user you'd like to nominate .
5. Click on "Commit changes..." and follow the steps to create a PR.
6. State your motivation for the nomination in the PR description.

Such nominations are also automatically announced in this issue, which you can subscribe to for updates.

How we process nominations

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.

We will review concerns about prospective or existing committers that are raised to us, either publicly in this repository or Nixpkgs or privately. Reach out to philip.taron@gmail.com for private matters, or on the Nixpkgs Zulip. When concerns are sent privately, we will treat the identity of the reporter as confidential, with the exception of involving the community team if we believe the report warrants their review.

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.

Removals

Inactivity

As per RFC 55 and the SC-approved amendment, inactive committers are routinely "retired" from being a Nixpkgs committer.

Former committers may still be active in other ways, such as maintaining packages and modules. See semi-automatic retirement below for more detail. Former committers that wish to actively make contributions that require commit access may re-nominate themselves at any time. See nominations above.

Emergencies and misuse

If a committer violates the expectations outlined above, delegators may remove their commit access.

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.

Individuals removed for cause may re-apply via the standard Nomination process once they feel they can demonstrate alignment with committer expectations. See nominations above.

Automation

Semi-automatic synchronisation

Every day, a GitHub Action workflow runs to synchronise the members of the GitHub team with the member list in this repository. If they don't match, an automated PR is created, which should be merged by the Nixpkgs commit delegators to reconcile the mismatch.

Semi-automatic retirement

Every day, a GitHub Action workflow runs to check if any Nixpkgs committers have not used their commit access within the last year, in which case an automated PR is created to remove them from the member list.

The PR will ping the user and inform them that it will by default be merged and implemented in one month. If the PR is still open one month later, an automated comment will be posted with the next steps for the Nixpkgs commit delegators.

If the PR is closed, retirement is delayed by another year.

Setup

Automation depends on a GitHub App with the following permissions:

• Organisation: Members read only (to be able to read the team members)
• Repository: Pull requests read write, Contents read write (to be able to create PRs in this repository)

The GitHub App should only be installed on this repository. To give the workflows access to the GitHub App:

• Configure the Client ID as the repository variable CLIENT_ID
• Configure the private key as the repository secret PRIVATE_KEY

See scripts/README.md for testing details.