Re: More than one user per bug and more thanone user per category.

I don't think Glenn means responsible as in "the buck stops here" but
rather "the lead person for making the needed actions happen".

In my experience assigning actions to a group is a surefire way to make
them not happen.

Ade

-----Original Message-----
From: mantisbt-dev-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
[mailto:mantisbt-dev-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx] 
On Behalf Of Patrick
Schoenfeld
Sent: 26 November 2007 09:32
To: mantisbt-dev-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
Subject: Re: [mantisbt-dev] More than one user per bug and more thanone
user per category.

Hi,

On Fri, Nov 23, 2007 at 10:00:48PM -0500, Glenn Henshaw wrote:
>    The issue is a tradeoff between responsibility and "credit". In  

I don't agree.

> most group activities in North America, progress doesn't happen  
> without a leader. A responsible person helps to ensure that someone is

> responsible to get the work done. As you noted, the same person is  
> deemed to have "resolved" the problem.

Ah, alright. Off course there *could* be one responsible person, but
thats not what mantis is at all about, right? All fields tell about the
one beeing the person who _works_ on a specific issue, thats different
from taking responsibility for it. In my company I am the one who takes
responsibility for everything happening regardless of weither I do it or
if another employee from the same division does. But it would not make
any sense to assign bugs to me. Because responsibility is something that
*does not need* to be expressed in Mantis. Responsibility is already
expressed in many different ways (by group leadership etc.) but Mantis
is about who actually _does_ something.

Another example: If we would be more persons in our division, then the
work could be done by several people alltogether, excluding me.
I am responsible for this to the CEO, while one of the group is
responsible to me. Who would be the one for the field? The one who is
responsible? No, thats not possible, because there are *two* people with
responsibility.
Setting it to me, the one with the "highest responsibility", would not
make sense either. It would fake the developer stats.

>    I can see using groups for emails, access control and project  
> assignment, but not for assigning bugs.

But why? The field is not about responsibility (just because it makes no
sense) but instead about who does the work (thats clear from all the
terminoloy used in mantis and also from the stats!), so it would be
logical.

Best Regards,
Patrick

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
mantisbt-dev mailing list
mantisbt-dev-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

______________________________________________________________

This incoming email was virus scanned for HESA by MessageLabs.
______________________________________________________________

_____________________________________________________________________

Higher Education Statistics Agency Ltd (HESA) is a company limited by
guarantee, registered in England at 95 Promenade Cheltenham GL50 1HZ.
Registered No. 2766993. The members are Universities UK and GuildHE.
Registered Charity No. 1039709. Certified to ISO 9001 and BS 7799. 
 
HESA Services Ltd (HSL) is a wholly owned subsidiary of HESA,
registered in England at the same address. Registered No. 3109219.
_____________________________________________________________________

This outgoing email was virus scanned for HESA by MessageLabs.
_____________________________________________________________________

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/