Summary of the Public Review: Rules for TYPO3 Units and the Unit Cooperation Panel

After the public review was announced on 6 August, it drew extensive feedback in the GitHub pull request comments, as well as through direct messages to the Governance Working Group members. All of the feedback was read and discussed.

The Rules for TYPO3 Units and the Rules for the TYPO3 Unit Cooperation Panel describe a proposed governance structure built around Units — groups of contributors responsible for defined areas of the TYPO3 project — and a Unit Cooperation Panel that would coordinate priorities across them.

• Proposed Rules for TYPO3 Units — Rendered PDF • Reviewed Pull Request
• Proposed Rules for the TYPO3 Unit Cooperation Panel —  Rendered PDF • Reviewed Pull Request

(The FAQs are at the end of the documents.)

The proposal is one outcome of the TYPO3 Association's broader strategy and governance work, and the Governance Working Group has been tasked by the TYPO3 Association Board with developing and reviewing it, with the goal of bringing a considered proposal to the Association's members at the General Assembly.

Publishing a concrete, versioned draft for public review, rather than discussing Units as an abstract idea, was a deliberate choice. It meant people could point to specific sentences, specific mechanisms, and specific gaps, instead of debating a general concept.

As a curious detail, a substantial share of the feedback came from people who are not members of the TYPO3 Association. Testing a governance proposal against as many perspectives as possible is exactly the point of opening it up publicly. At the same time, the proposed Rules ultimately concern the Association's own governance, the formal decision on whether to adopt them belongs to the Association's members.

The scope of the review was not limited to wording and cleanup. Feedback led to changes in the Rules themselves or to more or clarified FAQ items. The Governance Working Group had to make difficult choices between conflicting concerns. Their task was not to collect every comment and adopt it, or to defend the original draft unchanged.

Suggestions sometimes point in different directions, and adopting one can create a problem elsewhere in the framework. It is clear that the rules are not and will not be perfect, and that implementing them and the unit framework is only the first step in a journey of learning and improvement.

Some feedback questioned whether a more formal structure works against the flexibility TYPO3 needs in a fast-changing environment. The Governance Working Group sees Units as a response to that problem, rather than a cause of it: the previous team structure required from each new team to demonstrate its right to exist over months and teams received a budget only once a year. Units are intended to let subject-matter experts respond faster across broader topical areas without waiting for other bodies and external timelines.

The Rules for Units are one part of TYPO3's developing governance framework, not the whole of it, and they are expected to keep improving after this review, too. This makes it important to emphasize what the proposals are not trying to be.

Earlier feedback made clear that TYPO3's governance documents need to be things volunteers can actually read and work with in their spare time. That is why the Governance Working Group wrote a focused set of Rules, rather than a complex and exhaustive governance document that tries to anticipate every situation in advance. The aim is to move from more imperfection to less, not from no perfection to perfection.

Some of the most useful feedback did not point to something wrong in the text so much as reveal that the text could be read in more than one way. Here is how the Governance Working Group understands a few of the recurring questions.

The transition to Units is not a dissolve-and-replace exercise. The transition to Units will be a metamorphosis of the current team structure rather than a simple replacement of teams with Units. Many activities that current teams carry out are expected to continue, in some form, as Working Groups or other internal structures within a Unit. The Rules set the shared governance framework and the Unit Charters will describe how each Unit actually organizes its work (more about that below).

A recurring point of confusion concerned who needs to become a formal Unit Member. The requirements for contributing to TYPO3 are not the requirements for becoming a Unit Member. Unit Membership comes with formal responsibilities and accountability.

Contributors who don't want or don't yet meet the requirements of formal membership can still take part as Unit Supporters. Unit Membership is not a reward for having contributed. It is a formal governance role that comes with rights, such as a say in priorities and Association funds, and with corresponding accountability.

Each unit is inherently different. They are expected to have different subject areas, different needs, and different ways of organizing their internal work. The Coordinator role and the ability to delegate exist to provide a common governance framework across Units, not to force every Unit into the same internal process of day-to-day operation.

This came up most clearly around Core development. It helps to separate two questions:

• Who decides what should be built into TYPO3?
• Who decides whether an individual contribution is accepted?

