tweag-core team and tweagbot

[infinisil]

With my Tweag hat on, I'd like to get a confirmation from @NixOS/nixpkgs-core that:

• It's okay to create a @NixOS/tweag-core team, with me and @balsoft as initial members, as a subteam of the Nixpkgs maintainers team (so that the team can be requested for review)
• That the team can be added as a maintainer to various security-critical packages (aka "core packages") that we have funding to help maintain as part of Tweag, allowing us to get pinged for reviews

And for another @NixOS/org owner that:

• I can make the @tweagbot user an unprivileged organisation member, in order to unblock internal automation to ensure we can keep track of all the PRs/issues the team is requested for. We need this because only users within the org can search for e.g. team:NixOS/haskell ¹

Footnotes

1. And also team-review-requested:NixOS/haskell, for which https://github.com/NixOS/nixpkgs/issues/447514 would be great to distinguish automated team reviews requests from individual reviews requests. ↩

[Mic92]

Is membership in this team tight to be employed by Tweag or is it decided by the member of this team? It would be probably a good idea to clarify about this upfront.
For the bot itself, it might be helpful if it had a README and repo with a short summary of how it currently being used and who is in control of the account.

[infinisil]

It would be limited to only Tweag employees/contractors yeah, I'd add that to the description of it. And specifically only the people doing this core package security review.

The bot already has an account description containing the most relevant info, including a link to Tweag's Nix group whose lead (@balsoft) has control of the account. I think that should be good enough, and allows avoiding duplication of info.

[emilazy]

(Just a note that we’re reviewing this and will try to have a response posted soon, apologies for the delay!)

[emilazy]

After reviewing this, we believe it would be inappropriate to put corporate teams with external administration/membership criteria under the @NixOS/ namespace and that, in line with established practice in most aspects of Nixpkgs development, our written project values, and precedent from Linux kernel maintenance, participation in package maintainership should be on an individual basis, with teams organizing around specific areas of expertise and maintenance focus rather than corporate employment. We are of course very happy for companies to sponsor maintenance work on Nixpkgs and hope to see more of it, but feel that assignment and revocation of maintainer authority and organization of teams should be a matter for Nixpkgs, rather than being delegated to an external corporation based on its employment decisions.

We realize that corporate lib.teams.* entries are a pre‐existing reality that this request does not change by itself. However, we are sympathetic to @philiptaron’s concerns in NixOS/nixpkgs#447514 (comment) that it seems to imply an unusual amount of connection or endorsement between NixOS and a given organization, and believe that it makes sense to review the matter of corporate teams in general before signing off on further institutionalizing them.

Our guiding principle here is the project value of “People come first”:

We are here, first and foremost, as individuals working together. Our priority here is to work on Nix projects for the benefit of all their contributors and users. We value building excellent software with a vibrant and diverse community. Individuals gain trust and status by doing the work. Organisations gain prestige by funding the work of individuals and providing resources to support the project.

In accordance with these principles, we think that it makes sense for participation in Nixpkgs to be on an individual basis, and for Nixpkgs maintainer status, team membership, and package maintainer lists to be decisions internal to Nixpkgs itself. The role of organizations is then to support the work done by these individuals and the project more widely, rather than being a direct participant in the processes or making decisions about membership.

A large factor we considered is the authority of package maintainers. It’s unclear whether a corporate team being listed on a package gives that corporation a say in decisions relating to it, or whether it is just shorthand for the individual employees who work on it. There is also the matter of the Nixpkgs merge bot, which means that adding a person to a team can give them privileges to merge certain changes to packages. For ordinary packages and area‐specific teams, additions and removals of people with this access are subject to the review of the relevant maintainers. In practice, the criteria for the merge bot are designed to minimize the risk here, but they are still restricted to package maintainers for a reason. We feel that granting or removing merge rights or other non‐technical package maintainer authority based on employment status makes little sense.

We also feel that corporate maintainer teams haven’t seemed to work too well in practice; while it is natural for companies relying on Nixpkgs to have an interest in maintaining things that are relevant to them, it is also natural for different employees to have different areas of focus, and anecdotally we have not found corporate maintainer teams to be as responsive as we’d hope for on the whole.

We appreciate that this proposed team aims to mitigate that by being scoped to those employees working on a specific set of packages, rather than a blanket list of all employees who participate in Nixpkgs maintenance, and by establishing a round‐robin assignment process. However, we believe that insofar as the team has a coherent scope of maintenance, it makes sense to establish a general team around that scope rather than restricting it to Tweag employees, and that while the round‐robin review mechanism proposed here may help with distributing reviews and avoiding the bystander effect, the effect on triage should be comparable between corporate and non‐corporate teams.

We are careful to distinguish, here, between maintainer teams focusing on software produced by a corporation, and maintainer teams focused on software used by a corporation; we think the former make much more sense, as they are similar to other teams in being defined by the focus of their maintenance and having open membership, even if their members happen to currently overlap with employees of that corporation (although in general, we also think it is best for downstream packages to not be maintained solely by their upstream maintainers). For clarity, we also do not think this is specific to for‐profit corporations, and though we speak of “corporate teams” here, we believe the same arguments apply equally to teams defined by membership in non‐profit organizations, or even participation in a FOSS project – the distinction is whether the team is internal to Nixpkgs, or has membership dependent on some criteria external to Nixpkgs maintenance decisions.

A salient example of a large FOSS project with a formal list of area‐specific maintainers and heavy corporate involvement is Linux. In the Linux maintainer list, there are many maintainers affiliated with corporations, and it is no surprise that the maintainers of the Intel Xe and AMDGPU DRM drivers have email addresses at the corresponding companies, but they are listed solely as individuals. We believe Linux shows strong precedent for the model where maintainers are individuals and teams are organized by area of focus, even in an environment where many of the most active maintainers are doing it as part of their job. This gives us confidence that it makes sense to follow the lead of the project values here.

We do appreciate that adding individual maintainers to a wide variety of packages that share a common theme is tedious, and is the reason we have lib.teams to begin with. We think that where this arises, in a corporate context or otherwise, it’s a good opportunity to form teams around the relevant areas of expertise.

In this specific case, since the focus is on ensuring maintenance for certain core packages, there is overlap with the prospective team discussed at the recent NixOS Plumbers Summit – we plan to reach out to the participants to assist their effort to formalize the maintenance of the NixOS core and the packages it depends on. Of course, this may not have perfect overlap with the set of packages Tweag has funding to maintain, but we believe that funding employees to participating in teams relevant to corporate interests, and to participate as individual maintainers in other packages where there is no overarching theme, is the kind of sponsorship we would like to encourage – and that it should be the choice of the existing maintainers and team members whether to accept an individual employee’s offer to participate in maintenance, and the choice of the individual whether to continue maintenance even after they leave a company.

As our conclusions here have implications beyond this specific proposed team, and we don’t want to create a disparity by grandfathering in existing corporate teams, we plan to do a review and work with the members of those teams to figure out how best to redistribute their members to other teams and individual packages.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixpkgs-core-team-update-2025-12-20/73494/1