Handling trackers: Difference between revisions
Dan Polansky (talk | contribs) (+See also) |
Dan Polansky (talk | contribs) (→Priority <<Proposal>>: simplify the heading to eanble referring to it) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 71: | Line 71: | ||
|} | |} | ||
== Priority '' | == Priority == | ||
''This is a non-binding proposal of how to determine the priority of a bug.'' | |||
The purpose of the priority is to make decision easier if a bug can remain open for a specific release or not, according to the following rules: | The purpose of the priority is to make decision easier if a bug can remain open for a specific release or not, according to the following rules: | ||
Latest revision as of 08:07, 19 May 2011
Closing feature requests and bugs
Stable package
When a developer solves in CVS a feature request or a bug (both an issue) relating to stable package,
- she should assign the issue to the group FreeMind 0.8.0 - Fixed in CVS leaving the issue Open, given 0.8.0 is the stable package.
When a final release containing the solution is out,
- the issue should be assigned to the groups FreeMind 0.8.0 and set to Closed.
Unstable package
When an issue relating to unstable package is solved in CVS, it shall be closed only after the solution has been made available in another beta or RC release in unstable package. As soon as the issue is solved in CVS, it should be assigned the group FreeMind 0.9.0 - Fixed in CVS, given 0.9.0 is the unstable package.
Groups in Bugs tracker
| Group | Note |
|---|---|
| FreeMind 0.8.0 | |
| FreeMind 0.8.0 - Fixed in CVS | |
| FreeMind 0.9.0 | |
| FreeMind 0.9.0 - Fixed in CVS | |
| FreeMind 0.9.0 - Out of scope |
Categories in Bugs tracker
Categories allow us to assign per default bugs to a certain developer, as documented in the following table.
Note: The SourceForge tracker allows theoretically to assign automatically bugs with a certain category to a certain developer, but the feature seems slightly broken, so it's more secure to assign category and developer to a bug.
| Category | Owner ID | Note |
|---|---|---|
| Export / Import / XSLT | christianfoltin | |
| Filter and Attributes | dpolivaev | |
| Flash Online Viewer | juanpedro | |
| Java Applet/Viewer | christianfoltin | |
| Linux | ewl | |
| Mac OS (X) | christianfoltin | |
| Painting and Laying out | dpolivaev | |
| Plug-ins | christianfoltin | |
| Printing | christianfoltin | |
| Rich Text Editor / SimplyHTML | dpolivaev | |
| Saving & Loading | dpolivaev | |
| Windows | dpolivaev |
Priority
This is a non-binding proposal of how to determine the priority of a bug.
The purpose of the priority is to make decision easier if a bug can remain open for a specific release or not, according to the following rules:
- priority > 5 - the bug must be closed before the next FreeMind release
- priority < 5 - the bug can remain open through a release cycle
- priority = 5 - 5 is the default bug value and can't have a special meaning, hence the bug must be assessed
Determining the priority works as follows:
- determine the priority based on the type of the bug.
- correct this priority based on the presence of a workaround and the number of users impacted.
- if you get 5 as priority, use your judgment to correct up or down (could you live with this bug?)
- after each FreeMind release, raise the priority by 1 (skipping 5).
| Type of bug | Explanation | Priority |
|---|---|---|
| Data loss | user can loose data due to the bug | 7 |
| Availability | FreeMind itself or certain functions can't be used | 5 |
| Reliability or Performance | FreeMind crashes or certain functions do not always work, or only with limited speed | 4 |
| Feature bugs | certain features of a function can't be used or only in a limited way (such bugs can be suspect to be enhancement requests) | 3 |
| Workaround Presence | Explanation | Priority Correction |
|---|---|---|
| No workaround | +1 | |
| Any workaround | 0 | |
| Definitive workaround | A definitive workaround is one that you apply once and then you're protected forever against data loss; avoiding to do something wouldn't be definitive, changing a configuration parameter would be so, being able to repair a corrupted FreeMind file as well | -1 |
| Users impacted | Explanation | Priority Correction |
|---|---|---|
| All | All users on one or more platforms | +2 |
| Many | Many users, due to a common configuration | +1 |
| Few | Few users, having a slightly uncommon but meaningful setup | 0 |
| Very few | Very few users, having a rather meaningless setup, possibly not worth being supported by FreeMind | -1 |
