Gabriel Wicki <[email protected]> writes: > Christopher Baines <[email protected]> writes: > >>> # 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)? > Teams, committers and the maintainers collective are facts, but they > mostly "came to be" instead of having found consensus about how we all > can agree on what and how they should be. This is the (main) incentive > for this GCD.
I'm not sure I agree, I think at least teams have arisen from consensus, just in a less formal way than a GCD, but that doesn't mean it's any less authoritative. But my question here was about what is meant by this sentence: "The project has grown far beyond what is overlookable by individuals". >>> 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? > Maybe we have not. It was my understanding to try to be as welcoming > and as easy for "outsiders" to contribute, but I could certainly be > wrong. Or is it my wording that is putting you off? If so, please > excuse me. As you know I am no native English speaker and I am > certainly happy for input to adjust the language used here to the > general tone of the project. I think there's quite a gap between being welcoming, and a "continuous venture to recruit users to become contributors". The wording is a bit complex for my liking though, I think simpler language would be better, and I'm also not sure if this is necessary to explain or support the rest of the GCD. >> What activity stands out to you most as being the "continuous >> venture" you mention? > Accepting anonymous patches through email, documenting processes so that > newbies are supposed to understand and be able to follow them, be > helpful and inviting in our communication (mailing lists and IRC), ... > Did I misinterpret this sentiment? Right, maybe those things are true, but that doesn't seem like a continuous venture to me, but this is where simpler more explicit language would be better. >>> 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. > Yes. And (as stated under "Detailed Design") this GCD is an > amalgamation of already documented things, with the intention to sharpen > definitions where they are unclear, non-exhaustive or missing. > > I understand that this will lead to discussions (hence this process and > procedure), which is exactly the point. > > >>> # 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. > It is a body and process to **find consensus** and have it written down. > Maybe my understanding of the verb to ratify is wrong? Sorry, again, I > am no native speaker. By "ratify" I meant write it down (as a result of > the consensus finding process) and being able to refer to it as a whole, > in one central place, with the knowledge that we (as a community) agreed > on it. To me the word has more legal connotations. Maybe it can be replaced by "decide" since this is the language that GCD 001 uses? >>> 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? > Yeah, something seems missing there (: thanks for pointing it out! > >>> 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? > No. It is the way I call "users" that we do not try to "keep" in their > consumer-like role but encourage to help us improve affairs. Does that > word sound wrong? Do you have better suggestions? I think I'd say "potential contributor" for this, and if that's a bit too ambiguous, I'd explicitly say "to help users become contributors", or something like that. Spelling out meaning through explicit simple language is easier in my view. >> And again, the GCD process is about major and significant changes, not >> to replace existing documentation or information available elsewhere. > You are right, GCD001 mentions to only be there for *significant* > changes, but this seems silly. We have a structure that seems sound and > good, but we should probably find consensus about some details that are > not yet or not exactly specified. We currently have no process to find > consenus that is not GCD. Should we dismiss this GCD because it > violates GCD001's intention? I would argue that we do have processes to build consensus outside of the GCD process, the main one being patch review. I think https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48696 is a reasonable example of this in the context of roles and responsibilities. >> I don't even know what is meant by "ratification" in this context. > Again: my bad. Am looking forward to your suggestions. I would suggest to use "decide" instead, but I don't think that gets your point across in this instance, because I think we have a disagreement about how consensus and decisions have been made prior to GCDs. In my view there is some consensus and decisions have been made regarding at least some of the things that you're referring to "ratifying". >>> # 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. > Then we should maybe start discussions and address these issues, no? Discussions have already been happening as far as I'm aware, at least I overheard some at the Guix Days last month, but I'm unsure if there's an open issue or something relating to 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). > Not sure if I agree here. Would you suggest addending accepted GCDs to > our reference manual, so the manual stays the one, central location to > gain insight and look stuff up? > > Also, the documentation (not just the manual) need drastic overhauling: > it all just keeps growing in all directions and needs some tidying up.. > Volunteers welcome and much needed. To me the GCDs seem like a process and record relating to a decision made at a point in time. This is very different from the manual which is a living document which can change constantly. To me this has implications on the decisions that should be made through GCDs, at least in my view it would be good to explicitly say if decisions that are made are just for that instance, or an ongoing commitment. For me it would make more sense for say a GCD to decide to change something major in the manual, rather than attempt to move stuff from the manual to the GCD. At least while there's this uncertainty about how accepted GCDs should be treated going forward. >>> - 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? > Since team members are the ones taking part in the GCD processes it felt > necessary to draft what is expected of team members in a generally valid > sentence: hence this phrase. Since teams define their scopes and > organize their work autonomously (this is how I perceive the state of > the art currently) it seems hard to be more specific. But it also seems > necessary to state this to have means to remove "stale" members. > > @civodul had their comments to the same phrase here: > https://codeberg.org/guix/guix-consensus-documents/pulls/11#issuecomment-11169389 > > I have written this sentence to have a means to remove members from a > team that only want to be team members to participate in GCD processes > (where they, in the worst case scenario, just "disapprove" and troll our > consensus finding). It may well be out of place here. If that's your intent, I'd write something like that. So phrase it around inactivity or a lack of involvement, rather than an expectation of doing work. >>> - 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? > I wanted to specify that teams (or: their members) are supposed to (at > least) look at issues and PRs that get their label. If that's important to you, then I'd say that explicitly. > The intention here was that I could refer to some friend interested in, > let's say, Python specifics to reach out to our Python team. Or the > bootstrapping team. Or that people interested in audio on linux(-libre) > systems could reach out from the outside of the project to the audio > team. It was phrased with the idea in mind that we probably should ease > of reaching team members from the outside a bit. Of course I can tell > people interested (or with fresh new takes on) bootstrapping to clone > our repo and run this set of `./etc/teams.scm` invokations just to get > an email header where they can copy-and-paste the relevant addresses to > reach the right people, but we may lose their interest. > > As discussed elsewhere I would find it adequate for teams to define and > use their own channels of communication (and consensus finding). I > think some teams currently lack this. > > It is my understanding that a project like ours should not only strive > to optimize our source code repository but also tend to the knowledge we > gather and share it to the broader free software world out there. For me this more general referring people to teams thing seems like an unnecessary detail. >>> ### 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". > I agree that my phrasing is not very inviting. > > Currently, Commit Access is "convenient" for "frequent contributors". > I think this distorts the image of Commit Access being first and > foremost being a responsibility towards the project and GNU Guix users. I think our views on this are similar, I view commit access as a responsibility to review and merge the work of others, rather than the ability to push your own work, with or without review. >> 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!". > This is my ~6th year of staying tuned ;) For me it is kind of funny too, but mostly in a sad way. Personally, I think we had an initial version of this around 2024 after the qa-frontpage started using the "reviewed-looks-good" usertag: https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00120.html It did have some usage, but wasn't as successful as I'd hoped. >> 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. > Same here! > >> 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. > Unconstrained? I am not trying to neglect or circumvent our "Commit > Policy". This would be out-of-scope for this GCD. That being said, I > have some doubts on how closely this policy is followed (the > "Helping Out" paragraph could be a hint to that) I too have doubts, and have previously complained to the maintainers about people flouting the commit policy. It's harder to iterate on processes if people aren't following the current ones (and this includes maintainers as much as committers). >>> 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. > It is solely to state expectations towards people with Commit Access > (which follows in the next paragraphs). > >>> - Frequent, known contributors can apply for commit access. They >> >> What's a frequent but unknown contributor? > One that contributes anonymously. So, my presumption is that contributing to Guix is fine under a pseudonym/handle, and that this is also OK when applying for commit access. I don't know if this is correct though, and I guess it can be up to the discretion of the maintainers in a case by case basis. Given that, my reading of this item is that it removes this possibility? >>> 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. > Is it possible you commented while reading this document for the first > time? Yep, I'm just reading it through top to bottom, but I think this a reasonable approach. From what I read later, I gather this is referring to the maintainers, but in a way I haven't heard before. >>> - 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 > I like how the manual is somewhat more wordy, but is it more precise? > Would you want this GCD to list options (like the manual currently does) > what could lead to access revokation? I'm unsure whether precision was something the current documentation was aiming for, and I sort of get why you might not want this to be precise, otherwise you're setting out what bad behaviour is allowed, providing it doesn't get too bad. >>> #### 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 > Me too. But yet again, the existing phrasing is not very precise and > does not state what expectations we (as a project) have towards (active) > contributors. I wrote this phrase to indicate that pushing delicate > changes to master before disappearing from the interwebs for a long time > is not how we expect people to handle their responsibility. Personally I see a 24 hour response time as unreasonable, a more nuanced approach is needed. For example, pushing a big change just before you go on holiday isn't great, even if you can respond to emails within 24 hours. It might have been better to wait until after the holiday, or to have asked someone else if they can keep an eye on things and respond to any problems. >>> - 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. > I think I agree. IMHO a release team should be able to block the master > branch from direct pushed. But maybe locking the branch is also not the > best of ideas? Still we should define what we expect committers (and > team members) to parse ongoing discussions. This (again) is to refine > current phrasing. Would you disagree? How would you define the > project's expectations of responsible volunteers to take part in ongoing > discussions? Would you omit it completely? I'm also unsure about locking branches. Personally, as I say, I'd ignore this example of people pushing things when they're not meant to, so then the question becomes what problems is this meant to address? Having some specific examples would help as I can't really think of any. >>> 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. > Candidates to continue being maintainers. Ok, I think there's a need to more precisely set out the proposed process here. For these annual GCDs relating to the maintainers, my reading of this would say that maintainers cannot put people who aren't currently maintainers forward for the role in the appendix, is that correct? If so, that means new people can only become maintainers when serious issues emerge (through 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. >> >> I dislike this framing. > What do you not like about it? > >> 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. > I don't think I understand this sentence. Yeah, sorry, it's not very clear. In my view, the role of maintainer is more a interacting with people role, so I dislike framing it around people with 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? > I honestly don't know. My intention was to define how the community > have find consensus over who is part of the "maintainers collective", > and our tool for consensus finding is the GCD process. Where do you see > issues with this approach? I don't have any specific issues, just a general concern that trying to optimise the GCD process for both needs is harder than having two processes. >>> #### 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"? > A "contributor" can be happy without Commit Access. A prospect (as I > understood it) is looking for Commit Access. Thank you for suggesting > more adequate wording in advance (: I'm not sure there's a need to separate out contributors by desire for commit access here. I'd suggest saying something like "Review requests for commit access from contributors" and I think this is specific enough. >>> - 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? > Mailing lists, an IRC channel, a codeberg org and some repositories. > And probably some more? The infrastructure for all these things sits with other organisations, maybe they can be considered resources though. They at least relate to relationships the project has with other projects/organisations. >> My understanding is that resources and infrastructure generally are held >> by the Guix Foundation, which has it's own roles and processes. > huh You can see some more information on this here: https://foundation.guix.info/assets/index.html >> 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 > YES > > >> 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. > There were talks about needing to be able to addend/replace GCDs, I > think a GCD001.1 is in the works (though it may not be numbered as such). > > >> I also have concerns about the substantive changes, as I've mentioned >> above. > Thanks for sharing your thoughts! > > >> 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. > Why, though? Are "maintainers" not a (special) sub-group (team) of our > project? To me it would feel wrong to specify everything but the > maintainers here... Mostly because it's such a major change and decision. I get the intention about trying to set out something comprehensive, but that doesn't mean it's right or helpful to change so much at the same time. >> 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 agree! > >> I see "roles and memberships" as having more potential to get in the >> way of people participating and contributing, rather than enabling >> it. > How so? My goal was to stress the importance of teams and to motivate > people to come and contribute by specifying more exactly what the > project expects from each role. This is a thing that I sense to fend > off "prospects" (for the lack of a better word). > >> 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. > Yeah, this blows. IMHO other reviewers/committers should refrain from > doubling the work (as it seems to having been the case here) but (if > necessary) stating how your very review is valid and important (and to > be incorporated).
signature.asc
Description: PGP signature
