Thanks for this Gabriel and Simon, I've put some comments below. Simon Tournier <[email protected]> writes:
> --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 overlookable isn't a common word as far as I'm aware. I'm also not sure what the point is here. Is this something about the necessity of subdivisions between contributors (teams)? > 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 Have we? What activity stands out to you most as being the "continuous venture" you mention? > 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. We already have documentation on expectations on people and processes as far as I'm aware, e.g. https://guix.gnu.org/manual/devel/en/html_node/Making-Decisions.html as just one example. > # 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 "The GCD process is intended to provide a consistent and structured way to propose, discuss, and decide on major changes affecting the project" It's not a body or process to ratify things. > - 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. The last part of this sentence doesn't seem to relate to the first part? > 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. Is "prospect" a new role being proposed here? And again, the GCD process is about major and significant changes, not to replace existing documentation or information available elsewhere. I don't even know what is meant by "ratification" in this context. > # 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. We already have problems with other GCD's where reality is diverging, and there seems to be a lack of clarity on how exactly to handle this. We already have the ability to iterate and improve on the reference manual, so moving content in to a GCD would just hamper any changes or potential improvements (at least at the moment). > 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. This seems rather vague, the point above says teams are expressions of interest not taking part in work, and what does taking part mean specifically? > - 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. So the team is expected to be reachable, above and beyond the team members. What does that look like? Is some subset of members appointed as a representative, do we give team members a team email address they can share, or something else? > ### 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. I much prefer the existing text on this at https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html rather than "continuous contributions they have proven themselves worthy of the authority to push commits directly on our main repository's master branch". As it states "However, note that the project is working towards a more automated patch review and merging system, which, as a consequence, may lead us to have fewer people with commit access to the main repository. Stay tuned!". Personally I still want to see a world where people without commit access are better supported, rather than ending up in a state where you can't get stuff done unless you have commit access. The existing documentation we have sets out a better situation in my opinion, setting out the limited circumstances in which commits should be pushed directly to master, rather than the unconstrained "authority to push commits directly on our main repository's master branch" described here. > 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. The paragraph above doesn't really set out clearly what this responsibility is, apart from trying to reframe the authority they've proven themselves worthy of as a responsibility, which doesn't really make much sense to me. > #### 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 What's a frequent but unknown contributor? > 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. This is the first time I'm hearing of the "maintenance" 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. I much prefer the current documentation https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html#Commit-Revocation > #### 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. I much prefer the current documentation we have on this https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html#Addressing-Issues > - 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). This seems like the wrong tool for the job. In a world where people raise Pull Requests for changes, rather than pushing directly to master (for anything other than trivial or obvious changes), and we have sufficient tooling to do some minimal checks on the changes in Pull Requests, then this polling of ongoing discussions become unnecessary. The relevant Pull Requests can be automatically marked as not being able to be merged if and when that's appropriate. > ### 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 I'm not sure Maintainers or Maintainers team and "maintenance team" can be used interchangeably without causing confusion. > 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. Candidates for what? I don't get this last sentence. > Maintainers are long-time committers to the GNU Guix Project, trusted > individuals that have proven commitment to our cause time and time > again. I dislike this framing. I see advantage and other projects (like Debian for example) seem to as well, of trying to empower contributors that might not want to just do more through say getting commit access. > #### 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. I'm unsure if there's a significant overlap between the current technical focus of the process and what you're proposing here about making decisions regarding people. Why is the GCD process suitable and prefered for both these things? > #### Responsibilities and scope > > - Grant commit access to prospects (see Committers section, above). This "prospects" thing has come up above, and I'm not sure I like it. What's wrong with the term "contributor"? > - 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. What resources and infrastructure does the project have currently? My understanding is that resources and infrastructure generally are held by the Guix Foundation, which has it's own roles and processes. > #### 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--- ... I guess there's a couple of "major changes" being proposed here: - Moving information about roles and responsibilities from the manual and elsewhere in to a GCD. - Changing and adding to this in several ways As described above, I'm unsure what the advantages of the move are, and speaking as someone who's previously sent patches to various bits of documentation, I wouldn't know how to do similarly if it was in a GCD, and that lack of ability to change things going forward concerns me. I also have concerns about the substantive changes, as I've mentioned above. I think there's definately scope for improvement around "Maintainers", and maybe a GCD is even the right way of proposing something around that, but if so, I think it should be a standalone thing and not bundled in here. I definately agree with the sentiment around "more experienced participants empower newer users and contributors", but things like trying to improve code review processes and tooling seem like the bottleneck here. I see "roles and memberships" as having more potential to get in the way of people participating and contributing, rather than enabling it. For example, I've had people dismiss my reviews of patches/Pull Requests based on my lack of membership in the relevant teams, rather than the substance of the review. Thanks again, Chris
signature.asc
Description: PGP signature
