@@ -5,7 +5,7 @@ Symfony is an open-source project driven by a large community. If you don't feel
5
5
ready to contribute code or patches, reviewing issues and pull requests (PRs)
6
6
can be a great start to get involved and give back.
7
7
8
- Why Reviewing is Important
8
+ Why Reviewing Is Important
9
9
--------------------------
10
10
11
11
Community reviews are essential for the development of the Symfony framework,
@@ -16,7 +16,7 @@ On the `Symfony issue tracker`_, you can find many items in a "Needs Review"
16
16
status:
17
17
18
18
* **Bug Reports **: Bug reports primarily need to be checked for completeness.
19
- Is any important information missing? Can the bug easily be reproduced?
19
+ Is any important information missing? Can the bug be easily reproduced?
20
20
21
21
* **Pull Requests **: Pull requests contain code that fixes a bug or implements
22
22
new functionality. Reviews of pull requests ensure that they are implemented
@@ -30,9 +30,9 @@ Be Constructive
30
30
---------------
31
31
32
32
Before you begin, remember that you are looking at the result of someone else's
33
- hard work. A good review post thanks the contributor for their work, identifies
34
- what was done well, identifies what should be improved, and suggests a next
35
- step.
33
+ hard work. A good review comment thanks the contributor for their work,
34
+ identifies what was done well, identifies what should be improved and suggests a
35
+ next step.
36
36
37
37
Create a GitHub Account
38
38
-----------------------
@@ -48,25 +48,27 @@ A good way to get started with reviewing is to pick a bug report from the
48
48
49
49
The steps for the review are:
50
50
51
- 1 . **Is the Report Complete? **
51
+ # . **Is the Report Complete? **
52
52
53
53
Good bug reports contain a link to a fork of the `Symfony Standard Edition `_
54
54
(the "reproduction project") that reproduces the bug. If it doesn't, the
55
55
report should at least contain enough information and code samples to
56
56
reproduce the bug.
57
57
58
- 2 . **Reproduce the Bug **
58
+ # . **Reproduce the Bug **
59
59
60
60
Download the reproduction project and test whether the bug can be reproduced
61
61
on your system. If the reporter did not provide a reproduction project,
62
62
create one by forking _ the `Symfony Standard Edition `_. Reproduce the bug
63
63
with the instructions given by the reporter.
64
64
65
- 3 . **Update the Issue Status **
65
+ # . **Update the Issue Status **
66
66
67
- At last, add a comment and update the status of the bug report. **Thank the
68
- reporter for reporting the bug **. Include the line ``Status: <status> `` in
69
- your comment to update the status to one of the following:
67
+ At last, add a comment to the bug report. **Thank the reporter for reporting
68
+ the bug **. Include the line ``Status: <status> `` in your comment to update
69
+ the status of the ticket. This line will trigger our `Carson Bot `_ which
70
+ updates the labels of the issue accordingly. You can set the status to one of
71
+ the following:
70
72
71
73
**Needs Work ** If the bug does not contain enough information to be
72
74
reproduced, explain what information is missing and move the report to this
@@ -100,36 +102,36 @@ bug report. Reviews of pull requests usually take a little longer since you need
100
102
to understand the functionality that has been fixed or implemented and then find
101
103
out whether the implementation is complete.
102
104
103
- It is okay to do partial reviews. If you do a partial review, post how far you
104
- got and leave the PR in "Needs Review" state.
105
+ It is okay to do partial reviews. If you do a partial review, comment how far
106
+ you got and leave the PR in "Needs Review" state.
105
107
106
108
Pick a pull request from the `PRs in need of review `_ and follow these steps:
107
109
108
- 1 . **Is the PR Complete **?
110
+ # . **Is the PR Complete **?
109
111
110
112
Every pull request must contain a header that gives some basic information
111
113
about the PR. You can find the template for that header in the
112
- `Contribution Guidelines `_ .
114
+ :ref: `Contribution Guidelines < contributing-code-pull-request >` .
113
115
114
- 2 . **Is the Base Branch Correct? **
116
+ # . **Is the Base Branch Correct? **
115
117
116
118
GitHub displays the branch that a PR is based on below the title of the
117
119
pull request. Is that branch correct?
118
120
119
121
* Bugs should be fixed in the oldest, maintained version that contains the
120
- bug. Check `Symfony's Release Schedule `_ to find the oldest currently
121
- supported version.
122
+ bug. Check :doc: `Symfony's Release Schedule < releases >` to find the oldest
123
+ currently supported version.
122
124
123
125
* New features should always be added to the current development version.
124
126
Check the `Symfony Roadmap `_ to find the current development version.
125
127
126
- 3 . **Reproduce the Problem **
128
+ # . **Reproduce the Problem **
127
129
128
130
Read the issue that the pull request is supposed to fix. Reproduce the
129
131
problem on a clean `Symfony Standard Edition `_ project and try to understand
130
132
why it exists.
131
133
132
- 4 . **Review the Code **
134
+ # . **Review the Code **
133
135
134
136
Read the code of the pull request and check it against some common criteria:
135
137
@@ -145,19 +147,23 @@ Pick a pull request from the `PRs in need of review`_ and follow these steps:
145
147
features?
146
148
* Are all deprecations and backwards compatibility breaks documented in the
147
149
latest UPGRADE-X.X.md file? Do those explanations contain "Before"/"After"
148
- with a clear upgrade path ?
150
+ examples with clear upgrade instructions ?
149
151
150
- 5. ** Test the Code **
152
+ Eventually, some of these aspects will be checked automatically.
151
153
152
- Take your project from step 2 and test whether the PR works properly.
154
+ #. **Test the Code **
155
+
156
+ Take your project from step 3 and test whether the PR works properly.
153
157
154
158
TODO: precise steps
155
159
156
- 6 . **Update the PR Status **
160
+ # . **Update the PR Status **
157
161
158
- At last, add a comment and update the status of the PR. **Thank the
159
- contributor for working on the PR **. Include the line ``Status: <status> `` in
160
- your comment to update the status to one of the following:
162
+ At last, add a comment to the PR. **Thank the contributor for working on the
163
+ PR **. Include the line ``Status: <status> `` in your comment to update the
164
+ status of the ticket. This line will trigger our `Carson Bot `_ which updates
165
+ the labels of the issue accordingly. You can set the status to one of the
166
+ following:
161
167
162
168
**Needs Work ** If the PR is not yet ready to be merged, explain the issues
163
169
that you found and move it to this status.
@@ -174,7 +180,7 @@ Pick a pull request from the `PRs in need of review`_ and follow these steps:
174
180
175
181
Thank you @weaverryan for working on this! It seems that your test
176
182
cases don't cover the cases when the counter is zero or smaller.
177
- Could you add some tests for that?
183
+ Could you please add some tests for that?
178
184
179
185
Status: Needs Work
180
186
@@ -188,3 +194,4 @@ Pick a pull request from the `PRs in need of review`_ and follow these steps:
188
194
.. _Contribution Guidelines : https://github.com/symfony/symfony/blob/master/CONTRIBUTING.md
189
195
.. _Symfony's Release Schedule : http://symfony.com/doc/current/contributing/community/releases.html#schedule
190
196
.. _Symfony Roadmap : https://symfony.com/roadmap
197
+ .. _Carson Bot : https://github.com/carsonbot/carsonbot
0 commit comments