Hi there! With zimoun sponsoring this GCD (if no one else will) and my major rework of the draft, I am happy to announce that this GCD shall enter discussion phase.
The GCD will mainly ratify our current state of the art (both de-facto and de-jure), but comes with some innovation where our current situation lacks adequate definition. With this GCD every sub-group of our project will by definition be a "team". Committers and Maintainers become special teams, where special rules apply. These roles come with special responsibilities and (like it has already been) special ways to take these roles. Please join the discussion either here or on Codeberg: https://codeberg.org/guix/guix-consensus-documents/pulls/11 You may find the text of the revised, current version below. Looking forward to your input! gabber --8<---------------cut here---------------start------------->8--- # Preamble We are an exponentially growing community with hundreds of contributors. The project has grown far beyond what is overlookable by individuals. We have been on a continuous venture to recruit users to become contributors, which helped us not only grow in numbers but grow in overall quality of our software. We have grown from initially 4 contributors in 2012 to 103 in 2016 to 438 in 2025. Maintenance was collectivized, a consensus-finding process was introduced. Ratifying roles is a first step in shaping expectations, clarifying means of collaboration and paving the way we will write history. # Summary This GCD ratifies how currently work is coordinated within the GNU Guix Project. It is an amalgamation of the de-facto status quo and written documentation that is considered to be in effect. It lays out - what each role entails, - what the Project expects from which role and their members, - how one can take a role and - how one can discard it again. Expertise and special responsibilities is bundled in teams. Generally, teams form themselves and define their scope themselves. There are a bunch of special teams, though for which separate rules apply. # Motivation In the GNU Guix Project we collaborate with an emphasis on inclusion and mutual respect. Non-violent communication is a key prerequisite, as is a culture of collective growth—opposed to cultures of individual shaming: mistakes are human, errors happen and we all fail from time to time. It is key for a project like ours that more experienced participants empower newer users and contributors, the time to define roles and memberships adequately. It is key for prospects to know how they can contribute, where they can take part in this wonderful project of ours, hence we shall define it. This GCD is first and foremost a ratification of what already came to be with some accurate definitions in places where the current descriptions of the mentioned roles can be improved. # Detailed Design Through this GCD we shall agree on kinds of roles and procedures how roles can be taken (and discarded) by individuals. Upon acceptance the reference manual will be expanded altered to link to this GCD by the documentation team within a month. For reference: This GCD is an amalgamation of the following documents, perceived de-facto means of collaboration and the discussions that took place prior and during composition of this very GCD. Especially the following sections in the manual: - [Teams](https://guix.gnu.org/manual/1.5.0/en/guix.html#Teams "Contributing: Teams") - [CommitAccess](https://guix.gnu.org/manual/1.5.0/en/guix.html#Commit-Access "Contributing: Commit Access") and this blog post - [Maintainers](https://guix.gnu.org/en/blog/2019/gnu-guix-maintainer-collective-expands/ "GNU Guix maintainers collective expands") Since this GCD does not describe a (future) process, this document (in its final form) will be the Detailed Design, the ratification of the roles and their responsibilities within the GNU Guix Project. ## Roles The GNU Guix Project lives from voluntary contributions. It is a core value to enable and empower any and all people to contribute to our project, however they feel most comfortable. Contributions shall always be welcome from wherever they emerge. >From the project's view it is necessary to know who to talk to for expertise, know who is in charge over specific parts of infrastructure or moderation, or who will craft the next software release. All sub-groups of the GNU Guix Community are `teams`. Most `teams` tend to a specific area of the GNU Guix source code repository, but some teams have a special importance to the project and need to be bound to fixed-terms to keep our structure alive and prevent social ossification. This GCD will first elaborate on Teams in general—voluntarily and even spontantaneously formed sub-groups of the community—and then about special teams, where we, the GNU Guix Project, delegate specific power to people to be agreed upon through an annual update of a GCD. ### Teams and team members in general - Teams and their memberships are defined and described in our main source code repository in the `etc/teams.scm` script. #### Responsibilities and scope - Teams take responsibility for specific aspects of the GNU Guix Project. They define the scope of their responsibilities (which packages, modules or other aspects of the project) collectively. Teams organize their work autonomously. ### Team memberships - Teams are generally open for new members to join, but current team members retain the authority over timing and procedures when onboarding new members. - Team membership first and foremost expresses interest in specific aspects of the GNU Guix Project. In the default case, no level of expertise is necessary to join a team (see following sections for examples of special teams). - Team members are expected to take part in their team's scope of work. - Team members are expected to take part in ongoing discussions on the guix-devel mailing list. They are expected to voice their opinions in our consensus-finding process (GCD). - All team members should strive for consensus finding rather than pushing for what they perceive to be the best solution 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. This includes email as well as Codeberg, through their team's label. ### Committers People with Commit Access make up a special team within the GNU Guix Project. Through continuous contributions they have proven themselves worthy of the authority to push commits directly on our main repository's master branch. This is not to be thought of a "badge of honor" but rather a responsibility they take towards the project. Having commit rights does not imply 24/7 monitoring of GNU Guix activity. Hence we distinguish: - Active committers are people with commit rights following the Project and 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. #### Filing - The committer is added to the committers team in `etc/teams.scm`. - A committer's OpenPGP public key is added to the main repositories `keyring` branch of the main repository. - The commiter's OpenPGP fingerprint is added to the .guix-authorizations file of the branch(es) you will commit to. #### Gaining and losing Commit Access To become a committer one should have proven themselves to the community to know what GNU Guix is, what it stands for, that they support our mission, that they are acting in good faith and that they know their way around our ways of collaboration. - Frequent, known contributors can apply for commit access. They shall have accumulated 50 reviewed commits, 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 your intent, listing the three committers who support your application and giving your key's fingerprint to the maintenance team (see below), all signed with their OpenPGP key. The maintenance team will ultimately decide whether to grant you commit access and add you to the committer's team. - It is expected from new committers to send a message to [email protected] mailing list introducing yourself and stating the fact that you just joined the committers team, also signed with your 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 reposity's main branch `master`. Since this is code automatically (with every `guix pull` command) is distributed to innumerable systems around the globe, actions coming with this responsibility have to be considered and checked carefully. Altough most (if not all) possible mistakes can be reverted, a single, malicious commit to `master` could 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. - 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 `master`. These changes are either peer-reviewed and by the responsible team readied pull requests or hot-fixes that need to reach the main branch as quickly as possible. - 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 are reachable and respond (if necessary) to direct emails within 24 hours. This should ensure getting insight about incidents they are involved in. - Active committers should be informed about ongoing discussions 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 the `master` branch prior to a release). ### Moderation The moderation team is a special team that overlooks our channels and enforces our Code-of-Conduct. #### Responsibility, scope - Enforce our Code-of-Conduct within our official project channels. ### Maintainers Maintainers are another special team within the GNU Guix Project. THey hold special authority about the projects infrastructure and finally grant prospects commit access (or refuse it). One can think of the maintenance team as the project lead—but only if the fact is considered, that the GNU Guix Project works very decentralized with maximal autonomy to whoever feels fit to take responsibility (in teams). Membership of the maintenance team are pledges to the project for 1 year terms. Maintainers offer themselves as candidates in an appendix to a GCD. Maintainers are long-time committers to the GNU Guix Project, trusted individuals that have proven commitment to our cause time and time again. #### Approval - The maintenance team crafts a GCD to approve their next terms in the group they feel fittest for the task. - Should serious issues emerge, the maintenance team can be (partially) replaced by a GCD. #### Responsibilities and scope - Grant commit access to prospects (see Committers section, above). - Enforce GNU and Guix policies, such as the project’s commitment to be released under a copyleft free software license (GPLv3+) and to follow the Free System Distribution Guideline (FSDG). - Keep the authority over the GNU Guix Project's resources and infrastructure. #### Reachability - Maintainers are reachable through `[email protected]`. ## Cost of Reverting Reverting this GCD comes at practically no cost, we will simply return to the current status quo, which is not so bad after all. # Drawbacks and Open Issues --8<---------------cut here---------------end--------------->8---
