[Kdenlive-devel] Draft mantis policy - RFC

Mon Nov 10 22:13:12 UTC 2008

fredag 31 Oktober 2008 skrev Mads Bondo Dydensborg:
> Hi all

Hi again

I've had very little feedback (well, ok, I'll be honest, no feedback :-) on 
the list for this mail.

I still think a policy is sort of needed. In the absence of feedback, I am 
going to act as if everybody agreed. (So, someone needs to stop me, if they 
don't! :-)

And as a more or less direct consequence of my self-appointed status as 
mantis-overload (all your bugs are belong to me), Cinephiliac (BugsBane) has 
agreed to be made an "updater" in mantis, and have already been doing a lot 
of great updating, helping to keep the bugs from clotting up in mantis, and 
getting them into shape for the devs (Dan and JB at this point).

I still think we are going to get a surge of bug reports after 0.7.0 is 
released - and that it would be a good thing to have some more people that 
was willing to work as updaters (reviewer/qa) in mantis. Feel free to holler 
out, if you are willing to do this.

Also, updaters might wish to follow the kdenlive-svn mailing list
( Kdenlive-svn mailing list
Kdenlive-svn at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kdenlive-svn )
as the devs are so nice to refer to issues in the commit messages, making it 
easy to track intended changes in relation to issues, and perform the needed 
AQ on them (by testing before closing or providing feedback to the devs).

Regards 

Mads

> 
> 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.
> 

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

The Bible tells us to be like God, and then on page after page it describes
God as a mass murderer. This may be the single most important key to the
political behavior of Western Civilization.
                       - Robert A. Wilson (Right Where You Are Sitting Now)