From: John Cole <john.cole@ua...> - 2004-07-20 14:05:59
Your 'confirmation' procedure sounds very interesting, but that isn't what
I was wanting for our case :-) In our situation, we are getting some
friction between developers, tech support and sales/marketing about the
order bugs and features are addressed (especially features).
We had some people go to a user conference for a utility package that we
use. At that conference, there was a technical session where they went over
a bug/feature list and everyone in the audience voted on the priority of
those issues. Well, someone here loved the idea (I'm not too fond of it
Within hours of hearing this story, I loaded the 0.19 alpha of mantis and
saw the 'Sponsor' feature and realized that it almost was a voting based
priority value for an issue (btw, thanks everyone for changing this to an
'issue' management system and not just a 'bug' tracker).
What I would love to see is a slight modification to the 'Sponsor' feature
that gave you the option of setting a 'user priority' level with either cash
or a vote. It already lists who is sponsoring (and by how much). I haven't
checked but I assume that there is a way to sort issues based on the sponsor
level, so with a little work, this would be very good for setting a user
based priority level.
The 'conformation' process you outlined sounds very nice, but it would
seem that it would require multiple voting accumulators, and would be harder
to interchange with the 'sponsor' feature. I'm hoping that a slight
modification to the 'sponsor' feature might make it into an upcoming 0.19
release (but I expect that it has been frozen for enhancements ;-)
[mailto:mantisbt-dev-admin@...]On Behalf Of Alex
Netman (aka Wanderer)
Sent: Monday, July 19, 2004 11:44 AM
To: John Cole
Subject: Re: [Mantisbt-dev] Mantis 0.19.0a2 released
On Mon, 19 Jul 2004 09:51:00 -0500 (19.07.2004 20:51 my local time),
received Monday, July 19, 2004 at 22:12:12,
you wrote about "[Mantisbt-dev] Mantis 0.19.0a2 released"
at least in part:
JC> There is a feature request
JC> http://bugs.mantisbt.org/bug_view_page.php?bug_id=0000668 for voting
JC> on a bug. Apparently this was started some time ago, and it would be
JC> a nice feature to have, instead of sponsoring an issue, voting or
JC> moderating the priority higher. Could this be addressed in the .19
JC> release? :-)
I see it not as "voting", but as "confirmation" procedure. From my POV
(which I started to implement) it can work in two areas of life-cycle of
1. New issue (or any status below "confirmed") can be escalated to
"confirmed" if it get enough voices of reporters (which haven't another
way to change status). I.e - added new variable into config_inc
g_confirm_issue_level and each vote add to "collected summary" some
value (less or equal to 1), calculated dynamically from "Trust level of
reporter" - % False in Reporter By Resolution can be used for defining
such trust level. Each reported can confirm each issue only once
(additional table will be needed for storing results)
2.(Optional, but useful). In case of presence "fix confirmation"
procedure on workflow same procedure can be used for fix confirmation
and issue status can be changed from "confirmation waited" to "fix
Alex Netman (aka Wanderer)
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
Mantisbt-dev mailing list
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.