| | 1 | = Ticket Life Cycle = |
| | 2 | |
| | 3 | As of FCKeditor 2.5, every line of code introduced in the FCKeditor/trunk tree must pass through a more strict review process. This guarantees the overall quality of the code base. |
| | 4 | |
| | 5 | This document describes the life cycle of a ticket in the FCKeditor project. |
| | 6 | |
| | 7 | == Ticket Creation == |
| | 8 | |
| | 9 | Anyone is allowed (and invited) to open tickets for every single issue faced in FCKeditor. The [wiki:Bugs Bug Reporting Instructions] and [wiki:Features Feature Request Instructions] pages have more information on how to properly fill new tickets. |
| | 10 | |
| | 11 | == Clean up == |
| | 12 | |
| | 13 | The ticket title, its description or its fields could be cleaned up to confirm to our internal requirements and recommendations. |
| | 14 | |
| | 15 | == Confirming Bugs == |
| | 16 | |
| | 17 | Someone from the core development team should them check the ticket information and decide whether it has enough useful information to move forward. |
| | 18 | |
| | 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 FCKeditor. |
| | 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", "IE7", "Firefox", "Safari" 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. |
| | 34 | |
| | 35 | == Analyzing == |
| | 36 | |
| | 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. |
| | 38 | |
| | 39 | The assignee, the reporter or other could come with some more information at this point, to help on the analysis research and coding. |
| | 40 | |
| | 41 | == Proposing Patches == |
| | 42 | |
| | 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. |
| | 44 | |
| | 45 | If the submitter of a patch changes their mind about wanting a review, the review keyword should be removed. |
| | 46 | |
| | 47 | The "HasPatch" keyword, if available, should be removed at this point. |
| | 48 | |
| | 49 | 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 flag should be set to "Review?" again, with instructions to the reviewer. |
| | 50 | |
| | 51 | == Reviewing Patches == |
| | 52 | |
| | 53 | A reviewer will read through each proposed patch. If the patch is ready to commit, the reviewer will change the review keyword to "Review+". |
| | 54 | |
| | 55 | 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. |
| | 56 | |
| | 57 | == Commit == |
| | 58 | |
| | 59 | After a patch has been reviewed, someone with commit privileges in the source repository will commit it. The ticket is them resolved as "fixed", pointing to the relative changed with a message like "Fixed with [XYZ].". |
| | 60 | |
| | 61 | ---- |
