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>
