godotengine/godot-contributing-docs
1
0
Fork 0
mirror of https://github.com/godotengine/godot-contributing-docs.git synced 2025-12-31 05:48:13 +03:00
Code Issues Packages Projects Releases Wiki Activity

Update the review and merge process.

Browse Source
This commit is contained in:
Lukas Tenbrink
2025-11-07 12:16:55 +01:00
parent 8ea278a507
commit a8d2934f21
1 changed files with 17 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
organization/pull_requests/review_process.rst
View File

@@ -1,57 +1,33 @@
Review and merge process
========================
.. note::
This page is intended to provide insight into the pull request (PR) review
process that we aspire to. As such, it is primarily targeted at engine
maintainers who are responsible for reviewing and approving pull requests.
That being said, much of the content is useful for prospective contributors
wanting to know how to ensure that their PR is merged.
From a high level, the ideal life cycle of a pull request looks like the
following:
1. A contributor opens a PR that fixes a specific problem (optimally closing
a GitHub `issue <https://github.com/godotengine/godot>`_ or implementing
a `proposal <https://github.com/godotengine/godot-proposals>`_).
1. A contributor :ref:`opens a pull request <doc_pr_workflow>` that fixes a
specific problem (ideally closing a GitHub `issue <https://github.com/godotengine/godot>`_
or implementing a `proposal <https://github.com/godotengine/godot-proposals>`_).
2. Other contributors provide feedback on the PR (including reviewing and/or
approving the PR, as appropriate).
2. The :ref:`bugsquad and triage team <doc_areas>` **categorize** the pull request,
adding appropriate tags and requesting reviews from :ref:`area maintainers <doc_areas>`.
3. An engine maintainer reviews the code and provides feedback, requests
changes, or approves the pull request, as appropriate.
3. Contributors discuss **whether the approach of the PR is appropriate** to fix the problem
at hand, and leave feedback.
4. Another maintainer reviews the code with a focus on code style/clarity and
approves it once satisfied.
4. Contributors **review the code**, and iterate improvements with the pull request author.
When they are satisfied, they will approve the pull request.
5. A team leader or a member of the `production team
<https://godotengine.org/teams#production>`_ merges the pull request if
satisfied that it has been sufficiently reviewed.
This document will explain steps 2, 3, 4, and 5 in more detail. For a more
detailed explanation of the pull request workflow please see the :ref:`pull
request workflow document <doc_pr_workflow>`.
5. A release manager merges the pull request when there are sufficient approvals. A pull request
always needs approvals from the respective :ref:`area maintainers <doc_areas>`, but reviews
from other contributors help.
.. note::
In practice these steps may blend together. Oftentimes maintainers will
provide comments on code style and code quality at the same time and will
approve a pull request for both.
In practice, the above steps may often blend together.
Typically the first interaction on a pull request will be an engine maintainer
assigning tags to the pull request and flagging it for review by someone
familiar with that area of code.
Engine maintainers are folks who are "members" of the Godot project repository
on GitHub and/or are listed on the `Teams page <https://godotengine.org/teams>`_
on the Godot website. Maintainers are responsible for a given area of the
engine. Typically this means they are the people who are given more trust to
approve and recommend pull requests for merging.
Even if you are not a maintainer, you can still help by reviewing code,
providing feedback on PRs and testing PRs locally on your machine to confirm
that they work as intended. Many of the currently active maintainers started out
doing this before they became maintainers.
Even if you are not a maintainer, you can still help by :ref:`reviewing <doc_pr_review_guidelines>`,
providing feedback, and :ref:`testing PRs <doc_testing_pull_requests>` locally on your machine
to confirm that they work as intended. Many of the currently active maintainers started out doing
this before they became maintainers.
When will a pull request get reviewed?
--------------------------------------