TYPO3 Contribution Explained

Ok, so you want an overview first, that's fine. Actually, it's a brilliant idea to understand the concept first to help you understand why we do things the way we do them. So let us walk you through that.

Common Workflow

So this it what your usual coding workflow may look like.

  1. You clone or pull from a central Git repository and change some lines of code
  2. You push right back to that central repository

This workflow has some drawbacks though, because there is only a very low level of peer control over the code you are pushing. Chances are relatively high that your change might break something elsewhere, does not comply to TYPO3s coding guidelines, doesn't work on the respective PHP versions for the TYPO3 version you are working on.... in short: it's dangerous.

TYPO3 Contribution Workflow

As you can see, our workflow is a bit different, simply because we do not allow to push right back to our Git repository. We use a 6-eye principle to ensure proper quality assurance and Gerrit helps us here - but let's go over the workflow step by step.

  1. You clone or pull as usual and do changes to the codebase.
  2. When trying to push back to the Git repository, you will not be allowed to do so. In fact, the only entity that may push back to our Git repository is Gerrit itself, so the same rules apply for everybody.
  3. Instead, you push your changes to Gerrit and they will show up as a pending code review.
  4. From here, any contributor can review the change.
  5. Reviewing consists of two parts, the Code Review where a contributor checks if the code style is according to our coding guidelines or in general makes sense by reading and the Verification which means if the code does what it is supposed to do (like fixing an issue) and checks whether the unit, functional and acceptance tests run through.
  6. If a review has enough positive votes (at least two people voting verified+reviewed), an active contributor (aka member of the Core team, called "Merger") is able to merge that review into the existing codebase. The reason we need a member of the Core team to finally merge the change is that we run a "You break it, you fix it" policy. So, the Core team member that merged a change immediately becomes responsible for that change in case the original author decides to no longer work on it. And he / she will be responsible for backporting it to selected older TYPO3 versions.