Pull request workflow
The so-called "PR workflow" used by Godot is common to many projects using Git, and should be familiar to veteran free software contributors. The idea is that only a small number (if any) commit directly to the master branch. Instead, contributors fork the project (i.e. create a copy of it, which they can modify as they wish), and then use the GitHub interface to request a pull from one of their fork's branches to one branch of the original (often named upstream) repository.
The resulting pull request (PR) can then be reviewed by other contributors, who might approve it, reject it, or most often request that modifications be done. Once approved, the PR can then be merged by one of the core developers, and its commit(s) will become part of the target branch (usually the master branch).
From a high level, the ideal life cycle of a change to Godot looks like the following:
A contributor opens a pull request that addresses the issue or implements the idea.
The ◆ Bugsquad and triage team categorize the pull request, adding appropriate tags and requesting reviews from area maintainers.
Contributors discuss whether the approach of the PR is appropriate to fix the problem at hand, and leave feedback.
Contributors review the code, and iterate improvements with the pull request author. When they are satisfied, they will approve the pull request.
A release manager merges the pull request when there are sufficient approvals. A pull request always needs approvals from the respective area maintainers, but reviews from other contributors help.
Note
In practice, the above steps may often blend together.
Even if you are not a maintainer, you can still help by reviewing, providing feedback, 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.
When will a pull request get reviewed?
When you open a new pull request, area maintainers are notified immediately.
However, a lot of pull requests are opened every day, so reviews can take a while to come in. Going by historical data, you can expect the following review timelines:
80% of regression fixes are merged (or rejected) within a week.
80% of bug fixes are merged (or rejected) within two weeks.
80% of enhancements are merged (or rejected) within two months.
As you can imagine, simple and relevant pull requests will usually be reviewed more quickly than large and complicated pull requests.
How quickly a PR gets reviewed or merged also depends on where in the release cycle we are currently in:
During the development (dev) phase, both bug fixes and new features or enhancements are merged.
During the beta phase we enter "feature freeze", stop merging (most) new features, and focus on bug fixes only.
And during the release candidate (RC) phase we only consider critical fixes.
What kind of changes (new features and bug fixes) are accepted also depends on when in each phase we are in. Some big or risky features will only be merged during the early part of the dev phase, to give us as much time as possible to find potential regressions or issues before release.
If you think your pull request has been overlooked, or you have any questions about the review process, feel free to ask about it in the Contributors' chat. You can ask in #new-contributors, #devel, or the channel of the area you're expecting reviews from.