---
title: "TYPO3 Contribution Explained"
manual: "TYPO3 Core Contribution Guide"
version: "main"
permalink: "https://docs.typo3.org/permalink/t3contribute:workflow-explained"
source: "WorkflowExplained/Index.rst"
rendered: "2026-10-09T09:48:53+00:00"
---

# TYPO3 Contribution Explained {#workflow-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 {#common-workflow}

![](../Images/Graphics/Regular-Workflow.png)

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
1.  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 {#typo3-contribution-workflow}

![](../Images/Graphics/Contribution-Workflow.png)

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](https://review.typo3.org) 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.
1.  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](https://review.typo3.org) itself, so the same rules apply for everybody.
1.  Instead, you push your changes to [Gerrit](https://review.typo3.org) and they will show up as a pending code review.
1.  From here, any contributor can review the change.
1.  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 end-to-end tests run through.
1.  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.