A collection of unrelated points on this proposal:
The scope of the steering committee sounds very good, and is something that I’ve wanted GNOME to have for a long time (largely because of the power vacuum issue, but also as a way to diversify and open up project leadership roles). I’m wholeheartedly in favour of that aspect of the proposal.
Committee appointment is a tricky problem. We need to ensure that the committee is composed of people who can engage in high-quality decision making. We also need individuals who have the time and energy to fulfil their duties. And we want the committee to be representative of the wider project and to be open to emerging project leaders. A more diverse appointment system might help with that. I’d be in favour of having additional seats that have an alternative appointment mechanism (committee self-appointment or election being the obvious ones).
I’d probably drop the term limits for the initial proposal. It’s a good thing to consider, but I’d probably wait to see how things work out before setting those details.
My main concern about the proposal is that it is too big. Formalised teams plus steering committee plus RFC process is a lot. Out of those three elements the development teams is the most high-risk and complex. I can’t help but wonder whether that part of the plan should be decoupled and given more time/space to evolve. (Speaking of which, the teams which represent groups of modules are awfully big and include a large variety of project types. A proposal for constituent sub-teams would be good to have, in my view.)
For the new governance structure to have legitimacy I think that it will be important to have some form of community ratification, possibly a referendum amongst foundation members. That could happen after a trial period. Let’s also set out a timeline for review and adjustment, like an annual retrospective for the first couple of years.