On Mon, May 4, 2026 at 6:28 AM Gabriel Wicki <[email protected]> wrote: > > Hi Greg! > > I hope you are doing fine! > > > Greg Hogan <[email protected]> writes: > > I disapprove. > I think I adopted all your concrete suggestions¹ (i.e. slimming the GCD > down to just the changes, even though it is still lengthy for > completeness' sake). > > I am still very puzzled about your refusal to explain your more cryptic > statements to me². How could I possibly incorporate your criticism when > I am unable to understand it? Why would you refuse to explain? > > I just don't get it.
I would rather have left the deliberation period for independent voting and then repeated this discussion. Despite multiple commentators explaining the different purposes of and interplay between the project documentation and a GCD this document continues to assert itself as "complete and exhaustive" and it purports to clarify while mainly contributing confusion. The responsibility for a GCD is to the author(s), not to project team members offering constructive comments while asking important questions. As far as I can tell no consideration was given to the impact of renaming all groups as "teams", except that somehow all groups now teams would be listed in etc/teams.scm. And now we have "special teams". I think that committers should be a member of at least one real team in order to fully participate in project discussions. And teams need committers! This GCD is incomplete and full of holes. Who disbands a team? How is this different from an edit to etc/teams.scm removing the team? How are inactive team members removed? What does it mean that "teams are generally open for new members to join, but current team members retain the authority over timing and procedures when onboarding new members"? When are teams not open to new members? Is this timing of joining different from editing etc/teams.scm? Is there any meaning to referencing onboarding? This GCD proposes active, passive, and inactive committers. Why? For the latter, "their commit access will eventually be revoked". How? When? What is the contribution here? This GCD is a collection of existing well thought out processes interspersed with directionless edits. What is the "not unlike the deliberation period of the GCD process" for the annual maintainer report which includes the "composition of their team for the upcoming term for approval"? The most impactful change in the GCD and it just punts. The superficial clumsy wording can be fixed, but as noted during discussion, fundamentally this GCD is not a meaningful contribution. As requested, what problem(s) are you looking to solve? And this is just beautiful: "Any and all contributions to our project should and will improve our project for the greater good". There is an ongoing discussion on gatekeeping the tools used for writing free software, and this document nonchalantly decides that all code is acceptable. The statement is either false or meaningless (otherwise we would simply merge any and all requests) and the "should" and "will" cannot both be needed. Chef's kiss.
