[FEATURE] Rules for the TYPO3 Unit Cooperation Panel

[mabolek]

Note

Please read the article introducing the review round before starting your review here.

[github-actions]

This pull request must be classified as either a bylaw change, a formal change, or a maintenance change. Please add one of the following labels: type: formal change or type: maintenance change.

[Esders]

Thanks for putting this up. A concern specific to the Panel, since it "is the TYPO3 CMS Product Owner" (§1) and handles "Creation and prioritization of the TYPO3 Project roadmap" (§4.1).

The Panel is entirely appointed, not elected: each Unit's representative is "assigned by the Unit Coordinator" (§3.1), plus one Board representative. Combined with §5.3 (decisions need two thirds of all members in favor), influence over just 3 of 7 seats is enough to block anything from reaching the roadmap.

I appreciate that FAQ 2 already applies conflict-of-interest reasoning (the Board rep can't chair because the Board "defines budgets for Units"). I'd like to see that instinct extended.

Questions: (1) Should the Panel that owns the roadmap be elected, or at least each Unit's representative be elected by its Unit rather than assigned by the Coordinator? (2) Is the 2/3-of-all-members threshold intended to make blocking (3 of 7) easier than passing (5 of 7)?

Full reasoning and the link to the Unit-rules side is here: https://talk.typo3.org/t/unit-rules-what-keeps-decision-making-power-from-concentrating/6699

[mabolek]

Hi @Esders!

Thank you for taking the time to review the proposals. This kind of stress testing is exactly what the Governance Working Group is looking for.

I read your post on talk.typo3.org, but I'm replying here in GitHub because it may help us later to have all the feedback in one place. 🙂

(1) Should the Panel that owns the roadmap be elected, or at least each Unit's representative be elected by its Unit rather than assigned by the Coordinator?

The intention is that a Unit's Coordinator is the most natural choice to represent the Unit in the Unit Cooperation Panel. However, there will be cases when a unit coordinator won't be able to take on the role. In such cases a different person must be chosen.

I think it would be good to mention this explicitly in the list of areas where the Unit Council should be consulted (section 3.1.5.i). I will bring this to the Governance Working Group.

The intention is also that the Unit Cooperation Panel should be representative of the people actively involved in the project. Both the Unit Coordinator and the Unit's representative to the Cooperation Panel should have their explicit or implicit support.

(2) Is the 2/3-of-all-members threshold intended to make blocking (3 of 7) easier than passing (5 of 7)?

Yes. The emphasis is on reaching a large degree of consensus among the Units, as they represent the project's combined subject-matter expertise.

[Esders]

Thanks @mabolek, and good to hear the representative selection will go to the WG.

On (1): adding it to 3.1.5.i is a good step. Could I suggest going one degree further: when the Coordinator is not the Panel representative, have the Unit Council elect the representative rather than only be consulted. That keeps the Panel seat tied to the Unit's own choice and reduces reliance on a single appointment, while still keeping the Coordinator as the default.

On (2): thanks for confirming the intent, and I understand the consensus goal. The flip side worth documenting is that a one-third bloc (3 of 7) can hold up any roadmap item indefinitely, which is the same concentration surface from the other direction. Is there, or could there be, a safeguard against persistent blocking, for example a defined escalation path when the Panel cannot converge? That would keep "consensus" from becoming a standing veto for a small, well-resourced minority.

Appreciate the open discussion.

[mabolek]

Hi @Esders!

On (1): […] Could I suggest going one degree further: when the Coordinator is not the Panel representative, have the Unit Council elect the representative rather than only be consulted. That keeps the Panel seat tied to the Unit's own choice and reduces reliance on a single appointment, while still keeping the Coordinator as the default.

The Governance Working Group will discuss this and get back to you here.

On (2): thanks for confirming the intent, and I understand the consensus goal. The flip side worth documenting is that a one-third bloc (3 of 7) can hold up any roadmap item indefinitely, which is the same concentration surface from the other direction. Is there, or could there be, a safeguard against persistent blocking, for example a defined escalation path when the Panel cannot converge? That would keep "consensus" from becoming a standing veto for a small, well-resourced minority.

Yes, this is definitely something to add FAQ item about. The topic as such was extensively discussed with the team leaders on 5 August. It was difficult to come up with a perfect solution that both honored the wish for consensus and prevented any chance of deadlock. In the end, the agreement was to try this version and change it later if necessary.

My personal opinion is that the chance of a "a small, well-resourced minority" creating a deadlock is very small indeed. It would require this minority to be represented as a majority in several different units.

[rfoucard]

Hi @mabolek, from a compliance and governance perspective, I recommend making the selection process for each Unit’s representative to the Panel more transparent and predictable:

Candidates for Unit Coordinator and Deputy Unit Coordinator should state when standing for election whether they are willing to represent the Unit on the Cooperation Panel. This would allow the Unit Council to understand from the outset which responsibilities it is assigning and whether a separate representative will need to be elected.

A simple order of representation could apply:

1. The Unit Coordinator represents the Unit by default if they accepted this responsibility when standing for election.
2. Otherwise, the Deputy Unit Coordinator represents the Unit if they accepted this responsibility when standing for election.
3. If neither is available or willing to serve, the Unit Council elects another Unit Member as its representative.

This would allow all three roles to be settled during a single election session. It would preserve a clear and practical default while ensuring that the Panel seat always results from a choice made by the Unit Council, rather than a unilateral appointment by the Coordinator.

[rfoucard]

Hi @mabolek. I understand the 2/3 intention to encourage broad consensus, and I admit that I have not yet found a perfect alternative that would preserve this objective without creating deadlock situations.

Rather than suggesting a different voting threshold at this stage, I would recommend adding a few safeguards to the current model:

• Panel decisions should use a common decision template, ideally shared by all bodies, in which the alternatives considered, the reasons they were not selected, and the rationale for the final decision would be always documented.
• Objections should always be documented too, including the reasons behind them and the conditions under which they could be resolved.
• Abstentions should be excluded from the calculation of the result—as I understand is already intended by the proposal but I am not sure—so that they cannot effectively become a “silent no.”
• Panel decisions should be published in the same way as the Board has recently started publishing its decisions.

I prefer these safeguards to escalation because they strengthen transparency and accountability while keeping responsibility within the Panel. They also encourage members to resolve disagreements without creating an incentive to shift difficult decisions to another body or a single person, such as the Panel Chairperson. Also, escalation seems natural in the event of a tie, but when a two-thirds majority is required, it is less clear when it should occur. Should every failure to reach the threshold trigger escalation? If not, how do we prevent escalation from becoming systematic?

I would also welcome a common decision-making framework covering all Association bodies. There are already significant differences between the proposed Panel process and the Board’s current process, and neither is perfect. A consistent approach to quorum, majorities, abstentions, objections, recusals, decision records, and deadlock resolution would benefit the whole organization.

[Esders]

Thank you @rfoucard, both proposals address my two points well.

On representation: declaring willingness to serve on the Panel at election time, with the Coordinator as default and the Unit Council electing the representative otherwise, is exactly the "seat tied to the Unit's own choice" I was hoping for, and cleaner than what I suggested. I'd support this wording.

On the 2/3 threshold: I'm happy to drop my escalation idea in favor of your transparency safeguards. Documented alternatives, documented objections with resolution conditions, and published decisions do more to prevent a silent, unaccountable block than an escalation path would. On abstentions, §5.3 already says "excepting abstentions," so the intent seems covered, though making it unambiguous would help.

A common decision-making framework across all bodies sounds like the right long-term goal. Thanks for turning this into something concrete.

[andreaswolf]

Suggested change

	One person can only represent a single body in the Unit Cooperation
	Each person can only represent a single body in the Unit Cooperation

Already left that as a remark on the paper version at T3DD :)

