Hi, On Wed, Mar 18, 2026 at 04:45:54PM +0100, Andreas Enge wrote: > Hello all, > > almost a week has gone by, and this GCD seems a bit stuck. > Several people have made comments and suggestions (not all going into the > same direction), but resulting in few changes to the document. I have > taken some time off from the discussion, to work on GCD 006, but also > since there is not much point in Gabber and me exchanging the same > arguments over and over again. (...)
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. 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 > 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. On the specific point of removing access I like Gentoo's process. They voice it as "retirement", and people can reactivate it easily. - Individuals can set that they are "devaway" for a period of time. - Individuals can choose to retire - Inactive retirement: they warn committers about removal (4 times) over a time period (12-18 months). - Return to duty: "Reinstating a developer status is a lot easier than gaining a new developer status" - https://wiki.gentoo.org/wiki/Project:Retirement/For_developers - https://wiki.gentoo.org/wiki/Project:Retirement > If I understood Chris correctly, he would prefer to split the GCD into one > about teams in general, and one about maintainers. Personally I have no > preference and could live with both options (but see below...). (...) Splitting will help to keep each one concise and focused. It's difficult to keep the conversation on the core points, the wider the scope of the GCD. > 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 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. > Many approaches are possible. > So maybe the maintainers part indeed needs more thoughts? Maintainers > should definitely be mentioned in this document (since they grant commit > access), but maybe details of how they are determined should be > postponed to another GCD? (...) 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. Steve / Futurile
