| 154 | | One way to help out is to *triage* bugs that have been reported by other users. |
|---|
| 155 | | Pick an open ticket that is missing some details, and try to replicate the |
|---|
| 156 | | problem. Fill in the missing pieces of the report. If the ticket doesn't have |
|---|
| 157 | | a patch, create one. |
|---|
| 158 | | |
|---|
| 159 | | Once you've completed all the missing details on the ticket and you have a |
|---|
| 160 | | patch with all the required features, e-mail `django-developers`_. Indicate |
|---|
| 161 | | that you have triaged a ticket, and recommend a course of action for dealing |
|---|
| 162 | | with that ticket. |
|---|
| 163 | | |
|---|
| 164 | | At first, this may require you to be persistent. If you find that your triaged |
|---|
| 165 | | ticket still isn't getting attention, occasional polite requests for eyeballs |
|---|
| 166 | | to look at your ticket may be necessary. However, as you earn a reputation for |
|---|
| 167 | | quality triage work, you should find that it is easier to get the developers' |
|---|
| 168 | | attention. |
|---|
| | 154 | One way to help out is to *triage* bugs that have been reported by other |
|---|
| | 155 | users. We have a couple of dedicated volunteers who work on this regularly, |
|---|
| | 156 | but more help is always appriciated. |
|---|
| | 157 | |
|---|
| | 158 | Most of the workflow is based around the concept of a ticket's "triage stage". |
|---|
| | 159 | This stage describes where in its lifetime a given ticket is at any time. |
|---|
| | 160 | Along with a handful of flags, this field easily tells us what and who each |
|---|
| | 161 | ticket is waiting on. |
|---|
| | 162 | |
|---|
| | 163 | Since a picture is worth a thousand words, let's start there: |
|---|
| | 164 | |
|---|
| | 165 | .. image:: http://media.djangoproject.com/img/doc/djangotickets.png |
|---|
| | 166 | :height: 451 |
|---|
| | 167 | :width: 590 |
|---|
| | 168 | :alt: Django's ticket workflow |
|---|
| | 169 | |
|---|
| | 170 | We've got two roles here: |
|---|
| | 171 | |
|---|
| | 172 | * Core developers: people with commit access who make the decisions and |
|---|
| | 173 | write the bulk of the code |
|---|
| | 174 | |
|---|
| | 175 | * Ticket triagers: community members who keep track of tickets, making |
|---|
| | 176 | sure that they're always categorized correctly. |
|---|
| | 177 | |
|---|
| | 178 | Second, note the four triage stages: |
|---|
| | 179 | |
|---|
| | 180 | 1. "Unreviewed", meaning that a triager has yet to examine the ticket and |
|---|
| | 181 | move it along. |
|---|
| | 182 | |
|---|
| | 183 | 2. "Design decision needed", meaning "this concept requires a design |
|---|
| | 184 | decision," which should be discussed either in the ticket comments or on |
|---|
| | 185 | django-developers. |
|---|
| | 186 | |
|---|
| | 187 | 3. Once a ticket is ruled to be approved for fixing, it's moved along into |
|---|
| | 188 | the "Accepted" stage. This stage is where all the real work gets done. |
|---|
| | 189 | |
|---|
| | 190 | 4. If a ticket has an associated patch (see below), a triager will review the |
|---|
| | 191 | patch. If the patch is complete, it'll be marked as "ready for checkin" so |
|---|
| | 192 | that a core developer knows to review and check in the patches. |
|---|
| | 193 | |
|---|
| | 194 | The second part of this workflow involves a set of flags the describe what the |
|---|
| | 195 | ticket has or needs in order to be "ready for checkin": |
|---|
| | 196 | |
|---|
| | 197 | "Has patch" |
|---|
| | 198 | The means that the ticket has an associated patch_. These will be |
|---|
| | 199 | reviewed to see if the patch is "good". |
|---|
| | 200 | |
|---|
| | 201 | "Needs documentation" |
|---|
| | 202 | This flag is used for tickets with patches that need associated |
|---|
| | 203 | documentation. Complete documentation of features is a prerequisite |
|---|
| | 204 | before we can check a fix into the codebase. |
|---|
| | 205 | |
|---|
| | 206 | "Needs tests" |
|---|
| | 207 | This flags the patch as needing associated unit tests. Again, |
|---|
| | 208 | this is required part of a valid patch. |
|---|
| | 209 | |
|---|
| | 210 | "Patch needs improvement" |
|---|
| | 211 | This flag means that although the ticket *has* a patch, it's not quite |
|---|
| | 212 | ready for checkin. This could mean the patch no longer applies |
|---|
| | 213 | cleanly, or that the code doesn't live up to our standards. |
|---|
