Hi Gabriel, I'm trying to engage with just one of your questions, and a bit about approach:
On Wed, Mar 18, 2026 at 05:03:13PM +0100, Gabriel Wicki wrote: (...) > - Should we try to keep the current model of inheriting the Maintainer > role (maintainers appoint new ones)? How would we adequately phrase > that? > > The reason I came up with the GCD-for-maintainer-approval is because > it felt somewhat wrong to write such a seemingly monarchist ruling on > top of our consensus based, egalitarian project. I am ok with either > (or even new) suggestions, but I'd like some input from others. (...) Consensus is not defined within the manual and that's a problem. There are subtly different viewpoints on what it means in practise. How does it specfically apply to specific situations should be defined. There will always be some level of conflict, we shouldn't be resolving problems with our Governance process under the pressure of some disagreement. When I look at some of the debates from the past I don't always see consensus, sometimes I see exhaustion. There have been evident cases of frustration building in the project because there's no clarity on how to make decisions and resolve conflict. Sometimes, in my opinion, the word consensus is being used to cover conservatism, incrementalism and blocking. The current balance is towards "do nothing" and it favours those most willing to put energy into email debates. Without a clear mechanism for establishing consensus, and resolving issues it also blocks a slightly different strand within the project of "do-ocracy". The reason we have Maintainers or BDFL's in FOSS projects is because most people do development for fun and don't want to manage social issues. Yet social and organisational issues are key to a project's success. That's not monachism, that's just reality. > - How is dissent resolved in each of the roles (teams, committers, > maintainers)? Do we have, should we introduce and how do we write > down according procedures? (...) These are all reasonable questions, but there's also no need to first principle this, we can benefit from other peoples work as we did with GCDs. I looked at the Governance model for Arch, Debian, Gentoo and FreeBSD last year, some results are in my Codeberg. There's lots of answers there which can be used to create a model. That's what I would do anyway. I would split it into defining the roles/responsibilities of committers, maintainers and how 'consensus' is achieved when there is conflict. That's the basic unit of governance. The teams can be in a different GCD imho. Steve / Futurile [0] https://guix.gnu.org/manual/1.5.0/en/html_node/Making-Decisions.html
