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 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, some exceptions happen during code sprints or coding nights of the TYPO3 Developer Days)
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.
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 in stable branches are only allowed if the TYPO3 Project Leader has approved a specific change.
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.
Raising third-party dependencies from PHP can be done at any time, however the base system requirements of TYPO3 Core must be kept.
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.