Changes between Version 5 and Version 6 of TicketLifeCycle

Timestamp:

Aug 31, 2010, 12:49:00 PM (13 years ago)

Author:

Krzysztof Studnik

Comment:

Not finished

TicketLifeCycle

@@ -1 +1 @@
 = Ticket Life Cycle =
+[TODO] 
+Update this page
 
 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.
@@ -7 +9 @@
 == Ticket Creation ==
 
-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.
+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]'''
 
 == Clean up ==
@@ -17 +19 @@
 Someone from the core development team should then check the ticket information and decide whether it has enough useful information to move forward.
 
-The following actions could be taken when confirming a ticket:
-
- * 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.
-
- * 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".
-
- * Resolve the ticket as "invalid" if it does not describe a problem with CKEditor.
-
- * 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.
-
- * 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.
-
- * 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".
-
- * Mark the ticket with the "HasPatch" keyword, if a patch or descriptive code changes is provided, even if not analyzed and reviewed.
+The following actions could be taken when confirming new ticket:
+ * 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.
+ * 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".
+ * Resolve the ticket as '''{{{invalid}}}''' if it does not describe a problem with CKEditor.
+ * 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.
+ * 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.
+ * 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].
+ * Mark the ticket with the '''{{{HasPatch}}}''' keyword, if a patch or descriptive code changes is provided, even if not analyzed and reviewed.
 
 == Analyzing ==
 
-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.
+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. 
 
 The assignee, the reporter or other could come with some more information at this point, to help on the analysis research and coding.
@@ -41 +36 @@
 == Proposing Patches ==
 
-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.
+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  keyword should be appended to the ticket, indicating that the patch awaits review.
 
 If the submitter of a patch changes their mind about wanting a review, the review keyword should be removed.