Teams, Special Teams and Memberships
by Gabriel <gabber> Wicki —
sponsored by Simon <zimoun> Tournier
Withdrawn
Timeline
18 February
drafting28 February
discussion01 May
deliberation15 May
withdrawn
Summary
Guix organically grows: the structure of collaboration is evolving and documented both inside the reference manual and within implicit knowledge. This GCD clarifies the different roles by summarizing the agreed upon social structure and appending necessary parts in the reference manual. It makes Teams the keystone of Guix collaboration.
Specifically, the scope of this GCD is to lay out:
what each role entails,
what the project expects from which role and their members,
how one can take a role,
how one can quit a role and
under what circumstances and by whom membership of a role can be terminated.
GCD007 formalises the currently existing roles in teams as completely and exhaustively as currently possible. It only adds information to or changes information in the reference manual where necessary: these parts are marked specially.
Motivation
GNU Guix is a growing project with a strong emphasis on consensus and mutual help. We have grown past a size where each member of the project can have an (active) relationship to each other member, to a number of contributors that makes it hard for the project to keep growing organically.
Enabling people to join us with ease, to contribute without unnecessary overloads or hard-to-guess social conventions, to engage the collaboration is the heart of free software project. The main issue is that the information is spread across multiple sections in the reference manual or even on informal blog posts. It might be difficult to have a clear picture of the collaboration structure. For one example, how a new Team is created or deleted is not documented. It’s not clear either how to join a Team and what is expected for a Team member. For another example, the collective of maintainer and their scope isn’t formally defined.
This GCD makes teams the cornerstone of Guix collaborations. It clarifies their aims and organization.
For reference: This GCD takes up work previously written down in:
and this blog post
Roles
Nowdays, the Guix project mainly processes the contributions through teams. A team is a sub-group of Guix community members with a clearly specified interest, task or responsibility.
Teams and team members
Teams describe the fundamental sub-group in the GNU Guix community:
every sub-group describes a team and every team is listed in the
repository's etc/teams.scm script.
What will be changed in the manual:
The `Teams' chapter will be rephrased to include the more general cases of teams and their responsibilities (i.e. non-code and special teams).
The paragraph on team creation will be refined as to reflect:
- the fact that all groups are now considered teams,
- teams take responsibility towards aspects of the project, not only modules in code,
- the hereby specified process for team creation and
- a general approach for team disbanding.
Reachability expectations will be specified.
Team creation, definition and disbanding
Teams are created by a proposal on the
guix-develmailing list, the consideration of input from other contributors, crafting a Pull Request adding the team and first members toetc/teams.scmand finally having the Pull Request pushed onto themasterbranch of the GNU Guix main source code repository.Generally, establishing new teams should be welcomed. Any and all contributions to our project should and will improve our project for the greater good. Other contributors shall help to adequately phrase a new team's scope, find other (potential) members and connect existing, concurrent efforts in a way that enables collaboration and prevents unnecessary duplication of labor.
All teams and their memberships are defined and described in our main source code repository in the
etc/teams.scmscript.Teams can be disbanded when they have been inactive or unresponsive for several months or their purpose has dissolved. The process to disband a team is started through a discussion thread on the
guix-develmailing list with a CC to each team-member to see whether disbanding completely, dissolving into other teams or changing the scope is the best way to go forward.
Responsibilities and scope
Teams take responsibility for specific aspects of the GNU Guix project.
Teams organize their work autonomously.
Except for the special teams defined below, teams define the scope of their responsibilities (which packages, modules or other aspects of the project) collectively within the team.
Changes to a team's scope—especially diminishment of the scope and particularly unintuitive changes—should be announced to the
guix-develmailing list.
Team membership
Teams are generally open for new members to join, but current team members retain the authority over timing and procedures when onboarding new members. Delaying on-boarding can be necessary for teams that take on time-bound tasks (e.g. the release team during an intense phase of a release cycle).
Team members can leave teams at will.
Team membership first and foremost expresses interest in specific aspects of the GNU Guix Project. Generally no level of expertise is necessary to join a team (this of course is not valid for the special teams, see below).
Team members are expected to take part in their team's scope of work. Inactive team members may be removed.
Team members are expected to take part in ongoing discussions on the
guix-develmailing list. They are expected to voice their opinions in discussions and take part in our consensus-finding process (GCD).All team members should strive for consensus finding rather than pushing for their preference(s) when dissent or confusion about issues emerge.
Reachability
Teams are expected to be reachable and respond to communications both from within as well as from outside of the project by email, and for code-related teams Codeberg, through their team's label.
This is necessary to ensure that the team's expertise can be queried from within the project and the team can be informed with information from the outside.
Committers
People with Commit Access make up a special group within the GNU Guix Project. Through continuous contributions they have proven themselves worthy of the authority to push commits directly onto our repository's branches. This is not to be thought of a "badge of honor" but rather a responsibility they take towards the project.
Since committers are the oldest and best documented de-facto sub-group in the GNU Guix project, not much has to be changed in the manual. What will be changed in the manual, though, is the following:
Committers will be coined as a special team.
Active, passive and inactive committers will be distinguished.
A paragraph on the project's expectations towards reachability and staying up to date with discussions of committers will be added.
The committers team will be created in etc/teams.scm.
Active, Passive and Inactive Committers
Having commit rights does not imply 24/7 monitoring of all of GNU Guix activity. Hence we distinguish:
Active committers are people with commit rights following the Project and currently able and willing to push changes to the main branches of repositories.
Passive committers are people that currently hold commit rights but are unreachable or otherwise unavailable to use their responsibility.
Note: passive committers are committers during a weekend offline, while sick or intoxicated and either unable or unwilling to hit the keyboards or just too busy with other responsibilities to work on Guix. Their state is changed back to "active" as soon as work is taken up again.
Inactive committers are long-time passive committers: members of the committers group that do not take up their work as committers for the project. Their commit access will eventually be revoked.
Filing
Commit access of a contributor is filed in the following three places:
The committer is added to the committers team in
etc/teams.scm.A committer's OpenPGP public key is added to the main repositories
keyringbranch of the main repository.The commiter's OpenPGP fingerprint is added to the .guix-authorizations file of the branch(es) they will commit to.
Gaining and losing Commit Access
To become a committer one should have proven oneself to the community to know what GNU Guix is, what it stands for, that one supports the project's mission, that one is acting in good faith and that one knows their way around our ways of collaboration.
Frequent, known contributors can apply for commit access. They shall have accumulated 50 reviewed commits and have sustained activity in the project for at least 6 months. When they find three committers to vouch for them they can officially apply with an email stating their intent, listing the three committers who support their application and giving their key's fingerprint to the maintenance team (see below), all signed with their OpenPGP key.
The maintenance team will ultimately decide whether to grant them commit access and add them to the committer's team.
It is expected from new committers to send a message to guix-devel@gnu.org mailing list introducing themselves and stating the fact that they just joined the committers team, also signed with their OpenPGP key.
Committers can lose their commit access when they violate their responsibilities or are inactive for several months.
Responsibilities and scope
Committers sign and push commits to the Guix repository's main branch
master. Since with everyguix pullcommand this code is automatically distributed to innumerable systems around the globe, actions coming with this responsibility have to be considered and checked carefully. Although most (if not all) possible mistakes can be reverted, a single, malicious commit tomastercould jeopardize our means of computation, destroy our reputation and mean a factual end to this endeavor.Committers inform themselves about the current situation of the project by reading up on the
guix-develmailing list.Committers should be part of other teams. Teams without committers have to look for external helpers with commit access which can be tedious. Committers are expected to empower others.
Committers push changes to
masteras described in the `Commit Policy' section of the manual.When in doubt about non-time-critical contributions, committers are expected to encourage consent-finding, rather than opting for one specific solution.
Reachability
Active committers should try, to the extent of their availability, to be reachable by email. This is particularly important after pushing changes to the main branch. Such changes may cause breakages and their insight can be useful in repairing them.
Active committers should be informed about ongoing discussions on the
guix-develmailing list.Committers commit to take note of messages on
guix-develmarked with a[COMMITTERS]or similar prefix in the Subject: line with a frequency of at least 7 days. This ensures that all active committers take note and can respect imposed restrictions that are taken by other committers (like a push freeze to themasterbranch prior to a release).Passive committers are required to read up on discussions and inform themselves about the current state of affairs before taking up their work as committers and pushing changes to protected branches.
Maintainers
The maintainers collective is another special team within the GNU Guix Project. It holds special authority about the projects infrastructure and finally grants applicants commit access (or refuse it). One could think of the maintainers collective team as the project lead—but only if the fact were disregarded that the GNU Guix Project organizes work from hundreds of contributors in an extremely decentralized fashion, granting maximal autonomy to whoever takes the responsibility in the structures intended to do so: teams.
Memberships of the maintainers collective team are pledges to the project for one-year terms. The maintainers collective reports their annual activity and suggests the composition of their team for the upcoming term for approval. This should not be mistaken as general elections and a basis to spread discontent, but rather set a framework to have a regular flow of information from the maintainers to the project in its breadth and to enable the project as a whole to approve of the maintainers collective's work.
Maintainers are long-time committers to the GNU Guix Project, trusted individuals that have proven commitment to our cause time and time again.
What will be changed:
A section (or chapter) is added to the reference manual summarizing adequately everything described here (currently no such section exists).
The maintainers team will be created in
etc/teams.scm.
Activity Report and Approval
The maintenance team crafts a yearly report of their activity with a proposal for the composition of the team for the next period. This report shall then be approved of—not unlike the deliberation period of the GCD process—by the community made up of team members.
People interested in joining the maintainers collective shall reach out to the maintainers team directly.
Responsibilities and Scope
Grant commit access to contributors (see Committers section, above).
Enforce Guix policies. At the time of writing, this includes, among others, ensuring Guix is released under a copyleft license (GPLv3+), moderating communication channels and enforcing the code of conduct.
Keep the authority over the GNU Guix Project's resources and infrastructure, like the mailing lists, the IRC channel, the Codeberg organization and repositories.
Reachability
- Maintainers are reachable through
guix-maintainers@gnu.org. The maintainer's collective is expected to acknowledge queries within 24 hours and (at least initially) respond to queries within a week.
Cost of Reverting
Reverting this GCD comes at the cost of having to discuss and define GNU Guix Projects social structure more adequately than how we managed to do in this GCD.