Hi Gabriel,
As sponsor I should not raise my voice too loud and try to keep the
discussion on rail. From what I’ve read, the discussion has been on
rail and has not required interventions aside being timekeepers.
That said, as expressed by people using different angles, I’m also
confused by this GCD. When reading the GCD, my impression is that the
GCD is trying to chase more than one rabbit and then I feel lost.
If I go straight to the point: When the Preamble is longer than the
Motivation, or when the Summary lists subsections, then it raises a flag
on my side.
Before specifically commenting, let me summarize what I think this GCD
is (or should be) about:
1. Make the concept of Team the keystone of Guix collaboration.
2. Clarify the role of the special Team “maintainer”.
Therefore, I would try to stick on the essential. Aside this, I think
it’d be one or more other GCDs.
I’ve commented inline but also attached below all the rewording I’m
proposing inside one file for easing the reading or the comments.
Well, it’s a proposal for trying to focus on one rabbit.
> # Preamble
> Like all things historically grown, information about social structure
> of the GNU Guix project is spread among multiple documents, to be
> found spread across multiple sections in the reference manual and in
> need of some clarification. This GCD aims to clean up and complete
> where necessary, so users interested in contributing can figure out at
> ease which roles they may want to take, how these interact with the
> other roles and where to turn when in doubt or distress.
I propose to skip the preamble and instead and a paragraph to the
Summary.
> # Summary
I propose to add this paragraph:
Guix organically grows: the structure of collaboration is evolving
and documented sometimes inside the reference manual, sometimes by
an implicit knowledge. This GCD aims to clarify the roles by making
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 and, how one
- can quit a role,
This GCD aims at formalising and improving the current roles and
Teams.
> ## Scope
I propose to drop the Scope, Goal and Innovation subsections and instead
have the paragraph above.
> ## Goal
I propose to skip because I miss what it brings concretely.
> ## Innovation
I propose to skip in order to keep the summary… a summary. :-)
> # 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,
> (informal) hierarchies are a fact and there is no way around it.
>
> To keep our spirit of enabling people to join us with ease, to
> contribute voluntarily without bureaucratic challenges or
> hard-to-guess social conventions, defining our social structure—the
> way it has been and will probably stay for the foreseeable future—will
> help newcomers and other interested people to find their way in.
>
> GCD007 is a cornerstone of social guidance for whoever wants to know
> who is in charge, how they can get more involved, whose opinion is
> asked in what matters or who has the final say in what situation.
I propose this wording:
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 could have an (active) relationship to each other member, to
now a number of contributors that makes hard to keep the organic
structure.
Enabling people to join us with ease, to contribute without
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 Team the cornerstone of Guix collaborations and it
clarifies their aims and organization.
For reference: This GCD is a extension of the following documents,
de-facto means of collaboration:
- [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")
> # Detailed Design
I propose to skip the three paragraphs and directly starts with the
subsection Roles.
And I’d move the reference to upper.
> ## Roles
I propose to skip all and reword as:
Nowdays, the Guix project mainly processes the contributions using
Teams. A Team is a sub-group of Guix community members with one
specific interest.
> ### Teams and team members in general
>
> - Teams are created by a proposal on the `guix-devel` mailing list,
> the consideration of input from other contributors, crafting a Pull
> Request adding the team and first members to `etc/teams.scm` and
> finally having the Pull Request pushed onto the `master` branch 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.
>
> - Teams take responsibility for specific aspects of the GNU Guix
> project.
>
> - Teams organize their work autonomously.
>
> - All teams and their memberships are defined and described in our
> main source code repository in the `etc/teams.scm` script.
>
> - Teams are founded after proposing the creation on the
> `[email protected]` mailing list and pushing a commit adding the
> team to `etc/teams.scm` with its initial members.
>
> #### Responsibilities and scope
>
> - 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-devel` mailing 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-devel mailing 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. This
> includes email as well as 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
I propose to skip since there is no “issue” and/or something specific to
decide about committer. The GCD is already large enough. If we want to
decide something about committer, I think it’s another GCD.
Well, committer might be mentioned in above Roles. For instance:
Nowdays, the Guix project mainly processes the contributions using
Teams. A Team is a sub-group of Guix community members with one
specific interest.
One team is special: the Maintainers team; described below.
A special group within Guix, namely *committer*, has the
responsibility to propagate the contributions by pushing the changes
to the repositories. It might be asked that any committer is part
of at least one team.
And I think committer should be mentioned in this GCD only because it’s
related to Team. IMHO, a team can only be fruitful if at least one
committer is part of the team.
> ### Maintainers
>
> The maintainers collective is another special team within the GNU Guix
> Project. It hold special authority about the projects infrastructure
> and finally grant applicants commit access (or refuse it). One can
> think of the maintenance team as the project lead—but only if the fact
> is disregarded that the GNU Guix Project organizes work from hundreds
> of contributors in a very decentralized way with maximal autonomy to
> whoever feels fit to take responsibility in the structure we created
> to do so: teams.
>
> Memberships of the maintainers collective—or the *maintainer's
> team*—are pledges to the project for one-year terms. The maintainers
> collective report about their annual activity and suggest for approval
> the composition of their team for the upcoming term in a GCD. 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.
>
> #### Approval
>
> - The maintenance team crafts a yearly addendum to a GCD to approve
> their next terms in the group they feel fittest for the task.
>
> Anyone can apply to join the maintainer's collective at any time by
> reaching out to them (see below).
>
> - Should serious issues emerge, the maintainer's collective can be
> (partially) replaced by a GCD.
This section isn’t doable in practise. Or even, I’m sure it’s the way
I’d like for the project. Well, I propose:
- Being part of the Maintainers team is a multi-years commitment.
- The rotation of the collective is always partial. The team is
never composed by all new members.
- The collective is composed to up 5 members. For joining, the
- applicant must be publicly vouched by at least 5
committers.
> #### Responsibilities and scope
>
> - Grant commit access to prospects.
>
> - 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.
I propose this wording
- Enforce Guix policies. This includes, among others, communicating
for applying the accepted GCDs, 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 `[email protected]`. 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.
>
>
>
> # Drawbacks and Open Issues
>
> ## Team dissolving Under what circumstances should who be able to
> dissolve unnecessary, obsolete or defunct teams? Should we leave the
> ruling as it currently is and postpone such a discussion to future us?
> Would a ruling that a team that is inactive or unresponsive for
> several months can be dissolved sensible and adequate?
>
> ## Maintainer's reachability What can be expected? What are current
> response times?
>
> ## Emergency replacement of (parts of) the maintainers collective
> Should serious issues with (parts of) the maintainers collective
> emerge (individual members blocking duties, hindering progress,
> actively working against our project's principles, etc) starting a GCD
> process about the issue seems like the adequate thing to do. The GCD
> might not be fast enough, though. If the worst came to the worst, we
> could end up without a working maintainer's collective until we reach
> consensus in the GCD process (which takes at least three months).
>
> Maybe a 2/3 vote within the maintainer's collective could do the trick
> to relieve the collective of being bricked? I'm just spit-balling
> here, any and all input is much appreciated. --8<---------------cut
> here---------------end--------------->8---
Well, I’d like to propose more rewording but I’m running out of time…
Anyway. :-)
Cheers, simon
- - -
title: Teams, Special Teams and Memberships
id: 007
status: discussion
discussion: https://codeberg.org/guix/guix-consensus-documents/pulls/11
authors: Gabriel <gabber> Wicki
sponsors: zimoun
date: 26-02-28
draft-date: 26-02-18
discussion-date: 26-02-28
deliberation-date: <date when the deliberation starts>
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later
---
# Summary
Guix organically grows: the structure of collaboration is evolving and
documented sometimes inside the reference manual, sometimes by an implicit
knowledge. This GCD aims to clarify the roles by making 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 and,
- how one can quit a role,
This GCD aims at formalising and improving the current roles and Teams.
# Motivation
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 could have an
(active) relationship to each other member, to now a number of contributors
that makes hard to keep the organic structure.
The 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.
The main issue is that the information required for contributing 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 maintainers and their
scope isn’t formally defined.
This GCD makes Team the cornerstone of Guix collaborations and it clarifies
their aims and organization.
For reference: This GCD is a extension of the following documents, de-facto
means of collaboration:
- [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")
# Detailed Design
## Roles
Nowdays, the Guix project mainly processes the contributions using Teams. A
Team is a sub-group of Guix community members with one specific interest.
One team is special: the Maintainers team; described below.
A special group within Guix, namely *committer*, has the responsibility to
propagate the contributions by pushing the changes to the repositories. It
might be asked that any committer is part of at least one team.
### Teams and team members in general
- Teams are created by a proposal on the `guix-devel` mailing list,
the consideration of input from other contributors, crafting a Pull
Request adding the team and first members to `etc/teams.scm` and
finally having the Pull Request pushed onto the `master` branch 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.
- Teams take responsibility for specific aspects of the GNU Guix
project.
- Teams organize their work autonomously.
- All teams and their memberships are defined and described in our
main source code repository in the `etc/teams.scm` script.
- Teams are founded after proposing the creation on the
`[email protected]` mailing list and pushing a commit adding the
team to `etc/teams.scm` with its initial members.
#### Responsibilities and scope
- 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-devel` mailing 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-devel mailing 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. This
includes email as well as 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.
### Maintainer team
The maintainers collective is another special team within the GNU Guix
Project. It hold special authority about the projects infrastructure
and finally grant applicants commit access (or refuse it). One can
think of the maintenance team as the project lead—but only if the fact
is disregarded that the GNU Guix Project organizes work from hundreds
of contributors in a very decentralized way with maximal autonomy to
whoever feels fit to take responsibility in the structure we created
to do so: teams.
Memberships of the maintainers collective—or the *maintainer's
team*—are pledges to the project for one-year terms. The maintainers
collective report about their annual activity and suggest for approval
the composition of their team for the upcoming term in a GCD. 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.
#### Approval
- Being part of the Maintainers team is a multi-years commitment.
- The rotation of the collective is always partial. The team is
never composed by all new members.
- The collective is composed to up 5 members.
- For joining, the applicant must be publicly vouched by at least 5
committers.
#### Responsibilities and scope
- Grant commit access to prospects.
- Enforce Guix policies. This includes, among others, communicating for
applying the accepted GCDs, 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 `[email protected]`. 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.
# Drawbacks and Open Issues
## Team dissolving
Under what circumstances should who be able to dissolve unnecessary,
obsolete or defunct teams? Should we leave the ruling as it currently
is and postpone such a discussion to future us? Would a ruling that a
team that is inactive or unresponsive for several months can be
dissolved sensible and adequate?
## Maintainer's reachability
What can be expected? What are current response times?
## Emergency replacement of (parts of) the maintainers collective
Should serious issues with (parts of) the maintainers collective
emerge (individual members blocking duties, hindering progress,
actively working against our project's principles, etc) starting a GCD
process about the issue seems like the adequate thing to do. The GCD
might not be fast enough, though. If the worst came to the worst, we
could end up without a working maintainer's collective until we reach
consensus in the GCD process (which takes at least three months).
Maybe a 2/3 vote within the maintainer's collective could do the trick
to relieve the collective of being bricked? I'm just spit-balling
here, any and all input is much appreciated.
