|Version 20 (modified by krst, 3 years ago) (diff)|
Table of Contents
Reporting tickets can be very tricky if you are doing it for the first time. In some cases users unwillingly put to much or to little information about a bug or a new feature and as a result the ticket handling process extends. That is why we have placed some recommendations about every ticket field 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 settled faster.
In this field the reporter should place a short summary about the ticket. If possible the reporter should put the name of the browser in which a new bug has occurred or in which a new feature is requested, in the beginning of the summary. Of course if the reported problem is found in every browser you don't have to put anything in the beginning of the field.
IE: The sampleposteddata pages are not wrapping the "Value" column
Safari: objects are not selectable
FF3 : Content "flashing" on load
This field is used for choosing the type of the ticket. You can choose from:
- Bug - if you found that something isn't working properly in CKEditor or in our other projects
- New Feature - when you want to make a request for something new to be added to any of our project
- Task - tasks are usually used by CKEditor core development team to specify "things that should be done" which aren't related to Bug and New Feature. So generally we don't recommend to use this type by reporters.
The Full description field is the most important field in 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 now about when filling this field.
Every 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 bugs the things aren't so easy because we must reproduce the bug. Sometimes it is very hard to be done because of lack of the information that the reporter is providing. So besides the bug description we recommend to write a step by step instruction for reproducing the bug.
It is also essential to write what kind of browser or browsers the reporter is using when finding the bug e.g. IE, Firefox; what is the browser version and also what kind of operating system the reporter is using e.g. MAC, Linux, Vista. It could be done by adding 'Keywords' into field described below.
The following example will show you a full description regarding all the necessary data:
When pasting a large image from 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 "Paste from Word" 3. Paste the image into the window. 4. Click on the image so it is highlighted 5. You will see that the image frame is outside the window. Browser: IE 6.0.2900.2180 OS: Windows XP with SP2
This option allows us to segregate the most important issues from the least important ones.
We recommend the to set the priority to Normal and not to use the High and Low options. Of course it is a very important for us to know what Bugs/New Features we should deal with firstly. That is why every ticket is reviewed by someone from the core development team, who sets its priority due to its importance.
This option is used by the core development team for targeting Bugs and New Features. So for example, if we have confirmed a bug and someone has began fixing it, we set the Milestone to specify what version will be free of this bug e.g. 'CKEditor 3.5'. We recommend no to use this option by reporters and leave this setting for developers.
Component is an option which allows to specify in what part of the program the bug occurred, or for what part of the program a New Feature is requested for. So for example: if you have a problem with a context menu you set the Component to UI : Context Menu. If you are not sure what kind of component to choose just leave it as General.
Note: There are two options in the list that regard to CKEditor sister projects: CKPackager and MediaWiki+FCKEditor so if you have a problem with one of them simply choose one of these options.
This option allows the reporter to specify in which version of CKEditor or FCKEditor a bug occurred. If you have found a bug in two versions, remember to always choose the 'older' version of the program. That way we can determine the origin of the bug.
The "Keywords" field is a powerful and important feature. CKEditor core development team uses it to gain information regarding 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 Browser and Operating System keywords. The reporter can always check what kind of keywords have we used and in this way he or she can see what is the current status of the ticket and where the problem occurs.
Example: MAC Safari
The following is the list of standard keywords that we use. The keyword name is always "PascalCased" with no spaces:
In most of cases, Windows operating system is used, so there is no need for adding keyword. For other operating systems there are keywords defined:
For tickets, which come from operating systems other than Linux, Mac and Windows, please describe your environment in Full description field.
Gecko Marks tickets that are related to Gecko compatible browsers only. Possible keywords are:
- Gecko for all Gecko browsers including Firefox, Flock, Camino, etc.
- Firefox for all Firefox versions
- Firefox2, Firefox3, Firefox4 for specific versions
Opera Opera Marks tickets that are related to Opera browsers only.
IE Marks tickets that are related to Internet Explorer only. Possible keywords are:
Webkit Marks tickets that are related to Webkit compatible browsers only. Possible keywords are:
- Webkit for all browsers, based on Webkit engine
- Chrome for all Chrome or Chromium versions
- Chrome5, Chrome6, Chrome7 for specific Chrome versions
Core Developers Activity
- HasPatch - Tickets that contains a "valid" (checked by a core developer) proposal patch attached to it. A dedicated report has been created for it.
- Discussion - Tickets that need more discussion to understand the expected behavior, its correct interpretation, the correct way of handling then, etc...
Archived keywords Keywords that are no longer in use (replaced by Trac statuses), but 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 its has been understood as a valid request. It's 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).
- SF Marks tickets that has been originally 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.
This field 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 be only used to gain information about the tickets status. So if you see that a ticket has been assigned it means that someone has began working with it.
The last option in the ticket opening 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 for the attachment.