1. Centralized Coordination
Most of work is actually managing day to day communication: Answering technical questions, funneling ideas or identifying possible severe existing issues, connecting the right people to the according necessary tasks. This job can take up a lot of time during the working day, but is necessary to keep contributors motivated and pushing topics in development forward. This is not a decision-makers’ position, but more a person with a reliable time frame to be available for contributors, new initiatives etc on a day-to-day basis. We call this position the Open Development Manager. This position is open for anyone to apply, however, it should be clear that this position takes up a lot of time during daily business hours, so the employer should be involved when applying for this position.
2. Overall Strategy vs. Improving Core’s Code Base
The roadmap and strategic decisions need to be taken by people who have a different responsibility than people who want to ensure TYPO3 Core has a clean code base. The existing Core Product Team - consisting of Oliver Hader, Susanne Moog, Tymoteusz Motylewski and Benni Mack - will take over the strategy part (Susanne Moog and Oliver Hader being employed by TYPO3 GmbH) to align TYPO3 Core goals with the overall strategy of the TYPO3 ecosystem strategy.
One person needs to take final decisions - this will be the previous Core Team Leader - the position we now call TYPO3 Project Leader.
The previous “Core Team” - people who coordinate reviews, merges and the people who are responsible for every single line of code in TYPO3 Core, we now define as a group of developers with full merge access to all relevant parts of TYPO3 Core development. Each person within this group needs to have a full understanding of the whole TYPO3 Core functionality, align with rules given by the TYPO3 Project Leader with a full commitment on their time and quality and security perspective on a developer basis. People with these merge rights are now called “Framework mergers”, and will be appointed by the TYPO3 Project Leader (you can apply for this position as well, see below). This will be a small group of maximum 8 people to get quick and direct communication and technical decisions.
To sum it up: Framework mergers ensure that TYPO3 Core’s APIs get even more consistent and streamlined.
3. Components
We’ve identified that there are parts of TYPO3 Core that can be easily maintained by a separate group of people responsible for only a specific area - let's take Fluid, Form Framework or SEO, which these people can focus on exclusively, as they are specialists in that area. We want to invite people to take this responsibility and work separately and aligned with the Product Team, but with significant more freedom on how to progress and how to work together on one specific component. We’ve identified components, which are not solely based on a “per system extension level”. There is one head of development for this component, which we call Component Merger - this person has merge rights to bring changed / modified code in there without having to discuss every detail with the Framework mergers.
4. Initiatives
We like the initiatives as it allows for anybody to join a certain topic without having to know every little detail of the Core API. It is also the door-opener for innovation and new features - which might be released as an "A-Class Extension" with a certain quality standard, or a new part of TYPO3 Core. Initiatives have a separate roadmap regardless of the TYPO3 Core releases, but only when they are feature complete and ready for integration in Core, Framework mergers will come into play. Organization is done by the centralized coordination, so things move forward - each initiative at its own pace. We think it's a great idea to deliver great functionality - once finished, get it in.
These parts in total build a new development structure and contribution workflow, as follows.