The Unit Cooperation Panel is intended to act as Product Owner, creating and prioritizing a Product Roadmap that the Units can implement in their respective areas. This Product Owner role is also not tied to Scrum specifically, and the Panel isn't limited to meeting quarterly — that's a floor, not a cap.

Existing technical review and voting mechanisms are not disappearing. The Unit Rules require Units to define and document objective acceptance criteria. Responsibility for applying them can be delegated. The change is mostly about responsibilities and coordination, rather than replacing technical development processes. The precise product-development workflow is outside the scope of the proposed rules.

Several reviewers pushed on the difference between what the Rules intend and what they formally permit. As one reviewer summarized it: “Intent is not a safeguard. The rules are.” This is one of the many useful governance questions raised during the review that the Governance Working Group has put under serious discussion.

Where a concern was about an actual power, responsibility, requirement, or missing safeguard, the Governance Working Group’s response has often been a change to the Rules. Where it was about interpretation or how a clause relates to the rest of the framework, the FAQ has been expanded. More about this in the next main section, Changes in the Rules.

The discussion often touched on genuine trade-offs, rather than clear rights and wrongs:

• How much autonomy Units need to function
• How to guard against concentration of power
• How to keep the Rules understandable for volunteers
• How to avoid duplicating Association-wide policy
• How to keep room for experienced contributors to serve
• How to build in real accountability

These considerations can pull in different directions, and the Governance Working Group has tried to balance them, rather than simply pick a side.

The Unit Rules are not meant to solve every governance question TYPO3 has. The Unit concept traces back to the TYPO3 CMS Product Strategy and TYPO3 Association Strategy, particularly these sections:

• Product Strategy
  • Product Development Governance
  • Goal 5 — Establish Governance
• Association Strategy
  • 5.2 — Improving Governance
  • 5.4 — Strengthening the Innovation Process and Product Ownership

The Governance Working Group is not TYPO3's ultimate governance authority. The proposals are the result of broader governance and strategy processes within the TYPO3 Association, and the Working Group has been tasked by the TYPO3 Association Board to develop and review these proposed rules within that wider context, with the goal of bringing those proposals to the Association Members at the General Assembly.

This is where the review had the most concrete effect. Few changes are based on an exact suggestion. Most are the result of the Governance Working Group’s deliberations about how best to address a concern that was raised. Where a suggestion was not adopted, the goal was to record the reasoning in the FAQ, rather than leaving it unexplained.

The changes below are grouped by the governance concern they address, not by when they were made.

In the original draft, the Unit Coordinator was expected, but not explicitly required, to involve the Unit Council in decisions concerning adding and removing Unit Members. Commenters were concerned that this could give the Coordinator considerable influence over who could vote in future elections. 

The revised Rules give the Unit Council a formal vote: the Council now decides on admission and removal by simple majority, on the Coordinator's proposal. For Unit Member removal, two cases are still automatic: lapsed Association membership and prolonged inactivity.

A mandatory Unit Member removal has also been added: the Coordinator must remove a Unit Member or Supporter when a responsible Association body reports an unresolved violation of the bylaws or of Association policy.

The Rules have also been changed to allow the Unit Council to vote for the extraordinary removal of a Unit Member, independent of the ordinary removal and expiry rules, when proposed by the Coordinator.

Together, these changes address a concern raised clearly during the review: that a Coordinator could otherwise shape the electorate that elects them.

Previously, a Unit Council that lost confidence in its Coordinator or Deputy Coordinator could only petition the Association Board for their removal. The revised Rules now let “the Unit Council […] vote to remove the Unit Coordinator or Deputy Coordinator with two thirds majority of the votes cast.” The Coordinator still answers to the TYPO3 Association Board, who can also independently remove them.

A related change allows a quorum to be reached without the Coordinator or Deputy present specifically when electing a vacant Coordinator or Deputy role, so those two positions cannot block the Council from filling them.

The review raised a legitimate question: should Coordinators face a fixed term limit to prevent long-term concentration of power? The Governance Working Group decided not to introduce one. Instead, the Rules now describe the Coordinator's role explicitly as administrative — focused on Unit health and compliance with the Charter — while making clear that long-term policy and strategy for the Unit belong to the Unit Council, not the Coordinator personally.