[mabolek]

Thanks, @andreaswolf! Good catch.

[Lefaux]

As with the Unit proposal, both entities - when combined - allow hostile takeover of the entire project.

This document establishes a self-reinforcing closed-loop system that completes the commercial and institutional capture of the project. Combined with the Unit Proposal, it creates a structure where executive authority can manipulate project strategy and bypass democratic oversight entirely.

Bypassing the General Assembly:

Section 2 allows these rules to be amended through a "joint decision by the TYPO3 Unit Cooperation Panel and the TYPO3 Association Board." This bypasses the General Assembly (the democratic membership body) completely, enabling the Board and Panel to quietly expand their own authority or alter governance without public vote or community approval.

Autocratic Product Ownership:

Section 1 explicitly names the Panel—represented solely by its Chairman—as the single "TYPO3 CMS Product Owner." Centralizing the entire software roadmap into one person's hands replaces community-driven technical consensus with a single bottleneck easily aligned with GmbH commercial deadlines.

Financial Patronage and Co-optation:

Section 3.3 allows the Board to selectively decide who receives compensation from the Association budget. This creates a paid loyalty incentive: Panel representatives who align with Board and GmbH priorities can be financially rewarded, while critical voices can be denied compensation or stripped of their roles by Board-controlled Unit Coordinators.

