[FEATURE] Rules for TYPO3 Units - #49
Conversation
|
✅ This pull request is classified as It requires 2 approvals by representatives of the document owner (TYPO3 Association Board if not stated otherwise). |
Also adds numbering and titles to paragraphs.
|
What does this mean for existing TYPO3 teams and the team members? Will all teams be disbanded when the new rules are in place, and the team members then need to apply for unit membership (assuming they trust the unit coordinator, are okay with getting assigned tasks, and is an Association member)? And what will happen to existing team members who are not Association members and are not willing to join the Association? |
|
Hi @oliverklee!
Thank you for participating in the review. The transition to Units will be a metamorphosis of the current team structure rather than a simple replacement of teams with Units. I would expect many of the activities currently carried out by teams to continue as Working Groups or other internal structures within Units. However, since Units are intended to be self-managed, it will ultimately be up to each Unit to decide how it organizes its work. The transition process is currently being drafted, so the details may change. However, the current draft includes these steps for identifying the initial Unit Members:
The proposal for unit rules states that Unit Coordinators, Deputy Coordinators, and Unit Members must have an active personal membership in the TYPO3 Association. This means that someone who does not want to become an Association member cannot not take on the formal Unit Member role under the current proposal. However, that does not mean that they would no longer have a place in the unit. The proposed rules introduce the role of Unit Supporter for people who contribute intermittently or who do not want the level of commitment and requirements associated with Unit Members. The distinction between Members and Supporters is also important for governance. Unit Members have voting rights. They participate in decisions concerning priorities (that affect the tasks they are assigned) and budgets (use of the Association's money — aka. "the members' money"). |
mabolek
added
the
type: formal change
|
This pull request is classified as a formal change. This means it needs an formally documented decision by the TYPO3 Association Board, which must be documented in a new file under ❌ A formal change must add a new decision record under |
github-actions
Bot
added
the
pending formal decision
mabolek
removed
the
pending formal decision
github-actions
Bot
added
the
pending formal decision
|
Thanks to everyone who worked on this. One structural concern specific to the Unit rules. Taken together, these clauses concentrate a lot of influence in the Coordinator role, with no counterweight against a single employer: "The Unit Coordinator has final say in all matters concerning the Unit's mandated tasks and day-to-day operation" (§3.1.1b), and for code "the acceptance (for code, the merge decision) is up to the Unit Coordinator" (FAQ 14). Questions: (1) Should there be a cap on how many Coordinator seats a single employer may hold at once, plus a recusal rule when a Coordinator's employer benefits from an acceptance decision? (2) Should Coordinators have a term limit? Full reasoning, and how this connects to the Panel rules, is here to keep discussion in one place: https://talk.typo3.org/t/unit-rules-what-keeps-decision-making-power-from-concentrating/6699 — happy to be shown a clause I've missed. |
|
Could you please define the Unit Council somewhere at the top of the document? Even if it's just saying sth like "The Unit council, defined in ..., has/is/can..."? It's actually good practice to define words and roles before using them. If I overlooked sth please point me. |
|
In our team, less than 50% are Association members (AFAIK) and hence would qualify to be part of the initial Unit members. This would mean that our team (if it were migrated to a working group) would lose more than 50% of its members. Do you have any numbers of how many team members would be left out when the new structure gets put into place (assuming that the team members have good reasons to not be Association members)? |
|
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. 🙂
As you say, it is a worst-case scenario, but still a good and important question. We don't have this for team leaders today. However, if we try to keep repetition to a minimum and every rule and policy as general as possible, the Conflict of Interest Management Policy could also be adapted to apply to both concurrent seats and recusal.
There is currently no limitation that restricts the number of terms a person may run for and serve in a particular role anywhere in the TYPO3 project. The current safeguards built into the Unit Rules are that the Unit Members are able to elect a new coordinator at least once a year and the TYPO3 Association Board has the possibility of removing the Coordinator at any time. In the end, both of the questions are open-ended, and it's a question of perceived risk versus the benefit of good people to be able to serve. They are also questions that could be left to the General Assembly to decide — either specifically for this case or more generally for all roles in our community. I'll take this back to the Governance Working Group. |
|
Hi @ineswillenbrock!
That is a good point. I think it would easily be a repetition of the definition in 3.1.5.a if we add it to the top of the document, but we can add links from the terms ("Unit Council", "Member", "Supporter", etc.) to their definitions. That way you can click on the word and go straight to where you can read about them. I hope that's an acceptable solution. |
|
Hi @oliverklee!
We don't have any statistics on that. |
|
Thanks @mabolek, that's a helpful and open reply, and I'm glad this is going to the Working Group. On (1): the pointer to the Conflict of Interest Management Policy is the right hook. Could the WG consider making it concrete and binding rather than optional? Two specifics: a cap on how many Coordinator (and Panel) seats a single employer may hold at the same time, and mandatory recusal when a role holder's employer directly benefits from an acceptance or prioritization decision. If the Unit Rules referenced that policy explicitly, reviewers could see the safeguard in context. On (2): I understand there's no term limit anywhere today. My concern is that both safeguards you name, annual re-election and Board removal, sit on the Board/Council side, which is also the side that seeds the initial Council. A member-side safeguard would balance that. Rather than resolve it here, would the WG put it to the General Assembly as an explicit question (term limits and/or periodic re-confirmation for Coordinators), so members decide it deliberately rather than by omission? Either way, thanks for engaging so openly with the stress test. |
I understand the concern. However, this is exactly why the respective members have the opportunity to elect their Coordinator every single year. In my opinion, it doesn't make sense to introduce a term limit just for the sake of having one. Someone taking on such a role usually doesn't do so for power or personal benefit, but because they want to contribute to the success of the Unit. We should honor everyone who is willing to take on such a role, deal with all the responsibilities that come with it, and ultimately invest a significant amount of time and energy into the community. As long as the members continue to trust and re-elect that person, I don't see a reason why they should be forced to step down after an arbitrary amount of time. Benni, for example, has been leading the Core Team for around 12 years, and I think many members are grateful for his long-term commitment and everything he has contributed during that time. I don't think we would have gained anything by forcing him to step down simply because he had reached a predefined term limit. |
|
@oliverklee 's factual question has been answered ("we don't have statistics"), but his substantive concern has not. The proposal currently appears to accept that existing long-term team members who are not Association members will lose formal membership and governance rights and become Supporters, without quantifying the impact or defining a transition safeguard. |
|
Hi @Esders!
The Governance Working Group will discuss both topics and get back to you here. |
Hey @CybotTM, yes, team members who are not Association members would be Supporters in a Unit. That is intended, and it is how this kind of structure is meant to work. Supporters keep contributing. What changes is the formal governance vote. The part I'd like to understand better: what is the case for holding governance rights in the project while not being part of the Association that carries the legal and financial responsibility for it? To me, those two things belong together. If there are good reasons why people stay outside the Association, I'd really like to hear them. That would be the actual problem to solve, and fixing it looks more promising than decoupling governance from membership. |
Thanks you for pointing this out. It is duly noted. The Association Membership requirement was also discussed with the team leaders as a potential issue, but without these concerns requiring changes. I interpret this as a sign that the issue is minor. As mentioned in my original reply to @oliverklee, the Association Membership requirement in section 3.3.1.a stems from a wish to improve the governance. The assumption is that the Association Members will share the view that control over the Association's money is best handled by fellow Association Members. Additionally, becoming an Association Member also implies approval of the Association's bylaws and governance processes — something that many people find important. My impression is that becoming a member is considered a trivial decision by most people. However, some may have reasons for not wanting to join the TYPO3 Association. That must be respected. The intention is that the proposed rules address this through the Unit Supporters, while trying to deal honestly and openly with the wish for better governance. |
@o-ba I'll contact you in Slack for this. |
|
Hi @Esders, Thank you, for raising these relevant and valid concerns. As TYPO3 Association Compliance Officer, I’d like to add that they are indeed directly relevant to the current annual revision of the Conflict of Interest Management Policy that I’m working on. It is WIP but should be published soon. One of the main goals of this revision is to make sure that the same conflict-of-interest principles apply consistently to all roles with significant decision-making authority, including new roles such as Unit Coordinators and members of the Unit Cooperation Panel. I therefore think that both the Unit Rules and the Panel Rules should explicitly state that the Conflict of Interest Management Policy applies to these roles. This should include the disclosure of conflicts, recusal from related discussions and decisions, combinations of roles, and situations where several influential positions are connected to the same employer or economic interest. The detailed criteria and possible mitigation measures should, in my view, remain in the general Conflict of Interest Management Policy rather than being repeated in every set of governance rules. This will give us one consistent framework for the whole organization and make it easier to update over time. However, its application to the Units and the Panel should be made explicit. I’ll make sure that the specific risks highlighted in this discussion are considered as part of the revision, and I’ll be happy to suggest wording for the reference once the relevant provisions are ready. |
|
I would also like to come back to the question of term limits. This is not a new concern raised only in response to the proposed Unit structure: it was already brought before the 2026 General Assembly through Petition 4, asking TYPO3 to consider term limits more generally across the organization. I fully agree that people usually take on these roles because they want to contribute, not because they are seeking power or personal benefit. Term limits should not be understood as a judgment on their motivation, performance, or the value of their long-term commitment. They are a structural governance safeguard designed to work even when everyone involved is acting in good faith. Healthy rotation, succession planning, and the prevention of a lasting concentration of power are widely recognized governance good practices. Regular renewal can bring new ideas, skills, and perspectives, maintain a healthy balance between experience and change, reduce dependency on individuals, and give other members an opportunity to develop leadership experience. Of course, rotation also needs to be managed carefully. It can result in a loss of expertise or institutional memory, and recruiting and preparing successors requires time. This is why I would not support very short terms or rapid turnover. The objective should be a reasonable balance between continuity and renewal. Annual elections provide democratic accountability, but they do not achieve all these objectives. In my view, a one-year term is too short to define meaningful objectives, implement them, and properly assess the results. It also leaves very little time for the Unit to review its leadership needs, identify potential candidates, prepare a successor, and consider a genuine alternative. In practice, an annual election could therefore easily become a routine “let’s keep the same person” decision, particularly when no one else has had enough time or encouragement to prepare and stand for the role. Paradoxically, very frequent elections do not necessarily create more renewal. They can reinforce the incumbent’s position because re-electing the only known or available candidate is naturally the easiest option. As a concrete starting point for discussion, I would suggest three-year terms. This would give a Coordinator enough time to define and complete meaningful objectives across approximately two major TYPO3 release cycles. I would combine this with a maximum of three consecutive terms, allowing someone to serve for up to nine years. Nine years seems more than sufficient to make a substantial and lasting contribution, while creating a clear responsibility to share knowledge, develop future leaders, and prepare an orderly succession. This would not force experienced contributors out of the project. After leaving the Coordinator position, they could remain actively involved, support their successor, transfer their knowledge, or contribute in another role. After a defined break, they could also become eligible to serve again. This would preserve valuable experience without allowing the same position of authority to become effectively permanent. Since this question concerns positions of power across TYPO3, I believe it should ultimately be considered as a general governance principle rather than only as a rule for Unit Coordinators. However, the creation of the Unit structure makes this a particularly good opportunity to address it consciously instead of adopting unlimited re-election as the default. I will also consult the Board on this topic, as it committed to preparing a counter-proposal to Petition 4 from the 2026 General Assembly. In my view, the general principles and model for term limits should be developed consistently across the organization, rather than independently by each body. They could then be implemented in the bylaws or specific rules governing each role, with justified adaptations where necessary. |
|
This is great to see, thank you @rfoucard. Making the Conflict of Interest Management Policy explicitly apply to Coordinators and Panel members, including several influential positions tied to the same employer, is exactly the safeguard I was hoping for. Referencing it from both rule sets, with the detail living in the policy itself, sounds right. On term limits, I fully agree with framing them as a structural safeguard, not a judgment on anyone. @o-ba, I think we agree on the value of long, committed service. My point is only that a safeguard should hold by design, independent of how good the current person is, precisely because dedicated long-tenured leaders are the norm here, not the exception. A 3-year / max-9 model, decided consistently org-wide via Petition 4, sounds like the right level to settle this. Thanks all for taking the stress test seriously. |
| """""""""""""""""""""""""""""""""" | ||
|
|
||
| The role of Coordinator, Deputy Coordinator, and Member in a Unit | ||
| requires active personal memberships in the TYPO3 Association. |
There was a problem hiding this comment.
This is not what I heard from reports from the Dialogue Days - I heard that it was decided that it's not required to be an Association member in order to be a Unit member. Is this report incorrect, or was this changed after the Dialogue Days?
There was a problem hiding this comment.
Hi @oliverklee! The Dialogue Days were not a decision-making body and no decisions were made. It was announced as "two days of structured dialogue." The lead of the recap says: "Two intensive days made shared priorities, concerns, and responsibilities more visible, while leaving the assessment, prioritization, and formal decisions to the next stages of the process." (My emphasis.) For the benefit of a good process, I hope we can keep this review to what is written in the actual proposal texts. 🙂
There was a problem hiding this comment.
I'm asking here because this seems to be the only place available for this. (In the Talk thread, you explicitly asked to move all discussion here.)
What I meant was this: "At the DD, it was communicated that their had been a decision that …". Is this report incorrect, or was this changed after the Dialogue Days?
There was a problem hiding this comment.
Hi @oliverklee! What you heard is incorrect. No decisions have yet been made concerning the Unit proposals. It is the text in this PR and the PR for the Rules for the TYPO3 Unit Cooperation Panel that constitutes the current proposal that should be discussed here.
There was a problem hiding this comment.
@oliverklee I was present and I don't remember any explicit "veto" from the crowd against the membership requirement (and that would have been the only thing we could have gotten, since there was no formal voting whatsoever).
I also second what @o-ba has said earlier in this thread about assoc membership and having a say in the project going together. We just have to ensure that membership is accessible for everyone (which IMO is the case with the Community membership tier) and that anyone feels welcome as a part of the assoc. But that is something everyone of us has to work on (and given that we have 1000+ members we don't seem to be such an unwelcoming crowd…).
| In consultation with the Unit Council, the Unit Coordinator must publish | ||
| rules and objective acceptance criteria for contributions on a suitable | ||
| platform, as specified by the TYPO3 Association Board or the Unit | ||
| Charter. |
There was a problem hiding this comment.
How does this fit with the current situation where different teams have very difference acceptance criteria, e.g., the Documentation Team works in quite a different way compared to the Best Practices Team, which works in different ways than the Education Committee?
There was a problem hiding this comment.
Hi @oliverklee! The intention is that Units should work with the same acceptance rules and criteria. The Unit Cooperation Panel has the additional responsibility of "Coordination and harmonization of Contribution Rules and Acceptance Criteria" (Section 4.1, point 3). The goal with this is to make collaboration and contribution easier both within Units, between Units, and from the outside.
There was a problem hiding this comment.
I understand the intention. Still, your reply doesn't answer my question. My question was and is how uniform acceptance criteria for a unit can cater to different teams/working groups within a unit working in quite different ways and hence would require different acceptance criteria (and in general, different ways to organize their work).
And to reword this: I think that having uniform acceptance critieria and uniform ways to organize things within a unit is a problem and does not fit well with the teams working in different ways, i.e., doing what works best for them.
There was a problem hiding this comment.
Hi @oliverklee! Your wish for full independence and self-determination, at the level you describe, may be incompatible with the wish for harmonization as a way to make collaboration and contribution easier. A goal for the Unit concept is to avoid isolation and silo thinking. At the same time, harmonization does not mean that specific needs cannot be addressed within that search for unity.
There was a problem hiding this comment.
@oliverklee I think this is not as big of an issue as it may seem at first. But I think we clearly lack widely accepted criteria for what constitutes a good contribution, at least from some examples I've seen over the past few months, where contributions were shot down with "I don't like that" (paraphrased) instead of giving helpful feedback.
I think this is also something that the "old crowd" (not pointing to anyone specifically here, just a general observation) has to get accustomed to: our role in the project must and should change a bit. Since we all have quite a few years of experience on our back, we must not forget that not everyone has that much experience, and also mentor people with less experience into a direction where they can gain our level of experience (or, even better, more experience).
To me, that also means that any feedback we give to everything someone else does should always be helpful, up to a certain degree – if something is clearly against established policy, that should also be pointed out, but it should be clearly stated. And, probably more important, these squishy "this is how we do it here" rules must become more codified. Yes, dreaded bureaucracy, but what we're doing here is serious business, not your average weekend escape-from-reality project.
|
In the news article, it says:
In our team meeting today, I asked our leader whether the team leader meeting officially came to a decision on accepting these documents. He said that he was not aware of any such decision having taken place at the meeting. So the news article is either incorrect: The way I understand it, the documents were presented at the team leader meeting, but not accepted. |
Hi @oliverklee! Your team leader is correct, and the article also states, that the "documents were presented to the Team Leader Meeting." The documents are still in review, so they can be improved and questions answered. It follows that no official decisions have been made. Your quote from the article is also clear on what happened: "The documents were accepted […] as the basis for this public consultation." To elaborate: The Team Leader Meeting performed an exhaustive review of the text. Many questions, improvements, and concerns were discussed over several hours. Afterwards, the group agreed that this community review round could start, and a deadline was set. |
| """"""""""""""""" | ||
|
|
||
| Though Unit Members should be awarded a large degree of freedom in task | ||
| selection, Unit Members answer to the Unit Coordinator and must fulfill |
There was a problem hiding this comment.
| selection, Unit Members answer to the Unit Coordinator and must fulfill | |
| selection, Unit Members answer to the Unit Coordinator and are expected to fulfill |
There was a problem hiding this comment.
Plus maybe something expressing something like this:
A volunteer must not be pressured against their will to fulfill a task, but active effort must be spent on issues the Unit coordinator / team prioritizes and schedules. Mediation and conselling is available to resolve issues.
As a team member, the preface is to work as a unit and not in fractured, unfocussed bits an pieces.
(Not happy with the words, but maybe this takes the edge off? @oliverklee @mabolek ?)
There was a problem hiding this comment.
Thank you, @garvinhicking!
I'll take this back to the Governance Working Group.
PS! "Are expected to" isn't part of RFC2119's list of definitions (see Note on imperatives). I wonder if what you're suggesting is effectively a move from "must" to "should." For more clarity, feel free to elaborate on how you understand it.
There was a problem hiding this comment.
In informal German legalese, what I learned is "'soll' ist 'muss' wenn kann" (roughly translates to "should means must if one can do"). So yes, "should" is probably close to "expected to". You still can not do that, but the expectation is otherwise.
|
I still don't know what specific problem this new structure is trying to solve. I'd assume someone (who?) identified these problems before starting to come up with a concept, and publicly documented these problems. This would also allow reviewers to determine whether this concept can solve these problems, and reject or modify parts that do not contribute to solving these problems (just like reviewing code changes). Where can I find the document listing the problems that this concept tries to solve? I also suggest linking that document from this document. |
|
I realize "core" is in unit "Feature" and "Stability & Compliance". Obviously, there will not always be agreement on core features and changes due to different priorities (simplified: features vs. stability). my question: Who decides on core features and changes? Is the final say in the TYPO3 core team? What is effectively expected to change for development of the TYPO3 core product with this new structure? Also, I find it a bit odd that the core mergers and component mergers are in "features", not in "Stability & Compliance". What is the role of the core mergers and who decides which merge requests get merged? (apart from the already existing voting system). |
|
Hi @oliverklee!
The Unit concept attempts to solve underlaying problems that were uncovered as a part of the Association's strategy process. There are two foundational documents:
Links to these documents were indeed missing from the article inviting the community to review the Rules. Thank you for pointing that out. I have now added the same information to the end of the article. Numerous articles have also been published during the last three–four years, but I won't link them here, as they are snapshots in time and also contain ideas and concepts that are no longer in discussion. However, I think Stefan Busemann's recent article has good perspectives on the current efforts. |
|
Hi @sypets! Thank you for taking the time to review the Rules for TYPO3 Units!
There are two aspects to distinguish between:
The Unit Cooperation Panel is intended to act as the Product Owner. It creates and prioritizes the Product Roadmap based on the Product Strategy and input from the Units. The Units are then responsible for implementing the roadmap within their respective areas. For Core development, the change is mostly about responsibilities and coordination, rather than replacing technical development processes. Regarding Core Mergers and Component Mergers being shown under Feature, I would not interpret the illustration as a final. It gives examples of topics only. The exact composition of the Units will be defined in their charters, which will also come up for public review. The exact internal organization is deliberately left to the Units — and the Units will also have to collaborate. For individual contributions, the important change is that the Unit becomes accountable for defining and documenting how contributions are accepted. Each Unit must define objective acceptance criteria. (In coding terms, "acceptance" means "merging." Not all Units' activities depend on merges.) The Unit Coordinator has ultimate responsibility for acceptance, but it can be delegated. I mean: The Coordinator should not personally decide on every merge request! This means that the existing review and voting mechanisms could continue. There is still work to do in defining how a feature moves from an idea to the Product Roadmap, implementation, review, and acceptance, and how responsibilities between Feature and Stability & Compliance work in practice. This product-development process does not belong in the Rules and is intended for the Units and the Unit Cooperation Panel to define. |
|
What concerns me almost as much as the individual flaws is the process that allowed a proposal of this magnitude to reach public review in this form. This is not a minor procedural update. It fundamentally changes how authority, membership, task allocation, contribution acceptance, voting, and accountability work inside the TYPO3 project. A proposal like this should have been subjected to explicit adversarial review before publication: not just “does this work when everyone acts in good faith?”, but “how can these powers be abused, how can an incumbent entrench themselves, how can conflicts of interest arise, and what checks prevent that?” Several of the issues below become apparent within a relatively short, systematic review of the rules as a whole. If these risks were not identified beforehand, that points to a serious failure of processual competence in the governance review itself. If they were identified and deliberately accepted, then the community deserves a clear explanation of why these concentrations of power were considered necessary and sufficiently safe. For a governance reform this fundamental, relying on good intentions is not enough. The rules have to remain robust even when future officeholders are biased, conflicted, ineffective, or acting in their own interest. I created a very detailed analysis of the issues but compiled the biggest concerns into a 10 point list which I think have to be addressed. a) The Coordinator can shape the electorate.The Coordinator decides on new Unit Members “in consultation with” the Council, while Supporters have no Unit voting rights. This means the person being elected has substantial influence over who gets to vote in future elections. b) Task assignment can indirectly affect voting membership.Member status can expire after six months without an assigned task or activity, while the Coordinator controls task delegation and can also grant exceptions. That creates an obvious risk of selectively retaining or losing voting Members. c) Members can be required to perform work they did not choose.Members “must fulfill delegated tasks promptly,” while Supporters may decline tasks freely. This creates a managed-volunteer model where political participation in a Unit is tied to accepting assigned work. d) The Coordinator has broad “final say” over operations.The Coordinator has final say over mandated tasks and day-to-day operation. The boundary between this authority and binding Council decisions is unclear, especially when the Council disagrees with the Coordinator. e) Ultimate contribution acceptance is concentrated in one role.The FAQ explicitly states that ultimate acceptance, including code merge decisions, is up to the Coordinator, even if delegated. This gives one office both managerial and technical gatekeeping power. f) The Council’s role is often only consultative.On important subjects such as membership, long-term prioritization, budget policy, internal structures, and contribution rules, the wording says the Council “should be consulted” rather than requiring Council approval. g) Removal of a Coordinator is weakly protected.The Council cannot directly remove its Coordinator; it can only petition the Association Board. This makes accountability asymmetric: the Coordinator has strong authority over the Unit, while the Unit has limited direct authority over the Coordinator. Where personal, professional, or employer relationships overlap between Unit leadership and Association governance, the absence of a direct recall mechanism makes this protection even weaker. h) There are no term limits.Coordinators serve one-year terms but can be re-elected indefinitely. Combined with influence over membership and task allocation, this creates a clear incumbency and entrenchment risk. i) One person can hold powerful roles across multiple Units.The proposal explicitly states that “any role in a Unit may be combined with any role in another Unit.” There is no apparent restriction preventing one person from coordinating multiple Units simultaneously, nor is there an apparent employer-level concentration limit. In principle, this allows a single employer — including TYPO3 GmbH — to accumulate substantial influence across several or even all Units if enough of its employees are elected or appointed. j) The model adds barriers while claiming to improve participation.Full Unit participation requires Association membership, sustained activity, acceptance of delegated work, reporting obligations, and role-expiry rules. For a project that needs more contributors, this looks more likely to discourage independent volunteers than attract them. None of these points requires assuming bad intent. The problem is that a governance framework should remain safe even under a hostile, self-interested, or simply ineffective officeholder. As written, too many operational, membership, technical, and electoral powers are concentrated in the Coordinator role without strong enough counterweights. |
|
Hi @Lefaux! Thank you for the thorough review. The purpose of this community review is precisely to identify questions and potential weaknesses in the proposal. The documents have already gone through review and feedback that led to changes and additions to the FAQs. The current community review is another step in that process. The proposal does not try to define every possible operational detail. It establishes responsibilities and a framework within which the Units can define their processes themselves. Several of the scenarios you describe are useful as governance stress tests. However, it is important to distinguish between a mechanism that could theoretically be abused and the intended operation of that mechanism. For example, the Coordinator's authority to assign tasks is intended to ensure that results can be reached, not to control the Unit's electorate. Similarly, the distinction between Unit Members and Supporters is intended to accommodate different levels of commitment, as explained previously in this thread. Some of what you bring up concerns safeguards, rather than the intended responsibilities themselves. While some of these points have already been discussed, others are should be taken into consideration. The proposal already provides several safeguards, including annual elections, Council involvement, public documentation, and accountability to the TYPO3 Association Board. The Conflict of Interest Management Policy is also being revised to explicitly cover Unit Coordinators and Unit Cooperation Panel members. I'll take this back to the Governance Working Group. As with all feedback given here, it will help determine if the proposed rules need additional safeguards or clarification and whether the intended interpretation could be made more explicit in the rules or FAQ. |
|
Thank you for the response. I think this gets to the core of my concern, though. Governance rules cannot primarily be evaluated based on their intended operation. They have to be evaluated based on the powers they actually grant and the abuse they actually prevent. Saying that task assignment is intended to ensure results rather than influence the electorate does not address the issue that, as currently written, task assignment can affect membership status, while the Coordinator also influences admission to membership and is then elected by those Members. The same applies to the other examples. I am not claiming that the Governance Working Group intends Coordinators to abuse these powers. I am pointing out that the rules appear to make such abuse possible. That is precisely what governance rules are supposed to protect against. I have been involved in the TYPO3 ecosystem for considerably longer than most people participating here, and I have seen this pattern more than once: rules were designed around how they were intended to be used, with a fairly naive assumption that people would continue to act within that intent. Later, those same rules were stretched or abused in ways that caused substantial problems precisely because the safeguards were not built into the rules themselves. Annual elections are not a sufficient safeguard if the incumbent can influence the composition of the electorate. I also struggle with the argument that these are merely “operational details” which Units can define themselves. Questions such as who controls voting membership, who can remove whom, whether a majority vote is binding, whether one person may coordinate multiple Units, and whether the person assigning work can indirectly affect the electorate are not implementation details. And this leads back to my original concern about the review process. Community review should certainly find additional problems and improve a proposal. But the community should not have to discover basic checks-and-balances issues that follow directly from combining the powers defined in the document. The distinction between intent and possibility is therefore essential here. Good governance does not require us to trust that future officeholders will use their powers only as intended. It deliberately limits what even a bad officeholder is able to do. “That is not what we intend the power to be used for” is not a governance safeguard. And similarly: Public documentation does not prevent selective non-assignment. The rules require documenting assigned tasks and role decisions, but I see no requirement to document why a specific Member was not assigned work. Since lack of assignment can contribute to membership expiry, the potentially abusive act may be the absence of a decision rather than a documented decision. For the technically minded: this is like writing a unit test for an email field and only testing one valid email address, while never testing If the conclusion of this review is that additional safeguards are required, that is welcome. But I would strongly suggest treating the identified issues as structural governance problems rather than merely clarifying the intended interpretation in the FAQ. If an abuse is possible under the rules, the solution should be in the rules. Finally: The review process itself excludes non-technical stakeholders.The proposal affects far more than developers. It affects agencies, employers, freelancers, project sponsors, executives, and others whose businesses depend on TYPO3. If the governance process is only easily reviewable by people who already understand the project's technical tooling, then the review is not genuinely accessible to the full community it claims to govern. |
|
I want to back @Lefaux here, because this is the crux, not a side issue. There is a recurring pattern in the replies: concerns about what the rules permit are answered with what the rules are intended to do. "The Coordinator's authority is intended to ensure results, not to control the electorate" does not resolve the concern. As written, that same authority can shape the electorate, whatever the intent. Intent is not a safeguard. The rules are. That is the whole purpose of an adversarial governance review, and @Lefaux states it precisely: good governance limits what even a conflicted or bad-faith officeholder is able to do. "That is not what we intend the power to be used for" is not a check. Concretely: where an abuse is possible under the rules, the answer should be a change in the rules, not a clarification in the FAQ. Recording a concern in the FAQ documents it; it does not constrain the power. @rfoucard already pointed the same way for conflicts of interest, that the safeguard belongs in the policy and should be referenced from the rules. The same logic applies to the other points Lefaux raises: membership control, activity-based expiry, a Council that is only consulted, indirect removal, multi-Unit and single-employer concentration, and term limits. So my ask to the Working Group is concrete: treat these as structural questions to be answered in the rules themselves, and state clearly which of Lefaux's ten points will lead to rule changes and which will not, with the reasoning. That is the honest way to close a review like this. |
|
Thank you for the support. My request sits one level deeper, though. For a governance change of this magnitude, adversarial scrutiny is not something I merely expect. It is something the process itself has to require. Anyone involved in designing, reviewing, or approving such a fundamental redistribution of authority has a responsibility to test the proposal against foreseeable abuse, conflicts of interest, power concentration, incumbency effects, and failure modes before it reaches public review. Since I do not assume malicious intent or incompetence, I have to assume that these issues were identified, weighed, and ultimately considered acceptable. That is why I am not primarily asking for a rule change. I am asking for the criteria and reasoning that led to these risks being deemed acceptable in the first place.
If these risks were not identified at all, then the problem is no longer just in the wording of individual rules. It is in the governance process that produced and reviewed them. Patching ten clauses after community feedback does not answer that deeper question. The process must be capable of detecting these issues before publication. If it is not, then the process itself is inadequate for changes of this importance. |
|
Hi @Lefaux and @Esders! Thank you again for taking the time to participate in the ongoing review process. I don't want to pre-empt the Governance Working Group's decisions, so I can only explain the intent and interpretation of the current proposal. As stated above, the Governance Working Group will discuss all feedback given. As with previous review rounds, feedback will be assessed and may result in changes to the proposal or additions to the FAQ. This is intended to give Association Members the possibility to assess not only the proposal itself, but also the reasoning behind decisions to change or not change it. I do want to clarify how the process is being framed, though. The proposal has gone through reviews, some issues have already been addressed, and the current public review is explicitly intended to uncover further issues. It should therefore not be understood as a finished or perfected proposal. Asking for feedback and improvements would be contradictory to that. Some decisions will also necessarily involve opposing concerns and different considerations. The Governance Working Group will have to make choices about what should carry more weight, and there may be legitimate disagreement about those choices. I hope we can keep the discussion focused on concrete changes or additions that you would like to see in the rules — or agreement to previously suggested changes. Feedback earlier in the process has taught us that many prefer shorter and focused documents to review, rather than long and all-encompassing works. The purpose of this review is to give the Governance Working Group concrete input to consider, rather than to resolve governance questions individually in the comment thread. Alongside this and subsequent proposal reviews, the TYPO3 Association is also working on better communication and platforms for dialogue on general governance topics. Recent articles on news.typo3.com, participation at events, and initiatives such as the Dialogue Days and the governance-focused booth at the Developer Days are examples of this ongoing effort. I especially encourage TYPO3 Association Members to make use of the opportunity to contact and discuss these proposals with their elected representatives. |
|
@mabolek, you asked to keep this focused on concrete changes, so here are concrete, rule-level requests. They follow from the points @Lefaux and I raised and from @rfoucard's input. The common principle: where the rules make an abuse possible, the fix belongs in the rules, not in the FAQ. Documenting intent in the FAQ does not constrain the power.
On process: this public PR is the review channel the Working Group set up, so I am raising these here as concrete requests, as invited. I would ask the WG to state, for each point, whether it will lead to a change in the rules and why, so members can see the reasoning before the General Assembly. Thanks again for engaging. |
|
Hi @Esders!
This is very much appreciated. Conflict of interest (1), panel representation (2), and term limits (5) are already on the list from previously. I will make sure that electorate protection (3) and removal (4) are added too. You will be tagged here when the results from the Governance Working Group are ready. |
|
A large part of what concerned me when reading this proposal has already been articulated very clearly by @Lefaux and @Esders. In particular, this applies to the concentration of powers in the Coordinator role, the risk of incumbency and capture, the relationship between task assignment and voting membership, employer conflicts, recall, and the important distinction between documenting an intended use of power and actually constraining that power in the rules. I support those concerns and don't want to repeat them. There are, however, a few additional structural gaps that I think are significant enough that they must not be left to implementation details or FAQs. Quorum creates an additional veto that has not been discussed yetSection 3.1.5.e requires half of all Council Members and either the Coordinator or Deputy Coordinator to be present for the Council to reach quorum. The only explicit exception is the petition for removal in 3.1.5.h. This means that Coordinator and Deputy can jointly prevent the Council from making any other decision simply by not attending. This becomes especially relevant if the Council is now intended to become a genuine counterweight and if more subjects are changed from "the Council should be consulted" to requiring Council approval. A properly convened Council must be able to reach quorum without either officeholder being present. Otherwise strengthening the Council on paper simultaneously gives those same officeholders a boycott veto over that Council. There is no effective appeal or independent review mechanismI cannot find a defined appeal path for decisions that negatively affect an individual's membership, role, or contribution. Referring somebody to the Board, Ombudspersons, or a petition process is not the same thing as a defined right of review. There is currently no clear requirement for an adverse decision to be reasoned, no review standard, no deadline, no recusal requirement for the reviewers, and no defined remedy. This becomes particularly important for membership admission or removal, role expiry, and contribution acceptance. The latter is especially relevant because the rules require objective acceptance criteria while simultaneously allowing the Coordinator to override them and giving the Coordinator ultimate responsibility for acceptance. At minimum, such decisions must be documented with reasons and must be reviewable by people who were not involved in the original decision. Volunteer accountability must start with acceptance of a task, not assignment of a taskThe discussion around changing "must fulfill" to "should" or "are expected to fulfill" bears the risk of treating this mainly as a wording issue. I think the underlying distinction needs to be made explicit instead. A Unit must be able to set priorities and decide that Feature A is more important than Feature B. That does not automatically mean an individual volunteer must be required to work on Feature A. For volunteer work, accountability must begin when a contributor explicitly accepts a task. Once accepted, it is reasonable to expect progress reporting, responsible completion, or returning the task if circumstances change. If the Unit has a mandatory deliverable for which nobody voluntarily accepts responsibility, that is a capacity problem. The available responses are to reprioritize, reduce scope, recruit additional capacity, or fund the work. Merely assigning the task does not magically create that capacity. Otherwise Unit governance rights remain indirectly conditional on accepting directed unpaid work, which I don't think is an appropriate model for an Open Source community. The initial electorate needs the same safeguards as the later electorateThe discussion has already identified the risk of an incumbent influencing the electorate that later re-elects them. The same adversarial test must be applied one step earlier. The current transition description says that existing team members will be listed and then the list will be "reduced" to those who qualify as initial Unit Members based on their current level of contribution. The Charter will then contain the initial Members, who elect the first Coordinator. Whoever performs that reduction therefore effectively seeds the first electorate. I understand that the transition process is still being drafted separately, so the detailed solution may belong there rather than in this PR. But before the new structure becomes effective, the transition rules must contain objective and published eligibility criteria, transparency about how the initial Member list was derived, and a review mechanism for disputed exclusions. Otherwise the safeguards against electorate capture only start after the most consequential electorate has already been selected. None of these points argues against Units, clearer responsibilities, or stronger accountability. They are consequences of formalizing authority. Once authority is made explicit, the corresponding checks must be explicit as well. I would therefore suggest adding these points to the Working Group's review together with the issues already raised by @Lefaux and @Esders. These safeguards must be addressed at rule or transition-rule level before the proposal goes to the General Assembly. Otherwise, we are creating a governance model in which a handful of reasonably well-coordinated people could, in the worst case, obstruct or effectively sabotage substantial parts of the project while remaining entirely compliant with the rules. And that is precisely the kind of scenario governance rules are supposed to prevent, rather than merely assume will never happen. |
|
As I noted on #50 I want to share this here as well: We fix security issues in TYPO3 - regardless of what the intent of the code was. |
|
I would like to add another perspective on the Unit Coordinator role. In my view, concentrating the role in a single person is problematic not only because of potential conflicts of interest or the amount of decision-making power involved. The proposed role is also operationally very broad and complex. The Unit Coordinator is expected to:
These responsibilities represent several distinct functions and require different skills: people management, project management, strategic planning, administration, communication and governance. Although a coordinator is elected for only one year and can delegate tasks, the rules do not require these responsibilities to be distributed among clearly defined roles. If one person retains most of them, this creates considerable key-person dependency. This could make it difficult to find a viable successor. A new coordinator would need to take over not only a leadership position, but also extensive operational knowledge, relationships and administrative responsibilities. If a coordinator leaves unexpectedly for personal or professional reasons, the Unit could become vulnerable—even with a Deputy Coordinator—because only a small number of people may understand or be able to perform the full role effectively. To support continuity and preserve the quality of a Unit’s operation, I would recommend allowing these functions to be distributed among several Unit Members. This does not mean that every Unit should be required to create a separate role for each responsibility. With a minimum Unit size of five people, such a requirement would be unnecessarily rigid and potentially impractical. Several related responsibilities could be combined into one role, or the Unit could decide that some or all of them should remain with the Unit Coordinator. The important distinction is how this decision is made. The distribution of these responsibilities should be decided by the Unit Council as part of the Unit’s internal structure—not depend exclusively on delegation by the Unit Coordinator. A delegation made solely by the coordinator can also be withdrawn solely by the coordinator, meaning that the underlying concentration of authority remains unchanged. The rules could therefore allow each Unit Council to decide whether responsibilities such as operational coordination, membership matters, governance, reporting or strategic planning:
The Unit Coordinator could remain the Unit’s primary representative and accountable contact to the TYPO3 Association Board. However, responsibilities assigned by a Unit Council decision should not be changed or withdrawn unilaterally by the coordinator. This would preserve the Unit’s flexibility and self-management while reducing key-person dependency. It would also make succession easier, retain operational knowledge within the Unit and allow responsibilities to be carried by people with the most appropriate skills. (Also it would make another level of engagement accessible for the unit members) |
@mabolek But, why? The decision to require a membership in the TYPO3 Association for unit members is arbitrary and needs a good reason, not just some vague views and assumptions. Currently, I don't any valid reason presented in the document or in the discussion. I'd assume either this is a copy'n'paste artifact from the DRK template, or this was put in place deliberately for reasons not listed. These reasons need to be out in the open, or the requirement should be removed. |
@mabolek I think that these "opposing concerns and different considerations" need to be cited here as part of the discussion. Otherwise, they serve as a blanket permission to ignore valid concerns and questions. |
@mabolek Thanks. These documents range from reasonably specific to very vague, marketing-style texts. Having this mixture and having the issues and goals distributed across several documents make a careful, responsible review of the new rules almost impossible, particularly in regard to this question: Which issue or goal does each single part of the big overhaul address? Is that part suitable to solve that particular problem or help work towards a particular goal at tall? And if it's not clear both to the authors as well as the reviewers which specific issue or goal is addressed with a sentence/rule/part, that sentence/rule/part needs to be changed or removed. (Plus the check for robustness against a hostile takeover and misuse of power etc.) And as long as a careful review in regards to the requirements is not possible, the new rules are in no shape to get reviewed and presented to the GA. I have the impression that the new rules need to be conceptually reworked instead of only "polished here and there". And first, the specific issues to solve and goals to achieve need to be identified and listed in a public document that reviewers can check the rules against. |
|
Having read the proposal, the discussion and feedback, I dare to bring back some hopefully helpful ghosts from the past. Without boring you with history, the inception and the first revision of the associations by-laws bear ample resemblance to what is going on here. Hiding a governance overhaul of this magnitude in github reminds me of putting it in the basement in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard". I am not trying to make fun of this, but when planning an interstellar superhighway the same rules apply as for reorganizing an NGO: do everything in plain sight and get all the buy-in before the planning. Back when founding the Association, we got just that wrong: "surprising" everyone with well-intentioned work and in turn we were surprised and frustrated when not everyone greeted the freshly minted TYPO3 Association with cheers and sighs of relief. We then ran the course for a few years and reworked it with the help of legal councilors specialized in NGO's. We even spoke to NGO's that had been living with the structures we were proposing for a while. That was quite embarrassing actually. Because what we really learned is that no problem we encountered wasn't trivial and that organizational patterns exist for all of them. My learning: Don't reinvent the wheel, don't even find new names for structures. Most importantly don't think you can ever insert new structures into an existing organization of volunteers without loosing a lot of momentum - and people. I am aware the Association has undergone many revisions and re-organization efforts in the mean time and all of those hold lessons in store, that you are more knowledgeable about than I am. What I do mean to bring back from the early days before many of you were there is this: 1. never assume good intentions are enough to design a working organization 2. never try to be innovative in a field that others have been at for decades. It just draws energy from your main effort and you will be sure to make avoidable mistakes. 3. don't be afraid to back out and start fresh, when your first attempt gets stuck. Chances are your attempt won't recover. 4. don't take it personal and, of course, don't panic. All the best, Daniel |
|
I have carefully reviewed the different comments. I will focus my recommendations on the points that contribute constructively to improving the proposal and can lead to practical solutions. I would therefore like to continue @Esders list to keep track on topics that can be concretely improved. (my additions in italic)
Coordinator workload and key-person dependency This is a valid concern from @DigitalZombies based on the current proposal. However, several responsibilities identified here— particularly membership decisions, task assignment, and the acceptance of contributions— are already being challenged in this discussion and may be transferred to the Unit Council. I would therefore recommend to first revise the distribution of authority and then reassess the Coordinator’s remaining workload before introducing additional formal roles. |
|
Hi! A big thank you to everyone who has been contributing to the discussion during the weekend. I'll return to some of you with comments on intent and interpretation. Generally speaking, everything is read and discussed by the Governance Working Group, even if it's not commented on directly. To enable the best possible conversation, I would like to add some general remarks based on the discussion thus far: Note
|
|
Hi @DigitalZombies! Thank you for taking the time to review the Rules for TYPO3 Units.
I think you are pointing out something important. I think the essence has always been the intention, but it should be made clearer and emphasized in the text. It's maybe an additional point to add to the list of areas where Unit Council should be consulted (which effectively means they must be consulted, unless in exceptional cases). The point that needs to be explored further is the role of delegation versus accountability. Accountability may also mean that some authority is necessary that cannot ultimately be delegated. Some tasks are the responsibility of the Unit Coordinator. You mention some good examples: operational coordination, membership matters, governance, reporting and strategic planning. Even if they can be delegated in practice, the Unit Coordinator is ultimately responsible for making sure they happen — because a failure to do them would ultimately be detrimental to the project and the unit's health. |
|
Hi @oliverklee!
Some have already been mentioned, such as weighing up the concerns about a requirement for TYPO3 Association Membership vs. a need for control over "the TYPO3 Association Members' money". They are discussed when they appear. Deliberations around concerns and considerations as a background for decisions about what to say in the Rules ultimately belong in the FAQ as statements by the Governance Working Group. |
|
Hi @oliverklee!
The connection between the governance model and the problems it is intended to address needs to be understandable. This is also one of the reasons the review includes the FAQ and the broader contextual material. Context also exists on different levels, thus the difference in the materials. However, this needs to be kept separate from a requirement that every individual rule to be mapped to a specific strategic goal. The rules have a more specific purpose, such as to define responsibilities, decision-making framework, and accountability of Units and the Unit Cooperation Panel. They are not intended to contain the complete rationale for TYPO3's governance strategy or to replace the broader strategy and governance documents. Some individual rules can therefore support several goals, while others are primarily there to make the overall framework coherent and operational. The current documents are also deliberately focused. Previous feedback during the process was that governance documents should be shorter and more focused so that they can realistically be reviewed by contributors in their free time. Adding a comprehensive catalogue of every problem, goal, rationale, and relationship to every rule would work against this goal. This is another point where different considerations are in opposition to each other. |
Well, that makes it impossible for reviewers to determine whether these changes are suitable (and required in the first place) for solving these problems or achieving these goals. |
|
Hi @hiq-lab!
Thank you for taking the time to bring the ghosts to our virtual ouija board.
I appreciate the Douglas Adams reference. I don't know if we're in quite a comparable situation to Arthur Dent's house or Earth. The link to this GitHub repository is only the most recent step in the process. News about the process has been published on news.typo3.com and included in TYPO3 Association Member newsletters. That is not to say that the last years have been without important learnings on the communications front. I would venture to say that putting policy up for review on GitHub is a result of those learnings and a major step towards better transparency and community involvement.
Those are indeed good points. I wouldn't say that they were missing from the process — there have certainly been steps back and fresh starts along the way — but the importance of capturing institutional knowledge cannot be understated. It is one of the goals of the ongoing governance work. We may need to produce another set of TYPO3 towels. |
|
Before I spend time citing what science says about motivation: Is this proposal in the state "we still would like feedback on whether this fundamentally makes sense, is helpful and doesn't do any harm", or is it in the state "we've already mostly decided to do this and will only accept feedback on wording, spelling and cleanup, and will disregard comments on the big picture"? |
Hi @oliverklee! The scope of this review is not limited to wording and cleanup. This is a proposal, and the final decision is up to the Association's members. As stated in the original review invitation and previous comments, feedback may lead to changes to the proposal or additions to the FAQ. |
@mabolek So, just to be sure I understand your correctly: The GWG (not the GA) be willing honestly consider to and to potentially change fundamental things about the whole concept, correct? (@rfoucard's comments and your own comments so far sounded more like "please only change the wording", which would contradict this.) |
14 participants
Note
Please read the article introducing the review round before starting your review here.
Added 24 August 2026: To enable the best possible conversation, here are some general remarks based on the discussion thus far:
Note