Hi Steve! I was longing for your input!
On Wed, Mar 18, 2026 at 07:38:33PM +0000, Steve George wrote: > My struggle with the GCD overall is that I don't know if it's supposed > to be a general set of principles, a policy or a set of rules. I did not intend GCD007 to write down super detailed rules (we currently deploy), but summarize the social structure we act in—with some not-too-giant adjustments where I felt it necessary. > Many of the items in the manual are recommendations and the > Maintainers have been free to interpret them. If we're shifting from > that position then I would like to see clear, concise language that > follows RFC 2119. > > [0] https://datatracker.ietf.org/doc/html/rfc2119 I don't think this GCD is the right place for exact rulings, the way RFC2119 sets it up for technical implementations. I have the strong feeling that this could be somewhat repellent for the non-cyborg population around us ;) > > Personally I would like to hear more voices on topics I feel important: > > - Keep the 1 year delay for losing commit access. > > (I understand Gabber's argument that "1 year" is also "several months", > > so writing "several months" would not invalidate the current manual; > > I still think that repeating the "1 year" from the manual would be good.) > > - Drop the distinction between "active committers" and "passive committers". > > Where is the consensus moving on these topics? I could live with how > > things are formulated (with the understanding that "several months" does > > not overwrite "1 year"), but would still prefer to change them. > (...) > > For me the overall contention of this section is about removing, and > actually in my opinion we simply don't have enough committers for the > amount of work the project has. So I'd rather see effort put into > defining how to increase the numbers of people involved. I agree with you here. But keeping in mind that we could eventually drastically improve our committer's workflows (automation!) we would probably want to consider shortening this timeline and slimming down the population with a "golden key" to our master branch. Hence the not-so-precise-but-still-very-much-the-same-as-before wording. > > Concerning the maintainers, as others I do not think that a 1 year term > > is reasonable, in particular if renewal is to be done through a GCD (why > > speak about an appendix? what would the corresponding body of the GCD be?). > > A GCD takes about two months with discussion and deliberation periods, > > and we do not want to spend the Novembers and Decembers of every year to > > discuss maintainers. With more traditional voting, it might be feasible. > > Another possibility: Three maintainers with three year terms and one of > > them replaced every year; and maybe a limit of two consecutive terms? > > I agree, it's needlessly beaucratic to go from no term to a term every year. I feel like my suggestion was misunderstood. I am neither suggesting fixed, single year terms, but rather that maintainers agree to a term of at least one year. We'd have a (yearly repeating) GCD where the current maintainers collective says in which constellation they plan to continue their duty the following year. More or less pro-forma team members approve of this—until major issues emerge. Right now the situation is as follows: would anybody raise concerns about one or more maintainers, we'd just all have to live with that. Or maybe craft a GCD defining a rule that removed this particular individual. This feels extremely odd. Having the maintainers thinking about their terms in yearly iterations—maybe combined with some report of what they actually did (I mean, what do they actually do??)—and having some formal way of our community to approve of their work and their suggestion(s) is IMO a big improvement. But I understand that the way GCD007 currently phrases it invites for misunderstandings. Maybe someone can help me adjust it? > I would strongly favour a rolling set-up which is how FreeBSD does it. > This will be beneficial for the people coming in, as they can be > mentored by the existing ones. Could you summarize what you mean by that? > ArchLinux and Gentoo both have some nice material on the overall > structure of governance which defines the relationship between > Maintainers/Leader <--> contributors in various forms. Worth looking > at for different approaches. Do you have any links I could look at? What specifically do you find worth considering? Have a splendid weekend gabber