Asymmetric Power Dynamics:

The Board seats an active representative on the Panel, yet the Panel’s two delegates sent to the Board hold zero voting rights (FAQ 4). This guarantees top-down executive influence over product planning while rendering community feedback on executive decisions purely symbolic.

The Full Pipeline of Control:

Because the Board can charter/dissolve Units and remove Coordinators, Coordinators will only appoint loyal Panel representatives. Those Panel reps then elect a Chairman who dictates the roadmap and approves rule changes alongside the Board—completing a unbroken top-down hierarchy from the Board down to individual volunteers.

Since this review process is clearly targeted at developers rather than the average community member, let us analyze these two changes like code:

If this were submitted as a PR, static analysis tools would flag it with critical CVE-severity alerts for privilege escalation, broken access controls, and administrative backdoors.

Privilege Escalation (CWE-269)

• Policy Rule: Section 2 of the Panel rules allows the Board and Panel to bypass the General Assembly and amend their own governing rules via a closed joint decision.
• Code Equivalent: A low-privilege service account modifying its own sudoers file at runtime to grant itself permanent root access without triggering admin re-authentication.

Broken Access Control & Identity Manipulation (CWE-284)

• Policy Rule: Coordinators control task distribution and can trigger the automatic 6-month membership expiry against dissenting Council members while exempting allies.
• Code Equivalent: An API endpoint that allows an application admin to arbitrarily revoke session tokens for internal auditors while granting infinite token validity to preferred users.

Hardcoded Backdoor Override (CWE-506)

• Policy Rule: Section 4.3.c lets Coordinators override published contribution rules whenever a case is deemed "obviously lacking coverage."
• Code Equivalent: A hardcoded logic bypass in production code that skips input validation whenever a specific unmonitored header flag is set.

Single Point of Failure / Supply Chain Vulnerability (CWE-703)

• Policy Rule: Concentrating final merge authority in single Unit Coordinators and defining the Panel Chairman as the sole "Product Owner."
• Code Equivalent: Removing required peer reviews (PROTECTED_BRANCH rules) on production code, allowing a single compromised maintainer key to push signed commits directly to releases.

Voting to accept these documents at the General Assembly merges unpatched architectural zero-days straight into the project’s institutional framework. Refusing to merge until the policy is refactored with proper peer reviews, immutable community checks, and strict access constraints is standard open-source hygiene.

Maybe this illustrates a bit more clearly why "the intent is" is not sufficient here.
We fix security issues in TYPO3 - regardless of what the intent of the code was.

[Bunnyfield]

I think there is a broader way to look at this proposal which also helps to connect several of the individual concerns already raised.

What we are discussing here is, functionally, a constitution for TYPO3 governance. It defines institutions, distributes authority, establishes decision-making powers, and determines how those powers may be exercised. Once we look at it that way, the analogy to a constitutional democracy becomes useful.

The General Assembly is our democratic legislature and, according to Art. 10 of our own Bylaws, the "supreme governing body of the Association." The Board is the executive. Art. 19 explicitly lists the "Execution of the decisions of the General Assembly" among its responsibilities. That does not mean the Board needs GA approval for every operational decision. A government needs room to govern within its mandate.

