Core Development

The TYPO3 Core Development Team is dedicated to develop and maintain the central parts of our favorite CMS.

Mission Statement

"To Jointly Innovate Excellent Free Software Enabling People to Communicate."

The TYPO3 Core Development Team endeavors to make TYPO3 the best of its breed. To achieve this mission it pursues the following goals

  • maintain and enhance the TYPO3 core
  • ensure TYPO3 source code quality
  • be a pillar of the community

TYPO3 Project Lead

In case you have questions, feel free to contact Benni Mack.

Please understand that technical support requests will be ignored. You are kindly asked to use Slack instead.

Current strategic development initiatives

A “initiative” consists of people with a common interest to make long-term improvements in a specific area in TYPO3 including strategic plans, goals, task-breakdown and monitoring of progress.

Dashboard Initiative

The Dashboard initiative aims to bring a multi-purpose dashboard to the TYPO3 backend.

TYPO3 Dashboard Initiative

Localization with Crowdin

Use the SaaS solution Crowdin for localization instead of Pootle. This allows us to improve the process and output of localization TYPO3 Core and TYPO3 Extensions.

Localization with Crowdin Initiative

PWA Initiative

Progressive Web Apps are a hot topic currently. It allows mobile websites to look and feel like native apps, work offline or be installable and more. TYPO3 should make it easy to build progressive web applications.

PWA Initiative

Find more TYPO3 core development initiatives

