Changeset 4347
- Timestamp:
- 01/17/07 15:35:22 (2 years ago)
- Files:
-
- django/trunk/docs/contributing.txt (modified) (3 diffs)
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
django/trunk/docs/contributing.txt
r4346 r4347 153 153 154 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.155 users. A couple of dedicated volunteers work on this regularly, but more help 156 is always appreciated. 157 157 158 158 Most of the workflow is based around the concept of a ticket's "triage stage". … … 171 171 172 172 * Core developers: people with commit access who make the decisions and 173 write the bulk of the code 173 write the bulk of the code. 174 174 175 175 * Ticket triagers: community members who keep track of tickets, making 176 sure th at they're always categorized correctly.176 sure the tickets are always categorized correctly. 177 177 178 178 Second, note the four triage stages: 179 179 180 1. "Unreviewed", meaning that a triager has yet to examine the ticket and181 move it along.182 183 2. "Design decision needed" , meaning"this concept requires a design180 1. A ticket starts as "Unreviewed", meaning that a triager has yet to 181 examine the ticket and move it along. 182 183 2. "Design decision needed" means "this concept requires a design 184 184 decision," which should be discussed either in the ticket comments or on 185 185 django-developers. 186 186 187 3. Once a ticket is ruled to be approved for fixing, it's moved along into188 the"Accepted" stage. This stage is where all the real work gets done.187 3. Once a ticket is ruled to be approved for fixing, it's moved into the 188 "Accepted" stage. This stage is where all the real work gets done. 189 189 190 190 4. If a ticket has an associated patch (see below), a triager will review the 191 191 patch. If the patch is complete, it'll be marked as "ready for checkin" so 192 192 that a core developer knows to review and check in the patches. 193 193 194 194 The second part of this workflow involves a set of flags the describe what the 195 195 ticket has or needs in order to be "ready for checkin": 196 196 197 197 "Has patch" 198 The means th at the ticket has an associated patch_. These will be198 The means the ticket has an associated patch_. These will be 199 199 reviewed to see if the patch is "good". 200 200 201 201 "Needs documentation" 202 202 This flag is used for tickets with patches that need associated … … 205 205 206 206 "Needs tests" 207 This flags the patch as needing associated unit tests. Again,208 this isrequired part of a valid patch.209 207 This flags the patch as needing associated unit tests. Again, this is a 208 required part of a valid patch. 209 210 210 "Patch needs improvement" 211 211 This flag means that although the ticket *has* a patch, it's not quite
