---
title: "Review a patch"
manual: "TYPO3 Core Contribution Guide"
version: "main"
permalink: "https://docs.typo3.org/permalink/t3contribute:reviewpatch"
source: "HandlingAPatch/Review.rst"
rendered: "2026-10-05T15:34:44+00:00"
---

# Review a patch {#reviewpatch}

Reviewing a patch consists of two steps:

1.  [Code-review](https://docs.typo3.org/permalink/t3contribute:lifeofapatch-review)
1.  [Testing the change](https://docs.typo3.org/permalink/t3contribute:lifeofapatch-test)

You have the option to contribute to both stages or just a single stage in the review process.

Both steps are free for everyone in the OpenSource community, you are not required to be
a Core merger or Team member.

If you're able to improve the patch yourself, your contribution would be very much appreciated.
Visit [Upload a new Patch Set](https://docs.typo3.org/permalink/t3contribute:lifeofapatch-improve-patch) to find out more about how you can help improve patches.

> [!NOTE]
> **See also**
>
> -   [Find the patch](https://docs.typo3.org/permalink/t3contribute:find-a-review)
> -   [the introduction to Gerrit](https://docs.typo3.org/permalink/t3contribute:working-with-gerrit)

## Code Review {#gerrit-commenting-files}

A basic code review is possible by using the Gerrit web interface.

For some tips on what to review, check our [Common code review checks](https://docs.typo3.org/permalink/t3contribute:common-review-checks).

1.  Select the latest patchset

    This should already be selected by default, but if you changed the patchset, you should
    select **Go to the latest patch set** (above the list of changed files).
1.  To leave a comment, click on one of the files

    ![](../Images/External/Gerrit/HandlingAPatch/gerrit_review_click_on_file.png)
    Commenting in the files directly is optional, but strongly recommended. If you just want to leave a general
    comment which needs no context, you can skip to step 8 (**Reply**).
1.  Optionally change the view

    You will see a diff of this file against the current codebase.

    You can change the view in the top right (**Diff view**) e.g. **side-by-side** or
    **unified** (or change this in your settings).
1.  Leave one or more comments

    Click on the line number in the file and a comment box will open.

    ![](../Images/External/Gerrit/HandlingAPatch/gerrit_review_comment_click.png)
    ![](../Images/External/Gerrit/HandlingAPatch/gerrit_review_comment_file.png)
1.  Click **Save**.

    > [!IMPORTANT]
    > You comment(s) will not yet be visible for others until you go back and click **Reply**.
1.  Go back

    ![](../Images/External/Gerrit/HandlingAPatch/gerrit_review_go_back.png)
1.  (Optional) Add comments to more files.
1.  Now press **Reply**.

    Using the **Reply** button, you can post your comments
    (and optionally add an additional note).

    ![](../Images/External/Gerrit/CoreMergers/VoteUser.png)

    You should also [vote](https://docs.typo3.org/permalink/t3contribute:gerrit-voting) for the change
    (Be graceful with -1 votes though).

## Test a patch {#gerrit-testing-a-change}

For testing the patch you need to import the change into your local repository.

Look at [Cherry-pick a patch](https://docs.typo3.org/permalink/t3contribute:cherry-pick-a-patch) for information on how to do this.

Test the patch in your local TYPO3 installation and verify the reported bug
is fixed and no other bugs are introduced with the change.

Depending on the outcome of your tests, place your positive/negative vote
in Gerrit, using the **Reply button**.

If you want to help the author and provide an improved patch, continue with the section
[Upload a new Patch Set](https://docs.typo3.org/permalink/t3contribute:lifeofapatch-improve-patch).

Otherwise throw the changes away, to bring your repository back to a clean state:

```bash
git reset --hard origin/main
```

## Vote {#gerrit-voting}

In order to comment or vote on a change you can click on the **Reply**
and enter your comment. Here, you can also apply your votes.

Remember, everyone with just a TYPO3 user account is able to vote, you do not
need to be a team member or Core merger.

![](../Images/External/Gerrit/CoreMergers/VoteUser.png)

-   **+1** : you approve of the patch
-   **-1** : you do not approve, in this case give your reason as a comment

**Votes**

The **+2** and **-2** votes are only available for Core Mergers.
See the section [Review a patch as a Core Merger](https://docs.typo3.org/permalink/t3contribute:coremergers-review).
for more details.

Click on **Send** and your comments will be saved. At the same time
all other contributors who either watched this change
or have already voted on this change will get notified.

### Policy for votes {#gerrit-policy-for-votes}

**Code Review:** Needs **+1** of two reviewers, one of them being a Core Merger.

**Verified:** Needs **+1** of two reviewers, one of them being a Core Merger.

Votes from the CI GitLab Pipeline Server (user "Core CI") do not count. This means
that a patch which is fully reviewed usually has at least 3 **Verified** **+1**
votes, two from humans and one from "Core CI" ("Core CI is happy" for Verified+1, "Core CI is not happy"
for Verified-1). Each comment by Core CI is linked to the log of the performed job,
so that you can inspect the output.

**Authors should not vote for their own patches**, unless the patch has been changed
substantially by other developers.

As soon as the patch has reached the approved status by getting a **+2** on
**Code Review** and **Verified**, a Core Merger can decide to push the
**Submit** button, finally pushing it to the main repository.

### Hints on voting -1 {#hints-on-voting-1}

See also [Review a patch](https://docs.typo3.org/permalink/t3contribute:reviewpatch) about the policies on voting and how to vote.

In general, **-1** on reading and/or testing of a patch is a mechanism used to
improve a patch. Still, -1 still takes a risk to kill someone elses patch
and it usually actively prevents a merge. There are ways to override a -1, but
those are not pushed through in real live Gerrit habits. In general, if voting
-1, you take some responsibility for this patch by saying "This one shouldn't
be solved until this or that is fixed". Some hints on using -1 in reviews:

-   Think about your vote and always give a logical explanation. "-1 looks ugly" is
    not enough.
-   If a patch is broken, does not fix the issue, is bogus, architecturally wrong
    or collides with other goals, a -1 is clearly ok.
-   -1 can also be used if you are actively working on a patch and want to prevent
    a quick merge: "-1, working on it now, will push soonish".
-   -1 may be ok if you have general doubts but you can not pinpoint it and need
    a second opinion: "Hey, this solution looks somehow weird and I doubt this is
    what we should do here. I think we should ask person x or person y, who has
    a deeper knowledge of this subsystem, to take a look at it. I do not want
    this patch to be merged until this is sorted out and will vote -1 for now
    for this reason."
-   If you are on the "receiving end" of a "-1" or even a "-2" vote, please do not
    be afraid or feel bad. This is done as part of the process to make TYPO3
    evolve as best as it can. Try to work out problems or negative feedback,
    be kind to each other and remember you are contributing to OpenSource because
    the experience of improving things together, and learning from each other
    is what drives us.

### Vote resets ("Revote") {#vote-resets-revote}

Whenever a new patch is submitted, all votes are reset. So if previously
a patch was voted to be merged, but then a last-minute issue is getting
addressed, after the commit every vote will be back to zero.

Contributors to a patch review will receive notifications about this and
are encouraged to review the patch and re-apply their vote if they
still feel confident.

It is ok if the patch owner pings previous votes to please consider
adding a revote, so that a patch can be pushed forwards.

## How to handle \[WIP\] patches {#how-to-handle-wip-patches}

It is possible to push patches as "WIP" ([work in progress](https://docs.typo3.org/permalink/t3contribute:git-work-in-progress))
patches. This is a
way to show people a quick-shot version of something that is not finished yet,
but goes into the right direction. Usually, WIP patches are not actively
reviewed by others and the original author should take responsibility to finish
this patch later.

As a contributor, you usually can not expect someone else to pick up your WIP
patch and finish it, except you stated that goal clearly: "Hey, I've done a
quick shot with this patch to show a possible solution for this issue, but the patch
is not finished yet. Foo and bar is missing and we still need a concept for foobar.
I'll probably not work actively work on it anytime soon, but maybe the current
state is helpful already".

Better: "Hey, I worked in this area and came up with this WIP patch for now. I
wanted to show into which direction this patch is leading, but we currently have
some open questions. However, it would be great if you can give me feedback to
the general approach at this early state already to decide if it is worth
following this solution to its end."

Having too many WIP patches in the review queue is not really helpful. Consider
to fork the project in GitHub or somewhere else and push to gerrit again if
your patches evolved.

## Stale reviews / Cleaning up {#stale-reviews-cleaning-up}

Since TYPO3 iterates on many, many patches and issues each day, the list
of Gerrit reviews (as well as Forge issues) may feel intimidating.

Due to this it is vital to "clean up" patches from time to time:

-   If you are no longer planning to work on a patch, maybe better abandon
    it, or ask other involved people to carry on.
-   If your patch is not getting feedback for a long time, ask in the
    #typo3-cms-coredev channel of the [TYPO3 slack workspace](https://typo3.slack.com)
    if people may want to review or give feedback on. Or try to find people
    working in a similar area of your patch and see if you can join forces.
-   From time to time, check on patches you have voted on, to see if you can
    push things forward to either get merged or abandoned.
-   Sometimes check all your own open patches and see if you might catch
    interest in picking it up again.
-   Please either update older patches in "Merge conflict" mode or state your
    intent to abandon the patch.