[Kdenlive-devel] Draft mantis policy - RFC

Fri Oct 31 22:36:33 UTC 2008

Hi all

As promised a draft for a mantis/issue tracking policy/guideline. Its a bit 
wordy, I am afraid. If you can't read it all, then perhaps have a look at the 
workflow diagram. I hope you care to read it and comment. The point is not to 
get facist about this, but rather to try and use Mantis in the most effective 
way for Kdenlive.

-o-

Content:

* Why A Policy?
* A Bugs Life
* Mantis roles
* Relation To Versions

* Why A Policy? 

Mantis as an issue tracker is not particularly strict in its requirement to 
the workflow followed by the users (reporters, updaters, developers, etc). 
The reason for a policy is to get on the same level, at least among the 
updaters, developers, etc. and thereby ensure that we don't "waste our time" 
when handling issues.

The goals of the policy are many, including the following:
- ensure that all issues reported gets treated/solved, thereby confirming 
reporters in the belief that their reports matter, and ensuring the continued 
feedback from a hopefully growing userbase.
- channel feedback from the userbase into development and thereby improve the 
quality and usability of Kdenlive
- support the developers, and minimize the time they need to spend 
with "administrative" tasks, increasing instead the time they have for actual 
coding/fixing.

The policy tries to meet these goals by laying out some guidelines on how to 
use the implicit workflow in Mantis

* A Bugs Life

Mantis by default supports the following phases in a bugs life (text copied 
from the manual):

- new - new bugs
- feedback - bug requires more information, the original posters should pay 
attention
- acknowledged - bug has been looked at but not confirmed or assigned
- confirmed - confirmed and reproducible (typically set by an Updater or other 
Developer)
- assigned - assigned to a Developer
- resolved - bug should be fixed, waiting on confirmation of fix
- closed - bug is closed

I propose we use them slightly differently:

- new: new bugs
- feedback - bug requires more information, the original reporter should pay 
attention
- acknowledged - bug has been confirmed by someone besides the reporter, and 
the issue report principially contains enough information to reproduce the 
issue and for a developer to fix the issue
- assigned - a developer has taken responsibility for the issue and is working 
on a fix
- resolved - bug is fixed in SVN, the fix has been tested and is working
- closed - the bug is fixed in a released version of Kdenlive.

I have tried to illustrate the state transition/the workflow on the attached 
image, which I hope is self-explaining. The only thing that may need a little 
more explanation is the resolved=>close state change, which is related to 
version handling. See below.

* Mantis roles

Mantis operates with different roles. Here is a list of the three most common 
and their suggested/standard capabilities:

reporter: can report an issue. Can monitor issue, and other read-only 
operations
updater: can change the status of an issue, confirm it, review it and close it
developer: as updater, but can assign, move, delete and reopen issues

reporters: Every user that can do anything at all currently needs to be at 
least reporter. Its the basic role.

updaters: I suggest to make the updater role more used. We should have a 
number of updaters, that works as a filter against all the duplicate and 
incomplete bugs, and also as the QA for commits to SVN. For new issues, the 
updaters should see if they can reproduce, if more information is needed, if 
its a duplicate, or already fixed on SVN, or similar. When the issue is 
complete, perhaps after a period as "feedback", it gets acknowledged by an 
updater, and hopefully a developer will look at it. When the developer 
commits a fix, an updater tests the fix, or make sure that the original 
reporter tests it (both, if at all possible) and when the updater is 
satisfied it works well, the updater change the status to resolved. An 
updater can of course also be a reporter, but one should probably not 
acknowledge ones own reports - its "good style" to have someone else 
acknowledge them. (An exception may be feature requests?)

developers: Developers should only really worry about acknowledged or assigned 
issues, and fix them. When fixed, they should refer to the issue in the 
commit logs to svn. It would be nice, if we could use the assigned state as a 
volunter way to track who is doing what, but that may just be me that like 
that sort of thing. Developers can of course also operate as updaters.

Obviously not all issues can be handled like this, often the complexity is to 
high for updaters to be able to handle it. In those cases, the updater may 
just have to acknowledge the issues and have the developer look at them. 
Still, if the updaters can ensure a high quality in, say, 75% of the reports, 
it should still lighten the load on the developers.

* Relation To Versions

There are some mechanisms that one can wish to support using the version 
fields in mantis:

a) track changes to SVN in relation to issues
b) track changes to released versions (ChangeLog)
c) track plans for what to fix in which version (Radmap)

I suggest we do like this:

a) whenever a a fix to an issue has been reviewed and approved, the bug is 
resolved and "Fixed in version" is set to "current svn (KDE4)", and a note is 
added about what SVN rev number that contains a fix. Also, as mentioned 
above, commiters refers to issues, when committing fixes for them.
b) whenever a version is released, all bugs fixed since the last release, are 
closed, and their "Fixed in version" is set to the version number of the 
release (e.g. 0.7.0).
c) whenever an issue is acknowledged, its "Target version" is set appropriate. 
In between versions, the large majority is the next version (currently 
0.7.0), but some major stuff (E.g. "Implement seamless googlevideo support to 
beat imovies marketshare") could go on versions futher in the future (e.g. 
1.0.0). As we near a version release, it should get harder and harder to get 
on the next version, only critical stuff should get on, and issues instead 
goes on the next-next version (currently 0.7.1).

re c) I think this is a reasonably way to do it, but we should probably have 
some generic names, while we are working, perhaps "next-version (0.7.0)" 
and "future-version (0.7.1)" or something like that?

Also, Jean-Michel has suggested we make a special version "To-do list", that 
is a special version that only contains feature requests (Is that about 
right, Jean-Michel?) I am bit reluctant to do that, because I think feature 
requests deserves to be part of the normal roadmap, and by doing a special 
version for them, they won't be part of the roadmap. Instead I think we 
should provide a number of saved filters that show e.g. all currently 
acknowledged but not resolved feature requests. But that may just be me?

-o-

So, that was my suggestion for a Mantis policy. If it is not clear, all of the 
above is very much a suggestion. But obviously I wrote it in the hope that it 
might prove useful. I am a strong believer in issue tracking - it probably 
shows - and I hope that you will post some comments on this and that we 
eventually can agree on some sort of common understanding.

Regards

Mads

-- 
Mads Bondo Dydensborg   mads at dydensborg.dk   http://www.madsdydensborg.dk/

United States Patent 6,368,227:
A method of swing on a swing is disclosed, in which a user positioned on a
standard swing suspended by two chains from a substantially horizontal tree
branch induces side to side motion by pulling alternately on one chain and
then the other. 
            -- This is not a joke - go look it up.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mantis-workflow.png
Type: image/png
Size: 71849 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20081031/948f7ee0/attachment.png>