Tying the Coordinator's term to policy-setting would turn every Coordinator change into a directional shift, when the intent is for it to be an administrative shift instead. This is a case where the Governance Working Group weighed the concern seriously and made a different choice, while adding the direct recall described above as a safeguard elsewhere.

Even an administrative role benefits from the trust of election documents, which is part of why the Coordinator and Deputy Coordinator remain elected rather than appointed.

Some reviewers read the original wording — that Unit Members “answer to the Unit Coordinator and must fulfill delegated tasks” — as describing something closer to an employment relationship than voluntary contribution. The Rules now read:

“Unit Members should be awarded a large degree of freedom in task selection. Unit Members can request to have tasks assigned or tasks can be assigned by the Unit Coordinator or their delegate. In both cases they must respond to assigned tasks. Tasks should be accepted and accepted tasks must be fulfilled to the best of their ability."

The FAQ adds a plain explanation of the difference between a RFC 2119-style must and should in this context, and asks that the Business Control Committee is tasked with auditing decisions within Units that diverge from a should.

The Panel Rules previously said representatives were assigned by the Unit Coordinator. They now set an order of preference:

1. The Coordinator represents the Unit by default, if eligible and willing
2. Otherwise the Deputy Coordinator, if eligible and willing
3. If neither can be assigned, the Unit Council elects another eligible Unit Member. 

This closes a gap where representation could otherwise be assigned unilaterally.

Any role may still be combined with a role in another Unit, but the revised Rules add that “Unit Coordinator, Deputy Coordinator, and Unit Member roles should not be combined across more than two Units.” This responds to a concern that a single person, or a single employer with several employees in leadership roles, could accumulate influence across many or all Units — even if unlikely.

The Governance Working Group decided against going further by limiting how many roles employees of a single company can hold across Units. Contribution to open source is broadly meritocratic, and restricting participation by a major institutional contributor could cost the project more than it protects.

Not every concern needed a change to the Rules themselves. When a reviewer asked that the Rules explicitly state that the Conflict of Interest Management Policy applies to Unit and Panel roles, the Governance Working Group concluded that the Policy itself should define its own scope, to avoid two documents disagreeing about the same question later. The FAQ instead records that the Governance Working Group asks the Association Board to adapt the Policy to explicitly cover Unit and Panel roles.

The same approach applies to a project-wide decision-making best practice. This governance vehicle has now been requested from the Board for both Units and the Panel, as well as a formal escalation process for situations such as a Unit without a functioning Coordinator or a Unit that will not admit new Members. These are gaps that the review correctly identified as under-specified. The Rules were also updated so the Board must act if a Unit runs out of tasks to complete.

The end of the public review is not the end of this process. Three things happen next, in sequence.

The Rules establish the shared governance framework, but each Unit still needs a Charter describing how it works in practice. Current team leads will review the draft Charters and have been asked to propose initial Unit Members from their existing teams. Those proposed members are not yet formally appointed Unit Members, but they give the future Units a practical starting point, and they can begin discussing their Unit's future work informally in the meantime. The Charter drafts will  go through their own public community review round before the Association Board formally approves them.

This is where TYPO3 Association members will decide on the governance changes this proposal requires, including any necessary changes to the Association's bylaws. That decision is not a formality, and it is not guaranteed to pass as written.

If the necessary decisions are approved at the General Assembly, this event is meant as the practical starting point for the Units themselves, building on the informal groundwork already done by the proposed initial Unit Members.

The public review mattered. It improved how Unit Members are admitted and removed, how a Coordinator is held accountable, how task assignment is worded, and how Panel representation is chosen. Several open questions have been forwarded to the Association Board to be deliberated further outside of the proposed rules.

The Governance Working Group is aware that it couldn’t address every concern to the satisfaction of everyone, but hopefully in the way that best accommodates the needs of the TYPO3 Association and its members. 

One thing is clear: This will not be the last time these rules are improved. A governance framework for a project the size of TYPO3 is something the community will keep learning from and adjusting, not something anyone gets to design once and call finished.