Handling trackers

From FreeMind
Revision as of 08:07, 19 May 2011 by Dan Polansky (talk | contribs) (→‎Priority <<Proposal>>: simplify the heading to eanble referring to it)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

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.

Categories in Bugs tracker
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:

  1. determine the priority based on the type of the bug.
  2. correct this priority based on the presence of a workaround and the number of users impacted.
  3. if you get 5 as priority, use your judgment to correct up or down (could you live with this bug?)
  4. 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

See also

Links