Changes between Version 5 and Version 6 of TicketLifeCycle


Ignore:
Timestamp:
Aug 31, 2010, 12:49:00 PM (9 years ago)
Author:
Krzysztof Studnik
Comment:

Not finished

Legend:

Unmodified
Added
Removed
Modified
  • TicketLifeCycle

    v5 v6  
    11= Ticket Life Cycle =
     2[TODO]
     3Update this page
    24
    35Every 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.
     
    79== Ticket Creation ==
    810
    9 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.
     11Anyone 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]'''
    1012
    1113== Clean up ==
     
    1719Someone from the core development team should then check the ticket information and decide whether it has enough useful information to move forward.
    1820
    19 The following actions could be taken when confirming a ticket:
    20 
    21  * 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.
    22 
    23  * Mark the ticket with the "WorksForMe" keyword 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 "WorksForMe" ticket expires in 30 days if no action is taken in the ticket, resolving it as "worksforme".
    24 
    25  * Resolve the ticket as "invalid" if it does not describe a problem with CKEditor.
    26 
    27  * 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. If the reason is something we can't workaround, the "CantFix" keyword should be used.
    28 
    29  * Mark the ticket with the "Pending" keyword, if the ticket does not have enough information to move forward, asking the reporter for more details. A "Pending" ticket expires in 30 days if no action is taken in the ticket.
    30 
    31  * Mark the ticket with the "Confirmed" keyword. For browser specific tickets, the relative keyword should be appended: "IE", "IE6", "IE8", "Firefox", "Firefox2", "WebKit" and "Opera".
    32 
    33  * 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 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.
    3429
    3530== Analyzing ==
    3631
    37 Once confirmed, the research starts to identify the source of the problem. A core developer could "Accept" the ticket, indicating that work is already in progress for it, avoiding duplicated work.
     32Once 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.
    3833
    3934The assignee, the reporter or other could come with some more information at this point, to help on the analysis research and coding.
     
    4136== Proposing Patches ==
    4237
    43 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. The "Review?" keyword should be appended to the ticket, 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 should be appended to the ticket, indicating that the patch awaits review.
    4440
    4541If the submitter of a patch changes their mind about wanting a review, the review keyword should be removed.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy