First, a genuine thank you to the Governance Working Group. Publishing both drafts for open review, with the FAQs included, is exactly the kind of openness I want from our project, and both documents are a real step forward in clarity.
I’ve read the two proposals closely (Rules for TYPO3 Units, PR #49, and Rules for the Unit Cooperation Panel, PR #50). I’d like to stress-test one thing with the community. Not because I believe anyone intends it, but because a good governance model should hold up even against a bad actor. My question: as written, do the rules prevent decision-making power over the product from concentrating in very few hands?
Let me walk through the chain I see in the text, so we can check it together.
Who owns the product direction. The Panel is defined as the product owner: “The Panel is the TYPO3 CMS Product Owner”, and its first responsibility is the “Creation and prioritization of the TYPO3 Project roadmap” (#50, §1 and §4.1). So whoever shapes the Panel shapes the roadmap.
How the Panel is filled. It consists of “One permanent representative from each TYPO3 Unit, as assigned by the Unit Coordinator”, plus one Board representative (#50, §3.1). The unit representatives are not elected by the unit or by the membership. They are assigned by the coordinators.
How much a coordinator controls. “The Unit Coordinator has final say in all matters concerning the Unit’s mandated tasks and day-to-day operation” (#49, §3.1.1b), and for contributions, “the acceptance (for code, the merge decision) is up to the Unit Coordinator” (#49, FAQ 14). A coordinator serves “a term of one year” and “may re-elect incumbents indefinitely” (#49, §3.1.5g).
Who can hold these roles. This is the part I’d like us to look at hardest. The rules place no limit on affiliation: a role holder “may be employed by anyone or no one” (#49, FAQ 7), and “Any role in a Unit may be combined with any role in another Unit” (#49, §3.3.2a). There is no cap on how many coordinator or Panel seats people from one organization may hold, and no conflict-of-interest or recusal rule for decisions in which their employer has a stake.
The stress test. Imagine any single well-resourced organization, of any kind, that can afford to pay people to do unit work. Paid contributors simply have more time than volunteers, so over time they can become coordinators of several units. Each such coordinator has final say on what that unit accepts, and assigns that unit’s representative to the Panel. The roadmap then runs through people appointed by one organization. Blocking is even easier than steering: since “All Panel decisions require at least two thirds of the votes of all members … to be in favor” (#50, §5.3), influence over just three of seven seats is enough to stop anything from reaching the roadmap.
To be clear, this is a worst case, not an accusation about anyone. But a model should be capture-resistant by design, not by good will.
What gives me hope is that the authors already reason this exact way in one place: the Board representative may not chair the Panel, because the Board “defines budgets for Units”, and this avoids a “potential conflict of interest around budget decisions” (#50, FAQ 2). That is the right instinct. I’d simply like to see it applied more broadly.
So, as honest questions for the WG and the community:
- Should there be a cap on how many coordinator and Panel seats a single employer may hold at the same time?
- Should role holders disclose their affiliation and recuse themselves from decisions their employer benefits from?
- Should the Panel that owns the roadmap be elected, or at least each unit’s representative be elected by that unit rather than assigned?
- Given that re-election is currently unlimited, should coordinators have a term limit?
I would genuinely be glad to be told I’m misreading the drafts. If I am, pointing to the clause that prevents this scenario would help all of us. If I’m not, writing these safeguards in would make a strong proposal much harder to abuse, and easier for everyone to stand behind.