Hi,
I re-send this announce [1] with a proper thread. In case it’s been
hidden by the initial top title of the thread.
GCD007: Teams, Special Teams and Memberships
Please comment by replying to this message or directly as a Review on
Codeberg <https://codeberg.org/guix/guix-consensus-documents/pulls/11>.
The Discussion period started on Sat, 28 Feb 2026.
The Discussion period ends, at best, on:
Monday, 30 March 2026*
Do not wait the last minute for commenting! Please remember [2]:
1. Be clear and explicit about what you are suggesting
2. Remain focused: do not change the scope
3. Ensure progress
4. Aim for finalization
5. Review is a discussion
The aim of the process is to end with a document we all can live with.
Cheers,
simon (as sponsor)
*Day: Décadi 10 Germinal an 234 de la Révolution, jour du Couvoir :-)
-------------------- Start of forwarded message --------------------
From: Gabriel Wicki <[email protected]>
Subject: [GCD007] Teams, Special Teams and Memberships
Date: Sat, 28 Feb 2026 21:47:28 +0100
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---
-------------------- End of forwarded message --------------------
1: [GCD007] Teams, Special Teams and Memberships
Gabriel Wicki <[email protected]>
Sat, 28 Feb 2026 21:47:28 +0100
id:[email protected]
https://lists.gnu.org/archive/html/guix-devel/2026-02
https://yhetil.org/guix/[email protected]
2: https://guix.gnu.org/manual/devel/en/guix.html#Reviewing-the-Work-of-Others
