Changes between Version 9 and Version 10 of TicketLifeCycle


Ignore:
Timestamp:
03/17/11 14:20:17 (3 years ago)
Author:
Anna
Comment:

Text enhancement and proof-reading

Legend:

Unmodified
Added
Removed
Modified
  • TicketLifeCycle

    v9 v10  
    33= Ticket Life Cycle = 
    44 
    5 Every line of code introduced in the CKEditor/trunk tree must pass through a strict review process. This guarantees the overall quality of the code base. 
     5Every line of code introduced in the {{{CKEditor/trunk}}} repository tree must pass through a strict review process. This guarantees the overall quality of the code base. 
    66 
    77This document describes the life cycle of a ticket in the CKEditor project. 
     
    99== Ticket Creation == 
    1010 
    11 Anyone is allowed (and invited) to open tickets for every single issue faced in CKEditor. The [wiki:Bugs Bug Reporting Instructions] and [wiki:Features Feature Request Instructions] pages have more information on how to properly fill new tickets. Created ticket has status '''[query:status=new&desc=1&order=id new]''' 
     11Anyone is allowed (and invited) to open tickets for every single issue encountered in CKEditor. The [wiki:Bugs Bug Reporting Instructions] and [wiki:Features Feature Request Instructions] pages contain more information on how to file new tickets and fill their contents. After it is created each ticket has the '''[query:status=new&desc=1&order=id new]''' status. 
    1212 
    1313== Clean up == 
    1414 
    15 The ticket title, its description or its fields could be cleaned up to confirm to our internal requirements and recommendations. 
     15The ticket title, its description, or its fields may possibly be cleaned up to conform to our internal requirements and recommendations. 
    1616 
    1717== Confirming Bugs == 
     
    1919Someone from the core development team should then check the ticket information and decide whether it has enough useful information to move forward. 
    2020 
    21 The following actions could be taken when confirming new ticket: 
    22  * Resolve the ticket as '''{{{duplicate}}}''' if the ticket is determined to have the same cause as a ticket reported earlier. The "DUP of #XYZ" comment should be added, pointing to that ticket. 
    23  * Resolve the ticket as '''{{{worksforme}}}''' if the bug seems to not be present in the current trunk code. A comment should be added instructing the reporter to check it again and provide more information. A ticket with this status, expires in 30 days if no action is taken in the ticket, resolving it as "worksforme". 
    24  * Resolve the ticket as '''{{{invalid}}}''' if it does not describe a problem with CKEditor. 
    25  * Resolve the ticket as '''{{{wontfix}}}''' in the rare cases that the bug seems valid but there's a specific reason why it should not (or cannot) be fixed. A comment with explanation of reasons, should be added. 
    26  * Check the option '''{{{request info}}}''' if the ticket does not have enough information to move forward, ticket would be returned to reporter, asking him for more details. Ticket status is set to ''pending'', and expires in 30 days if no action is taken. 
    27  * Check the option '''{{{confirmed}}}''' if the issue could be reproduced. For browser specific tickets, the relative keyword should be appended. List of allowed keywords could be found [http://dev.ckeditor.com/wiki/TicketSpecs here]. 
    28  * Mark the ticket with the '''{{{HasPatch}}}''' keyword, if a patch or descriptive code changes is provided, even if not analyzed and reviewed. 
     21The following actions could be taken when confirming a new ticket: 
     22 * Resolving the ticket as '''{{{duplicate}}}''' if the ticket is determined to have the same cause as another one reported earlier. The "DUP of #''XYZ''" comment should be added, pointing to that ticket. 
     23 * Resolving the ticket as '''{{{worksforme}}}''' if the bug seems to be absent in the current trunk code. A comment should be added instructing the reporter to check it again and provide more information. A ticket with this status expires in 30 days if no further action is taken, resolving it as '''worksforme'''. 
     24 * Resolving the ticket as '''{{{invalid}}}''' if it does not describe a problem with CKEditor. 
     25 * Resolving the ticket as '''{{{wontfix}}}''' in the rare cases that the bug seems valid but there is a specific reason why it should not (or cannot) be fixed. If this is the case, a comment explaining the reasons should be added. 
     26 * Checking the option '''{{{request info}}}''' if the ticket does not contain enough information to move forward. The ticket will be returned to reporter, asking for more details. Ticket status is set to '''pending''' and it expires in 30 days if no further action is taken. 
     27 * Checking the option '''{{{confirmed}}}''' if the issue can be reproduced. For browser-specific tickets an appropriate keyword should be appended. A full list of allowed keywords can be found [http://dev.ckeditor.com/wiki/TicketSpecs here]. 
     28 * Marking the ticket with the '''{{{HasPatch}}}''' keyword if a patch or descriptive code change is provided, even if not analyzed and reviewed. 
    2929 
    3030== Analyzing == 
    3131 
    32 Once confirmed, the research starts to identify the source of the problem. A core developer could '''Accept''' the ticket. Ticket gains status {{{assigned}}} automatically, indicating that work is already in progress for it, avoiding duplicated work.  
     32Once a ticket is confirmed, the research starts to identify the source of the problem. A core developer could '''Accept''' the ticket. In this case the ticket automatically gets an {{{assigned}}} status, indicating that work on it is already in progress.  
    3333 
    34 The assignee, the reporter or other could come with some more information at this point, to help on the analysis research and coding. 
     34The assignee, the reporter, and other interested parties can come up with some more information or suggestions at this point in order to help with the analysis, research, and coding. 
    3535 
    3636== Proposing Patches == 
    3737 
    38 A proposed patch should be added as a new attachment to the ticket. It must be a valid SVN patch file, named ''XYZ.patch'', where "XYZ" stands for the ticket number.  
    39 The  keyword '''HasPatch''' should be appended to the ticket, and selected action should be set as ''put on review'', indicating that the patch awaits review. 
     38A proposed patch should be added as a new attachment to the ticket. It must be a valid SVN patch file, named {{{XYZ.patch}}}, where "XYZ" stands for the ticket number.  
     39The  keyword '''HasPatch''' should be appended to the ticket, and selected action should be set to '''put on review''', indicating that the patch awaits review. 
    4040 
    41 When a submitter proposes an updated patch, the previous patch should still remain in the ticket. The new patch should be named ''XYZ_n.patch'', where "n" is a progressive number starting from "2". The new patch makes previous ones obsolete. The review status should be set again, with instructions to the reviewer. 
     41When the submitter proposes an updated patch, the previous patch should still remain attached to the ticket. The new patch should be named {{{XYZ_n.patch}}}, where ''{{{n}}}'' is a consecutive number starting from "2". A new patch makes previous ones obsolete. The review status should be set again, with instructions to the reviewer. 
    4242 
    4343== Reviewing Patches == 
    4444 
    45 A reviewer will read through each proposed patch. If the patch is ready to commit, the reviewer will change the review keyword to '''Review+'''. 
     45A reviewer will read through each proposed patch. If the patch is correct and ready to commit, the reviewer will change the ticket status to '''PASSED review'''. 
    4646 
    47 A patch might not be ready to commit for various reasons. The bug fix might be incorrect. The coding style might be incorrect. The reviewer should always explain in detail why a patch is not ready to commit, so the submitter or someone else can revise the patch. The review keyword is changed to '''Review-''' at this point. 
     47A patch might not be ready to commit for various reasons. The bug fix or the coding style might be incorrect, for example. If this is the case, the reviewer should always explain in detail why a patch is not ready to be committed, so the submitter or someone else can revise the patch. At this point the ticket status is changed to '''FAILED review'''. 
    4848 
    4949== Commit == 
    5050 
    51 After a patch has been reviewed, someone with commit privileges in the source repository will commit it. The ticket is then resolved as "fixed", pointing to the relative changed with a message like "Fixed with [XYZ].". 
     51After a patch has passed the review, someone with commit privileges in the source repository will commit it. The ticket is then resolved as '''fixed''', pointing to the checkin number with a message like "Fixed with [''XYZ''].". 
    5252 
    53 If the assignee or the patch developer has commit privileges, he/she has the preference to commit it. 
     53If the assignee or the patch developer have commit privileges, they can commit the patch themselves once it has passed the review and was accepted. 
© 2003 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy