|Version 16 (modified by w.olchawa, 7 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 FCKeditor 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 FCKeditor 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 bug or a new feature 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.
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 FCKeditor 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. FCKeditor 2.7 .
We recommend no to use this option by reporters and leave this setting for developers. However there are two exception for this recommendation.
The reporter is allowed to set the Milestone to Opera Compatibility and Safari Compatibility if a Bug or a New Feature regards specifically to Opera and Safari browsers, so you can use this Milestones when something isn't working or should be done only in those browsers.
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 FCKeditor sister projects: FCKpackager 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 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. FCKeditor 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, so we recommend the users not to use this field at all. 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.
The following is the list of standard keywords that we use. The keyword name is always "PascalCased" with no spaces:
|Firefox||(Tickets) Marks tickets that are related to Gecko compatible browsers only (not only Firefox).|
|IE||(Tickets) Marks tickets that are related to Internet Explorer only.|
|IE7||(Tickets) Marks tickets that are related to Internet Explorer version 7.x only.|
|Core Developers Activity|
|CantFix||(Tickets) Indicates that the ticket is looking for something that is almost impossible (or excessively hard) to be achieved or fixed.|
|Confirmed||(Tickets) 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.|
|HasPatch||(Tickets) 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) Tickets that need more discussion to understand the expected behavior, its correct interpretation, the correct way of handling then, etc...|
|Pending||(Tickets) 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||(Tickets) Marks tickets that has been originally created at SourceForge and then transfered to this site.|
|WorksForMe||(Tickets) 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. So if you see that a ticket has been assigned to someone it means that someone has began working with it.