Maintainer Teams, Scripts, and Commit Guidelines

### Maintainer teams Feel free to create a new maintainer team in [`team-list.nix`](./team-list.nix) when a group is collectively responsible for a collection of packages. Use taste and personal judgement when deciding if a team is warranted. Teams are allowed to define their own rules about membership. For example, some teams will represent a business or other group which wants to carefully track its members. Other teams may be very open about who can join, and allow anybody to participate. When reviewing changes to a team, read the team's scope and the context around the member list for indications about the team's membership policy. In any case, request reviews from the existing team members. If the team lists no specific membership policy, feel free to merge changes to the team after giving the existing members a few days to respond. *Important:* If a team says it is a closed group, do not merge additions to the team without an approval by at least one existing member. # Maintainer scripts Various utility scripts, which are mainly useful for nixpkgs maintainers, are available under `./scripts/`. See its [README](./scripts/README.md) for further information. # nixpkgs-merge-bot To streamline autoupdates, leverage the nixpkgs-merge-bot by commenting `@NixOS/nixpkgs-merge-bot merge` if the package resides in pkgs-by-name and the commenter is among the package maintainers. The bot ensures that all ofborg checks, except for darwin, are successfully completed before merging the pull request. Should the checks still be underway, the bot patiently waits for ofborg to finish before attempting the merge again. # Guidelines for Committers When merging pull requests, care must be taken to reduce impact to the `master` branch. If a commit breaks evaluation, it will affect Ofborg evaluation results in other pull requests and block Hydra CI, thus introducing chaos to our workflow. One approach to avoid merging such problematic changes is to wait for successful Ofborg evaluation. Additionally, using tools like [nixpkgs-review](https://github.com/Mic92/nixpkgs-review) can help spot issues early, before Ofborg finishes evaluation. ## Breaking changes

This section covers the use of maintainer teams, available utility scripts for nixpkgs maintainers, and guidelines for committers. It explains when to create a new maintainer team, how to review changes to team memberships, and the importance of respecting team membership policies. It also introduces the nixpkgs-merge-bot for streamlining autoupdates and emphasizes the need to minimize the impact of commits to the master branch by waiting for successful Ofborg evaluation and using tools like nixpkgs-review to identify potential issues.