Reviewing Issues and Pull Requests (Symfony Docs)

Symfony is an open source project driven by a large community. If you don't feel ready to contribute code or documentation yet, reviewing issues and pull requests is a great way to get involved. It works the same whether the change touches code or documentation, and anyone with some basic familiarity with Symfony can do it; you don't need to be an expert. People who "triage" issues are the backbone of Symfony's success!
Pick an item labeled Needs Review, check that it's complete, reproduce it (or read the change), then leave a friendly comment with a Status: <status> line to update its label. Always keep your comments respectful (see Writing Respectful Comments below).
Community reviews are essential for the development of Symfony: there are many more pull requests and bug reports than there are core team members to review, fix and merge them. On the Symfony issue tracker you can find many items in a Needs Review status:
Symfony uses GitHub to manage issues and pull requests, so you need to create a GitHub account and log in.
Remember that you are looking at the result of someone else's hard work. A good review thanks the contributor, points out what was done well, explains what should be improved and suggests a next step. Before commenting, read the Writing Respectful Comments guidelines below.
A good way to get started is to pick a bug report from the bug reports in need of review and follow these steps:
Is the report complete?
Good bug reports link to a "reproduction project" (created with the Symfony skeleton) that reproduces the bug. If there's none, the report should at least contain enough information and code samples to reproduce it.
Download the reproduction project and test whether the bug happens on your system. If the reporter didn't provide one, try to create it yourself.
Update the issue status
Add a comment to the report. Thank the reporter, and include a Status: <status> line to trigger the Carson Bot, which updates the issue label. Possible statuses:
Needs Work if the report lacks enough information to reproduce the bug (explain what's missing);
Works for me if it has enough information but works on your system, or if it's a feature request and not a bug (give a short explanation);
Reviewed if you can reproduce the bug (include the link to your reproduction project, if you created one).
A sample comment for a bug report that could be reproduced:
The process is similar to reviewing a bug report, but usually takes a little longer since you need to understand the change. It's okay to do partial reviews! If you do, comment on how far you got and leave the PR in the "Needs Review" state.
Pick a pull request from the PRs in need of review and follow these steps:
Every pull request must contain a header with basic information about the change. You can find the template in the Contribution Guidelines.
Is the base branch correct?
GitHub displays the branch a PR is based on, below its title:
For a documentation pull request, check that the prose follows the documentation standards, that code examples are correct, and build the docs locally to catch syntax errors.
For a code pull request, read the code and check it against these criteria:
Eventually, some of these aspects will be checked automatically.
Test the change (code PRs)
Reproduce the original problem on a project created with the Symfony skeleton, then check whether the PR fixes it. Check out the PR in a local clone of Symfony (the quickest way is the GitHub CLI; replace <ID> with the PR number) and run the link script to make your project use that code instead of the one in its vendor/ directory (see testing your changes in a real project):
Now run your reproduction project again to verify that the problem is fixed.
Update the PR status
Add a comment to the PR. Thank the contributor, and include a Status: <status> line to trigger the Carson Bot:
Needs Work if the PR is not ready to be merged (explain the issues you found);
Reviewed if the PR satisfies all the checks above. A core team member will then decide whether it can be merged or needs further work.
A sample comment for a PR that is not yet ready for merge:
Before you leave a comment, take a step back and think: is what you are about to actually say what you intend? Communicating over the Internet with nothing but text is hard, especially in a world-wide community of people with different ideas, opinions and backgrounds. Not everyone speaks English natively, and some may have had a bad experience contributing to other projects.
This guide is not about asking you to "conform" or give up your ideas and opinions; it's about communicating better and keeping the Symfony community a welcoming place. You are free to disagree with someone's opinions, but don't be disrespectful.
Many programming decisions are opinions. Discuss trade-offs, say which you prefer, and reach a resolution quickly. It's not about being right or wrong, but about using what works.
We don't expect you to be formal or to write error-free English. Don't swear and be respectful to others. Don't reply in anger or with an aggressive tone: take a deep breath, count to 10, and try to clearly explain the problem you found.
To be inclusive to a wide group of people, use pronouns that don't suggest a particular gender: unless someone has stated their pronouns, use "they"/"them" instead of "he"/"she", etc. Avoid wording that may be excluding, needlessly gendered, racially motivated or that singles out a group. For example, prefer "folks", "team" or "everyone" over "guys", "ladies", etc.
While reviewing you may run into suggestions that don't reflect your ideas, or that are simply wrong. Before you comment, consider the time the author spent and how your response would make them feel. Did you correctly understand their intention, or are you making assumptions? Be explicit, and avoid terms that refer to personal traits ("dumb", "stupid"). Assume everyone is intelligent and well-meaning.
Good questions avoid judgme