Table of Contents
Ticket Specs
Reporting tickets can be very tricky if you are doing it for the first time. In some cases users unwillingly put too much or too little information about a bug or a new feature and as a result the ticket handling process extends in time. That is why we have placed some recommendations about each of the ticket report fields to help you understand more about ticket reporting.
If you follow these recommendations, you will help us to speed up the ticket handling process and in this way your request will be able to be settled faster.
Summary
In this field the reporter should place a short, descriptive summary about the issue. If needed, the reporter should give the name of the browser in which a new bug has occurred or for which a new feature is requested, in the beginning of the summary. If the reported problem is found across different browsers this information is not needed.
Examples
[IE11] The sampleposteddata pages are not wrapping the "Value" column
[Safari] Objects are not selectable
[FF] Content "flashing" on load
Type
This field is used for choosing the type of the ticket. You can choose between:
- Bug - if you found that something is not working properly in CKEditor or other CKSource projects
- New Feature - when you want to request a new feature to be added to any of our projects
- Task - tasks are usually used by CKEditor core development team to specify "things that should be done" which are not related to Bug and New Feature. Generally we do not recommend external reporters to use this type.
Description
The Description field is the most important field when creating a new ticket. Its content allows our team to know with what kind of problem the reporter is dealing with. There are a few tips that the reporter should take into account when filling this field.
Each issue must be confirmed by someone from our core development team.
- When it comes to confirming new features, we just check if the request is valid and possible to be implemented or not.
- When it comes to confirming bugs, things are not so easy because we must reproduce the bug. Sometimes it can be hard because of lack of information that the reporter is providing. So apart from the bug description we recommend to provide a step-by-step instruction for reproducing the bug.
It is also essential to describe the environment that the reporter is using, i.e. give the name of the browser or browsers (IE, Firefox, etc.); browser version (IE8, Firefox 3.6, Opera 11), the operating system (MAC, Linux, Windows Vista). This information can also be added by entering keywords into the Keywords field described below.
Example
The following example will show you a full description containing all the necessary data:
When pasting a large image from Microsoft Word by using "Paste from Word" and highlighting it in the PfW window, the frame of the image goes outside the window area. Steps to reproduce: 1. Copy a big image from Word using CTRL+C (the picture should be bigger than the "Paste from Word" window. 2. Go to CKEditor and open the "Paste from Word" dialog window. 3. Paste the image into the window. 4. Click the image to highlight it. 5. You will see that the image frame is outside the window. Browser: IE 6.0.2900.2180 OS: Windows XP with SP2
Ticket Properties
Priority
This option is usually disabled for reporters. It allows us to separate the most important issues from the least important ones.
By default, the priority is set to Normal. The High and Low options are set after new issue is confirmed, to know what Bugs/New Features we should deal with firstly. That is why each ticket is reviewed by someone from the core development team, who sets its priority according to its importance.
Milestone
This option is disabled for reporters. Even if enabled, we recommend the reporters not to use this option and leave this setting for the core developers. The Milestone option is used by the core development team for targeting Bugs and New Features. If, for example, we have confirmed a bug and someone began fixing it, we set the Milestone to specify which release will be free of this bug e.g. CKEditor 3.5.3.
Component
Component is an option which allows the reporter to specify in what part of the program the bug occurred, or for what part of the program a New Feature is requested. If, for example, you have a problem with the context menu, you set the Component to UI : Context Menu.
A detailed list of components is maintained on the Components? page.
If you are not sure what kind of component to choose, just leave it as General.
Note: The list also contains some CKEditor sister projects, like CKPackager,CKReleaser, CKLangTool, and MediaWiki+FCKEditor, so if you have a problem with one of them simply choose one of these options.
Version
This option allows the reporter to specify in which version of CKEditor or FCKEditor a bug first occurred. If the bug can be confirmed for more versions, remember to always choose the older version of the program. That way we can determine the origin of the bug.
Keywords
The Keywords field is a powerful and important feature. CKEditor core development team uses it to gain information about a ticket, including browser details, current status, and ticket quality. Someone from our team always sets the keywords when a bug is reported, we also recommend the users to fill the Browser and Operating System keywords. The reporter can always check what kind of keywords we have used and in this way he or she can see what the current status of the ticket is and where the problem occurs.
Please note that the Keywords field should not be used for adding arbitrary tags that describe the issue. While filing tickets, use the pre-defined keywords only.
Example: Mac Safari
The following is the list of standard keywords that we use. The keyword name is always "PascalCased" with no spaces:
Operating System
In most of cases, Windows operating system is used, so there is no need for adding a special keyword for that. For other operating systems the following keywords are defined:
For issues that occur in operating systems other than Linux, Mac, and Windows, please describe your environment in the Description field.
Browser
Gecko - Marks tickets that are related to Gecko-based browsers only. Possible keywords are:
IE - Marks tickets that are related to Internet Explorer only. Possible keywords are:
- IE for all Internet Explorer versions.
- IE6, IE7, IE8, IE9, IE10, IE11 for specific versions of Internet Explorer.
WebKit - Marks tickets that are related to WebKit-based browsers only. Possible keywords are:
Blink - Marks tickets that are related to Blink-based browsers only. Possible keywords are:
- Blink for all browsers based on the Blink engine.
- Chrome for all Chrome versions.
- Opera for all Opera versions.
Core Developers Activity
- Discussion - Tickets that need more discussion to understand the expected behavior, its correct interpretation, the correct way of handling them, etc.
- HasPatch - Tickets that contains a "valid" (checked by a core developer) proposal patch attached to it. A dedicated report has been created for it.
- Refactoring - Tickets related to code refactoring whose purpose is to improve the overall code quality.
- VendorFix - Tickets where the fix is supposed to be provided by a third-party, like a browser, OS or platform vendor. These kinds of tickets usually remain opened until the fix is not confirmed at the vendor application.
- NeedsTest - Tickets that need tests to be written.
Archived keywords Keywords that are no longer in use (replaced by Trac statuses), but could be added to older tickets.
- Confirmed for "Bugs", it indicates that a core developer was able to confirm the bug in some way, validating the ticket. For "New Features" and "Tasks", it indicates that the ticket has been reviewed and it has been understood as a valid request. It is not there to indicate our intentions on working on the ticket though.
- Pending - Marks tickets that need more information to be correctly understood or even reproduced. A dedicated report has been created to easily identify expired tickets (pending for more than 30 days).
- Review+ - When the patch attached to the ticket has passed the review and is ready to be committed.
- Review- - When the patch added to the ticket has failed the review and is not ready to be committed (contains bugs or the coding style is incorrect).
- SF - Marks tickets that have originally been created at SourceForge and then transfered to this site.
- WorksForMe - Indicates that a core developer has tried to reproduce the problem with no success, having the expected results instead.
Assign to
This option is disabled for reporters. It is used by the development team to specify who will fix the bug or who will handle a new feature. We recommend reporters not to use this field at all. This field should only be used to gain information about the tickets status. So if you see that a ticket was assigned, it means that someone began working on it.
Attachments
The last option in the ticket creation process is adding an attachment. If you want to add an attachment, check the "I have files to attach to this ticket" box. After submitting the ticket you will be asked to provide an attachment.