But governing within the rules and governing the rules themselves are two fundamentally different powers.

The Board works for the Association and its members, not the other way around. Its accountability therefore runs back to the General Assembly. Following the same analogy, the Units are essentially ministries with different portfolios, responsibilities, and personnel. The Cooperation Panel is then comparable to an inter-ministerial coordination body, while also receiving substantial executive authority as the TYPO3 CMS Product Owner.

What is missing from this architecture is the equivalent of a

Constitutional Court

If we create a constitution, a legislature, a government, and ministries, we also need an independent institution that can decide whether those bodies are still acting within that constitution.

Its role must be narrow. It must not decide whether Feature A or Feature B is the better product choice. It must review whether an organ acted within its mandate, followed mandatory procedures, respected recusal requirements, and complied with the governance rules.

Neither the Board, the Cooperation Panel, nor a Unit can reasonably be the final judge of its own constitutional powers.

And this is not a role for the Ombudsperson structure.

Ombudspersons deal with individual grievances, conflicts, Code of Conduct matters, mediation, and similar issues. Constitutional review is fundamentally different: It protects the governance framework itself against violations by the bodies operating under it.

If the Ombudsperson structure is placed inside a Unit, as currently envisaged, it is structurally unsuitable for that role anyway. A body embedded in the executive hierarchy cannot simultaneously be the independent authority reviewing that hierarchy.

A constitutional review body must therefore sit outside the Units, outside the Cooperation Panel, and outside the operational authority of the Board. It needs independent legitimacy, clear jurisdiction, mandatory recusal rules, and the ability to issue reasoned decisions on governance violations.

Two practical consequences follow from the same principle:

Representation must include recall.
A "permanent representative" under §3.1 must remain accountable to the body that appointed or elected them and must be recallable and replaceable under defined rules.

Conflict resolution must include mandatory recusal.
If §4.1.5 gives the Panel responsibility for conflicts between Units, representatives of Units involved in that conflict must not simultaneously judge it. The rules must therefore define recusal, substitution, quorum, and majority calculation for those cases.

If we formalize executive authority this extensively, we must formalize its constitutional limits just as seriously.

Otherwise we are building a government and ministries, writing them a constitution, and then omitting the Constitutional Court that makes that constitution enforceable when it actually matters.

[sbusemann]

@Bunnyfield This is a good point. I am discussion at the moment, that the BCC should take of this role. Then we would have a clear separation of concerns. This is not a part of this document, but should be a part of the by-law changes.

[oliverklee]

@sbusemann In the past, the BCC refused to act on cases where the Board very clearly had violated the procedures and responsibilities the Board itself had defined for the different bodies of the Association. So the role of the BCC would need to change for that. Also, conflicts of interest (including BCC members "being best buddies" with Board members instead of actually controlling the Board) need to be resolved. Currently, the BCC is very (too?) close to the Board for this.

In addition, the responsibilities (controlling the finances vs. controlling governance and misuse of power) are different things. I think having a separate body for that's truly independent would make things a lost easier.

[Bunnyfield]

@sbusemann There should be separate institutions for fundamentally different oversight functions, just as there are in the Federal Republic of Germany. The Federal Court of Auditors is deliberately separate from the Federal Constitutional Court because financial oversight and constitutional review are entirely different responsibilities.

For the same reason, I do not consider the Business Control Committee an appropriate body for constitutional review. Its mandate is business and financial oversight. What we are discussing here requires an independent institution specifically mandated to review whether TYPO3's governing bodies act within the constitutional framework defined by the General Assembly.

And that necessarily includes the Business Control Committee itself. It is also part of the governance structure and must comply with the same constitutional rules. If the BCC were also the body deciding whether those rules had been violated, it would effectively become judge of its own constitutional limits.

The constitutional review body therefore needs to be institutionally separate from the Board, the Cooperation Panel, the Units, and the Business Control Committee.

Combining financial oversight and constitutional review would not create stronger oversight. It would merely concentrate two fundamentally different oversight powers in the same body.