Hi, When I asked about if we need a policy for membership in https://lists.debian.org/debian-go/2026/06/msg00072.html, the main objection was that a policy might lead to an increased amount of work needed by current Go team members to maintain the team, or that new contributors might be put off by having to go through some procedures before they contribute.
Thus I wrote this in a way that adds minimal amount of new work and mainly makes explicit what we currently have so that the path for new members is more clear and predictable, everyone gets equal treatment, and Go team members don't have to waste time guessing what to do in various situations as they are all covered. Timing-wise I think this also needed to be ready for a potential new flood of prospective members and to establish a clear pool of team members so we can later organize votes on team matters. Below is my initial suggestion for the policy regarding team membership, followed by justifications: 1. Anyone is welcome to contribute to any Go team package by triaging and investigating bugs, suggesting fixes or updates by filing Merge Requests, or testing and commenting on any existing Merge Request. All of the above can be done with any Salsa account and does not require prior permission or special privileges. 2. Anyone is welcome to suggest new Go packages to be included in Debian, and to draft the packaging under their own Salsa account. To create a new git repository in the Go team namespace one needs to either be a Go team member, or file a repository creation request via flight-deck.debian.net and have an existing member approve it. In such cases the requester is granted the special Owner permission for this one repository with an expiry of 24 months. 3. To be able to merge and push commits to any Go package git repository one needs to be a Go team member. To get permission to merge and commit independently to Go package repositories, one needs to have demonstrated sufficient technical knowledge of Debian Go packaging, as well as good judgement in how to contribute in a way that is useful and helpful to fellow developers and Debian's users. To be eligible for such an assessment, one must have authored git commits that were included in at least 5 different packages, and contributed reviews, documented testing or debugging to at least 5 different Merge Requests or bug reports for Go packages in Debian, spanning at least 5 months. 4. Go team membership is applied by opening an MR on the 'members' git repository that adds a new file with the applicant's Salsa username and a free form attestation that the person has demonstrated they meet the requirements above. It can be merged and membership granted when at least two existing members, who have held the membership for over a year, give their approval. 5. Access to Go team infrastructure and tooling requires membership in the Go team admin group, and can be granted when two existing admin group members approve it, or if the Debian Project Leader so decides. 6. If a contributor has not utilized their Go team membership and participated in Go package maintenance during the development cycle of two consecutive Debian releases, they will be notified about pending membership expiration. After inactivity of three consecutive Debian release cycles, Go team membership can be revoked. After that becoming a member requires a new application and two approvals as for any new members, but demonstrating abilities is obviously much easier due to the existing track record of contributions. 7. Debian Developers, who can upload any package and thus bypass any Salsa access controls, shall be given Go team membership on request, without having to go through any new member approval process. Debian Maintainers will be granted full permissions to the specific git repositories for packages they can upload without requiring them to go through the new member process. Justifications: - Current blind trust makes it too easy for a malicious person to infiltrate. Git repos can be created without ever talking to anyone on the team. - Set expectations that team membership is for recurring contributions and any one-off work can be done without membership just as a regular open source contribution. - A bit of time and effort is a reasonable requirement in exchange of open source collaboration. - Progression of trust: one -> few -> all packages -> infra/tools - Several years of inactivity is a fair metric to remove memberships. - DDs are already trusted, so they can skip the process of building trust. Technically the GitLab membership system has no facility for recording who was added when and why. Therefore, if this policy gets support, I would implement a repository with a list of members that automatically syncs to the GitLab Go team membership. - Otto