Roles & Responsibilities

    While everyone is welcome to participate and contribute to TYPO3's development, there are a few formalized positions with additional responsibilities, tasks or efforts. People in these positions all share the long-term goal to improve the whole TYPO3 Core and its components while maintaining the existing stable branches at a maximum quality level.

    Components are parts of TYPO3 Core or subsystems with a certain focus on one area.

    A component merger is responsible for this code, functionality, backwards-compatibility and architecture and future development. A component merger has direct merge rights to this component. Any change can however be overruled by a Framework Merger or TYPO3 Project Leader. If a change touches various places outside of the component. 

    A component merger is responsible for developing a vision for this component for future improvements, and communication of this vision together with the TYPO3 Project Leader. A component merger must be in touch with the TYPO3 Project Leader at least once a month on a status update, blocking issues or questions to continue in this area. Any violations to misusing the merge rights or miscommunication can lead to immediate revocation of this status. 

    The following components are currently in place:

    ComponentDescriptionCurrent Component Merger
    CLI IntegrationSymfony CLI integration and EXT:schedulerBenjamin Franzke
    Content Editing Experience + RTERTE API and CKEditor IntegrationJosef Glatz
    DocumentationCore Documentation / RSTs / Manuals maintained within TYPO3 Core RepositoryDaniel Siepmann
    Extbase + Plugin APIExtbase Plugin FunctionalityAlexander Schnitzler
    Fluid Engine + Fluid Integrationstandalone Fluid Template Engine and Fluid system extensionClaus Due
    Form FrameworkForm system extensionRalf Zimmermann
    Issue Tracking / ReportingTicketing system structure, bug triagingRiccardo De Contardi
    LoggingAPI + IntegrationsArno Schoon
    Performance / CachingCaching Framework and OptimizationsClaus Due
    Persistence + Database Layer + WorkspacesDataHandler, Doctrine DBAL and Overlay functionalityManuel Selbach
    SEOSEO system extension + Frontend MetaTag RenderingRichard Haeser
    Workspaces + Workflow ManagementContent Management / Publishing WorkflowDaniel Sattler


    New components are defined by the TYPO3 Project Leader.

    Not every part of TYPO3 Core is covered by a certain component (e.g. "Hooks", Dependency Injection or Extension API), but these overall areas are then responsibility of the TYPO3 Core Framework.

    Framework mergers are allowed to merge to any part of TYPO3 Core and its components and subsystems. This is a group of active people with enough knowledge of the architecture and feature-set of TYPO3 Core, as well as a broad perspective. Responsibility is to ensure a consistent, secure and stable API throughout all maintained branches of TYPO3 and its components. All members of this group are required to participate actively in helping other contributors to build a consistent API across the source code and documentation. All members ensure the code quality is increased and the feature set defined by the TYPO3 Project Leader is implemented properly. They are responsible for all parts of TYPO3 Core. It is required that all members know state-of-the-art technical functionality (currently PHP7, JavaScript/TypeScript, SCSS/CSS and HTML5).

    Regular communication with a maximum response time of 48hs within the framework merger group is required. In addition, it is necessary that framework mergers coordinate development in a monthly meeting call. A total of 8 (eight) framework mergers (excluding TYPO3 Project Leader and Product Team, which overrule changes by framework mergers) is planned to keep communication tight and effective.

    All framework mergers have full responsibility for every line of code or documentation within TYPO3 Core or their components, and are required to maintain actively on solving existing bugs or reviewing and improving existing changes.

    Current Framework Mergers
    • Andreas Fernandez
    • Anja Leichsenring
    • Benjamin Franzke
    • Daniel Goerz
    • Frank Nägler
    • Georg Ringer
    • Richard Haeser
    • Tobi Kretschmann

    The Open Development Coordinator is a technically skilled and strong communication person who is coordinating the day-to-day communication topics arising during core contributions, and has an overview of currently open issues or reviews that can be tackled by mergers or contributors.

    This person is responsible for bringing information and new topics to the right person, taking care of open questions of initiatives and mergers and answers questions related to core development on a daily basis. He/she is required to be in close contact with any other part of the contributors and has excellent communication skills. He/she is responsible for coordinating official news announcements.

    This person requires to be active during usual working hours, so applying for this job needs to have approval by his/her respective employers.

    Currently this position is not occupied, applications to TYPO3 Project Leader are welcome.

    The Product Team consists of the TYPO3 Project Leader and technically skilled people with a strong focus on the current development of the CMS market. The assignment of this team is to decide on functionality and implementation - to strengthen the brand, product and ecosystem from a technical and a holistic product view, not just from the technical side.

    The product team currently consists of:

    • Susanne Moog (Initiative Coordination, Mentoring)
    • Oliver Hader (Release Coordination, Research, Quality Assurance, Security Lead)
    • Tymoteusz Motylewski (Research, Development Coordination)
    • Benni Mack (TYPO3 Project Leader)

    This group is required to meet twice per month for coordination purposes, and twice a year in person for a multi-day strategy workshop.

    There are no open positions currently for the Product Team. It is required by each member to step down when appropriate due to insufficient activity or change of focus, or when asked by the TYPO3 Project Leader.

    In addition, TYPO3 GmbH is involved in advising for ecosystem products provided by TYPO3 GmbH, and responsible for the strategy of external communication.

    The Project Leader is responsible for the long-term product strategy, roadmap and release planning. He/she takes last decisions on the direction of the product, planned features or concrete implementations. Next to technical decisions, this also includes decisions on UX concepts, working mode process and infrastructure-based decisions for Core development as well as reaching out outside the TYPO3 community to broaden the view of the CMS market.

    Currently this position is filled by Benni Mack.

    House Rules

    Every member of the groups mentioned above must oblige to the code of conduct. Any member can be removed from his duties at any time from the TYPO3 Project Leader. As all members of these groups have a common vision, it is required that we all treat each other with respect and trust. It is important that not only the coding skills, but also the working mode within a team is taken into account when contributing.

    Any security-related information is not allowed to be exposed without authorization or public announcement from within the specified groups.

    When applying for a position, it should be considered that this will take continuous efforts for at least 6 months, as it is not planned to switch positions regularly. Members with revoked merge rights from a position must wait for 12 months before applying for any position again.

    All members of the groups mentioned above should re-evaluate their position at least every 6 months if the amount of time that needs to be invested can be handled in the future, as TYPO3 core development and contribution takes time, investment and effort. It is considered that all contribution is either done in spare time or supported by employers to make TYPO3 Core an excellent community-driven product. All members will have to re-apply for their position every 12 months.

    Merging

    Merging is the acceptance of a change (patch) to be added into TYPO3 Core codebase or its components. All mergers have permission to merge everything, however merge rights within the groups are based on "merge karma". If a change of a component merge also touches other areas, the component merger is required to ask for further reviews or tests from a framework merger.

    Merges are only allowed at any time if there are at least two other contributors positively tested/confirmed the change and reviewed the change. In addition, before a change happen, enough reasonable time Mergers are not allowed to vote on their own changes except for merging a patch.

    A change can only be merged if

    • Enough votes have been added (two +1s, one by another merger)
    • No -1/-2 vote from any other merger was given
    • A reasonable amount of time was given for peers to reviews (for any non-trivial change at least 24hs, for more significant changes 48hs)

    A change without code impact can directly be merged once tests have been run properly and have approved. 

    Features in stable branches

    New features must have proper documentation added with the initial merge. Features in Long-Term-Support branches are only allowed if the TYPO3 Project Leader has approved a specific change within the change.

    Backports

    When a change is marked for a backport, the merger is responsible for backporting and merging the backported change. When manual changes are necessary for a backport, the merger must ask for further reviews as it was a new change, otherwise a backport can be merged directly after all integration tests have approved the change.

    Backports to LTS branches in security-only branches must be approved by the TYPO3 Project Leader.

    Breaking changes

    Breaking changes include removing or renaming database fields / tables, removing / changing hooks and PHP code not marked as internal. Increasing the size of a database field is not considered a breaking change. Changing frontend output (Fluid Template files, TypoScript) is not allowed in LTS branches. All JavaScript files, labels or CSS/SCSS files are not considered part of the API, however removing files or JavaScript/TypeScript classes have to be handled with care in LTS branches.

    Breaking changes in stable branches are only allowed if the TYPO3 Project Leader has approved a specific change.

    Releases

    Releases (= tagging) are handled by the TYPO3 Project Leader or a person appointed by the TYPO3 Project Leader. This also applies to all subsystems or components.

    Dependencies

    Raising third-party dependencies from PHP can be done at any time, however the base system requirements of TYPO3 Core must be kept.

    Dependencies can only be added after approval of the TYPO3 Project Leader, and careful consideration of the license and stability of the dependency, regardless of it being PHP/JavaScript or SCSS/CSS code.

    These rules reflects the current state and may be further altered by the TYPO3 Project Leader with notification to all members of the affected groups.

    • Screenshot showing a user interface.

      PhpStorm—a Short Review

      Categories : Development , Community
      Created by Susanne Moog
      For some years JetBrains is offering free PhpStorm licenses for active TYPO3 Core developers. Its now time to give back and provide a short report about my experience with PhpStorm.
      Read more
    • Persistence Initiative: Meeting Report

      Categories : Development , TYPO3 CMS
      Created by Oliver Hader
      During a weekend in March 2019 Artus Kolanowski, Manuel Selbach, Benni Mack and Oliver Hader have been meeting at dkd Offices in Frankfurt/DE for a persistence initiative code and concept sprint.
      Read more
    • Introducing the TYPO3 Initiative Week (T3INIT19)

      Categories : Development , Community , TYPO3 CMS
      Created by Susanne Moog
      One week, 30 people - coming together to shape the future of TYPO3 - the TYPO3 Initiative Week
      Read more