Ticket Life Cycle

Every 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.

This document describes the life cycle of a ticket in the CKEditor project.

Ticket Creation

Anyone is allowed (and invited) to open tickets for every single issue encountered in CKEditor. The Bug Reporting Instructions and 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 new status.

Clean up

The ticket title, its description, or its fields may possibly be cleaned up to conform to our internal requirements and recommendations.

Confirming Bugs

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 new ticket:

• 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.
• 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.
• Resolving the ticket as invalid if it does not describe a problem with CKEditor.
• 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.
• 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.
• 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 ​here.
• Marking the ticket with the HasPatch keyword if a patch or descriptive code change is provided, even if not analyzed and reviewed.

Analyzing

Once 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.

The 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.

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 keyword HasPatch should be appended to the ticket, and selected action should be set to put on review, indicating that the patch awaits review.

When 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.

Reviewing Patches

A 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.

A 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.

Commit

After 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].".

If the assignee or the patch developer have commit privileges, they can commit the patch themselves once it has passed the review and was accepted.