maintainers/README: update guidelines around closed teams

This commit is contained in:
Emily
2026-01-11 15:23:42 +00:00
parent d9e058d773
commit ea17f27c98

View File

@@ -145,18 +145,11 @@ When adding users to [`maintainer-list.nix`](./maintainer-list.nix), the followi
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 judgment when deciding if a team is warranted.
Teams are allowed to define their own rules about membership.
Teams should be organised around areas of maintenance interest and expertise, rather than employer or participation in another project or organization.
For example, a team dedicated to maintaining support for a desktop environment or programming language in Nixpkgs makes sense, as does a team to maintain packaging of software from a given vendor, but a team exclusive to employees of a company or maintainers of another project does not.
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.
When reviewing changes to a team, request reviews from the existing team members.
Feel free to merge changes to the team if the existing members are unresponsive.
#### Synced GitHub teams