Code

Changes between Version 16 and Version 17 of ContributingHowTo


Ignore:
Timestamp:
02/02/11 19:23:53 (3 years ago)
Author:
julien
Comment:

Status != Triage Stage in Trac ;)

Legend:

Unmodified
Added
Removed
Modified
  • ContributingHowTo

    v16 v17  
    1717=== Understanding Trac === 
    1818 
    19 ''What the various statuses "really" mean...'' 
    20  
    2119Django uses Trac as its sole official issue tracker. All known bugs, desired features, and ideas for changes are logged there. 
    2220 
    23 However, Trac can be quite confusing even to veteran contributors. Having to look at both flags and statuses isn't immediately obvious, and the statuses themselves have names that can be misinterpreted. 
     21However, Trac can be quite confusing even to veteran contributors. Having to look at both flags and triage stages isn't immediately obvious, and the stages themselves have names that can be misinterpreted. 
    2422 
    25 What Django's statuses "really mean": 
     23What Django's triage stages "really mean": 
    2624 
    2725 * '''Unreviewed''': The ticket has not been reviewed by anyone who felt qualified to make a judgment about whether the ticket contained a valid issue, a viable feature, or ought to be closed for any of the various reasons. 
    2826 
    2927 * '''Accepted''': The big grey area! The absolute meaning of "accepted" is that the issue described in the ticket is valid and is in some stage of being worked on. Beyond that there are several considerations: 
    30    * '''Accepted + No Flags''': The ticket is valid, but no one has submitted a patch for yet. Often this means you could safely start writing a patch for it. 
     28   * '''Accepted + No Flags''': The ticket is valid, but no one has submitted a patch for it yet. Often this means you could safely start writing a patch for it. 
    3129   * '''Accepted + Has Patch''': The ticket is waiting for people to review the supplied patch. This means downloading the patch and trying it out, verifying that it contains tests and docs, running the test suite with the included patch, and leaving feedback on the ticket. 
    3230   * '''Accepted + Has Patch + (any other flag)''': This means the ticket has been reviewed, and has been found to need further work. "Needs tests" and "Needs documentation" are self-explanatory. "Patch needs improvement" will generally be accompanied by a comment on the ticket explaining what is needed to improve the code. 
    3331 
    34  * '''Design Decision Needed''': This status is for issues which may be contentious, may be backwards incompatible, or otherwise involve high-level design decisions. These decisions are generally made by the core committers, however that is not a requirement. See the FAQ below for "My ticket has been in DDN forever! What should I do?" 
     32 * '''Design Decision Needed''': This stage is for issues which may be contentious, may be backwards incompatible, or otherwise involve high-level design decisions. These decisions are generally made by the core committers, however that is not a requirement. See the FAQ below for "My ticket has been in DDN forever! What should I do?" 
    3533 
    3634 * '''Ready For Checkin''': The ticket was reviewed by any member of the community other than the person who supplied the patch and found to meet all the requirements for a commit-ready patch. A core committer now needs to give the patch a final review prior to being committed. See the FAQ below for "My ticket has been in RFC forever! What should I do?" 
     
    5654 * Pick a subject area that you care about, that you are familiar with, or that you want to learn about. You don't already have to be an expert on the area you want to work on; you become an expert through your ongoing contributions to the code. 
    5755 
    58  * Triage Tickets. If a ticket is unreviewed and reports a bug, try and duplicate it. If you can duplicate it and it seems valid, make a note that you confirmed the bug and accept the ticket. Make sure the ticket is filed under the correct component area. Consider writing a patch that adds a test for the bug's behavior, even if you don't fix the bug itself. 
     56 * Triage tickets. If a ticket is unreviewed and reports a bug, try and duplicate it. If you can duplicate it and it seems valid, make a note that you confirmed the bug and accept the ticket. Make sure the ticket is filed under the correct component area. Consider writing a patch that adds a test for the bug's behavior, even if you don't fix the bug itself. 
    5957 
    6058 * Look for tickets that are accepted and review patches to build familiarity with the codebase and the process. Mark the appropriate flags if a patch needs docs or tests. Look through the changes a patch makes, and keep an eye out for syntax that is incompatible with older but still supported versions of Python. Run the tests and make sure they pass on your system. Where possible and relevant, try them out on a database other than SQLite. Leave comments and feedback!