diff -r 3fbdf7e40da5 docs/internals/contributing.txt
a
|
b
|
|
258 | 258 | have been entrusted by the core developers to make some of the smaller |
259 | 259 | decisions about tickets. |
260 | 260 | |
261 | | Second, note the five triage stages: |
| 261 | Second, note the six triage stages: |
262 | 262 | |
263 | 263 | 1. A ticket starts as "Unreviewed", meaning that nobody has examined |
264 | 264 | the ticket. |
… |
… |
|
284 | 284 | checkin" so that a core developer knows to review and check in the |
285 | 285 | patches. |
286 | 286 | |
| 287 | 6. Sometimes, the reporter of a ticket won't include all the information |
| 288 | needed to understand and/or reproduce the reported issue. In the |
| 289 | pathological cases the ticket will be closed off hand by a triager. |
| 290 | But if, after reviewing it, the triager thinks the ticket has merits to |
| 291 | not be closed at that point but more details need to be provided to |
| 292 | be able to decide the next triage stage then the "More information |
| 293 | needed" stage can be used. |
| 294 | |
287 | 295 | The second part of this workflow involves a set of flags the describe what the |
288 | 296 | ticket has or needs in order to be "ready for checkin": |
289 | 297 | |