Changeset 7632 for django/trunk/docs/contributing.txt
- Timestamp:
- 06/14/08 08:44:49 (2 months ago)
- Files:
-
- django/trunk/docs/contributing.txt (modified) (7 diffs)
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
django/trunk/docs/contributing.txt
r7294 r7632 149 149 unclaim it or don't claim it in the first place! 150 150 151 Core Django developers go through the list of claimed tickets from time to151 Ticket triagers go through the list of claimed tickets from time to 152 152 time, checking whether any progress has been made. If there's no sign of 153 progress on a particular claimed ticket for a week or two after it's been154 claimed, we will unclaim it for youso that it's no longer monopolized and153 progress on a particular claimed ticket for a week or two, a triager may ask 154 you to relinquish the ticket claim so that it's no longer monopolized and 155 155 somebody else can claim it. 156 156 157 157 If you've claimed a ticket and it's taking a long time (days or weeks) to code, 158 keep everybody updated by posting comments on the ticket. That way, we'll know 159 not to unclaim it. More communication is better than less communication! 158 keep everybody updated by posting comments on the ticket. If you don't provide 159 regular updates, and you don't respond to a request for a progress report, 160 your claim on the ticket may be revoked. As always, more communication is 161 better than less communication! 160 162 161 163 Which tickets should be claimed? … … 178 180 read patches when the only difference in code is that it's indented. 179 181 180 * When creating patches, always run ``svn diff`` from the top-level181 ``trunk`` directory -- i.e., the one that contains ``django``, ``docs``,182 ``tests``, ``AUTHORS``, etc. This makes it easy for other people to apply183 your patches.182 * When creating patches, always run ``svn diff`` from the top-level 183 ``trunk`` directory -- i.e., the one that contains ``django``, ``docs``, 184 ``tests``, ``AUTHORS``, etc. This makes it easy for other people to apply 185 your patches. 184 186 185 187 * Attach patches to a ticket in the `ticket tracker`_, using the "attach file" … … 235 237 :alt: Django's ticket workflow 236 238 237 We've got two roles here: 238 239 * Core developers: people with commit access who make the decisions and 240 write the bulk of the code. 241 242 * Ticket triagers: community members who keep track of tickets, making 243 sure the tickets are always categorized correctly. 244 239 We've got two official roles here: 240 241 * Core developers: people with commit access who make the big decisions 242 and write the bulk of the code. 243 244 * Ticket triagers: trusted community members with a proven history of 245 working with the Django community. As a result of this history, they 246 have been entrusted by the core developers to make some of the smaller 247 decisions about tickets. 248 245 249 Second, note the five triage stages: 246 250 247 1. A ticket starts as "Unreviewed", meaning that a triager has yet to248 examine the ticket and move it along.251 1. A ticket starts as "Unreviewed", meaning that nobody has examined 252 the ticket. 249 253 250 254 2. "Design decision needed" means "this concept requires a design 251 255 decision," which should be discussed either in the ticket comments or on 252 django-developers. 256 `django-developers`_. The "Design decision needed" step will generally 257 only be used for feature requests. It can also be used for issues 258 that *might* be bugs, depending on opinion or interpretation. Obvious 259 bugs (such as crashes, incorrect query results, or non-compliance with a 260 standard) skip this step and move straight to "Accepted". 253 261 254 262 3. Once a ticket is ruled to be approved for fixing, it's moved into the … … 270 278 "Has patch" 271 279 This means the ticket has an associated patch_. These will be 272 reviewed to see if the patch is "good".280 reviewed by the triage team to see if the patch is "good". 273 281 274 282 "Needs documentation" … … 293 301 294 302 "invalid" 295 Used if the ticket is found to be incorrect or a user error. 303 Used if the ticket is found to be incorrect. This means that the 304 issue in the ticket is actually the result of a user error, or 305 describes a problem with something other than Django, or isn't 306 a bug report or feature request at all (for example, some new users 307 submit support queries as tickets). 296 308 297 309 "wontfix" … … 306 318 307 319 "worksforme" 308 Used when the triage team is unable to replicate the original bug. 320 Used when the the ticket doesn't contain enough detail to replicate 321 the original bug. 309 322 310 323 If you believe that the ticket was closed in error -- because you're … … 316 329 .. _good patch: `Patch style`_ 317 330 .. _patch: `Submitting patches`_ 331 332 Triage by the general community 333 ------------------------------- 334 335 Although the Core Developers and Ticket Triagers make the big decisions in 336 the ticket triage process, there is also a lot that general community 337 members can do to help the triage process. In particular, you can help out by: 338 339 * Closing "Unreviewed" tickets as "invalid", "worksforme", or "duplicate". 340 341 * Promoting "Unreviewed" tickets to "Design Decision Required" if there 342 is a design decision that needs to be made, or "Accepted" if they are 343 an obvious bug. 344 345 * Correcting the "Needs Tests", "Needs documentation", or "Has Patch" flags 346 for tickets where they are incorrectly set. 347 348 * Checking that old tickets are still valid. If a ticket hasn't seen 349 any activity in a long time, it's possible that the problem has been 350 fixed, but the ticket hasn't been closed. 351 352 * Contact the owners of tickets that have been claimed, but have not seen 353 any recent activity. If the owner doesn't respond after a week or so, 354 remove the owner's claim on the ticket. 355 356 * Identifying trends and themes in the tickets. If there a lot of bug reports 357 about a particular part of Django, it possibly indicates that we need 358 to consider refactoring that part of the code. If a trend is emerging, 359 you should raise it for discussion (referencing the relevant tickets) 360 on `django-developers`_. 361 362 However, we do ask that as a general community member working in the 363 ticket database: 364 365 * Please **don't** close tickets as "wontfix". The core developers will 366 make the final determination of the fate of a ticket, usually after 367 consultation with the community. 368 369 * Please **don't** promote tickets to "Ready for checkin" unless they are 370 *trivial* changes - for example, spelling mistakes or 371 broken links in documentation. 372 373 * Please **don't** reverse a decision that has been made by a core 374 developer. If you disagree with a discussion that has been made, 375 please post a message to `django-developers`_. 376 377 * Please be conservative in your actions. If you're unsure if you should 378 be making a change, don't make the change - leave a comment with your 379 concerns on the ticket, or post a message to `django-developers`_. 318 380 319 381 Submitting and maintaining translations
