Priority System for Enhancements

	During our most recent meeting (you'll see minutes and so
forth, soon), justdave suggested that we come up with a
long-term
roadmap.

	To assist this (or basically implement it), I'm going to
be
prioritizing enhancements.

	P1 = We definitely want this. It's a major feature, and
it's
obvious that it would be useful to everybody.

	P2 = We want this, but it's not totally clear or extremely
important.

	P3 = This isn't a bad idea, and maybe we'll want to
implement
it at some point in the future, but it's not near-term
roadmap
material. Some core Bugzilla developer may work on it.

	P4 = This isn't a terrible idea, but it's not important to
our
long-term plans for Bugzilla. We would review a patch if
somebody
posted it, but a core developer is unlikely to work on it.

	P5 = We basically never want this. If somebody implements
it
and asks for review, we *might* look at it.

	Also, if you're a reviewer, feel free to prioritize
enhancements like this. Just remember that a P1 should be
really
obviously needed, and we should basically all agree that
it's needed.

	-Max
-- 
http://www.everythin
gsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else,
too.
-
To view or change your list settings, click here:
<http:
//bugzilla.org/cgi-bin/mj_wwwusr?user=bondyahoo.com>

Hi all 

> 	During our most recent meeting (you'll see minutes and
so
> forth, soon), justdave suggested that we come up with a
long-term
> roadmap.

Yeah!

> 	To assist this (or basically implement it), I'm going
to be
> prioritizing enhancements.
> 
> 	P1 = We definitely want this. It's a major feature,
and it's
> obvious that it would be useful to everybody.
> 
> 	P2 = We want this, but it's not totally clear or
extremely
> important.
> 
> 	P3 = This isn't a bad idea, and maybe we'll want to
implement
> it at some point in the future, but it's not near-term
roadmap
> material. Some core Bugzilla developer may work on it.
> 
> 	P4 = This isn't a terrible idea, but it's not
important to our
> long-term plans for Bugzilla. We would review a patch
if somebody
> posted it, but a core developer is unlikely to work on
it.
> 
> 	P5 = We basically never want this. If somebody
implements it
> and asks for review, we *might* look at it.

I'm wondering - there are cases when it might be useful to
use
Enhancement_Urgent, Enhancement_Needed, Enhancement_Wanted,
Enhancement_Not_Likely as the severity rather than changing
the meaning
of Priority based on the status?  I'm saying this because I
know of a
number of Bugzilla users that have service level agreements
set up in
such a way so that the customer determines severity and the
developer
determines priority.  I'm not suggesting that this override
your
suggestion below, however, it is worth considering.  I have
felt for a
very long time that "Enhancement" (in and of
itself) is inadequate in
describing how badly the "customer" wants
something though both sides
agree that it's not a part of the current design (correct or
not).

One other possibility is to create Roadmap flags:
Plan:ThisMajorRel,
Plan:ThisMinorRel, Plan:ThisFixRel, Plan:NextMajorRel,
Plan:NextMinorRel, Plan:NextBugFixRel, Plan:FutureRel.  It
also wouldn't
be difficult to implement those as keywords.  If Plan:
soundsl ik

> 	Also, if you're a reviewer, feel free to prioritize
> enhancements like this. Just remember that a P1 should
be really
> obviously needed, and we should basically all agree
that it's needed.

Could voting play a helpful role in this?

Kevin Benton
Senior Software Developer
MSS Silicon Design Engineering
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily
reflect the
view of Advanced Micro Devices and have not been reviewed by
management.
This communication may contain sensitive and/or confidential
and/or
proprietary information.  Distribution of such information
is strictly
prohibited without prior consent of Advanced Micro Devices. 
This
communication is for the intended recipient(s) only.  If you
have
received this communication in error, please notify the
sender, then
destroy any remaining copies of this communication.


-
To view or change your list settings, click here:
<http:
//bugzilla.org/cgi-bin/mj_wwwusr?user=bondyahoo.com>

Benton, Kevin wrote:
>
>> 	To assist this (or basically implement it), I'm
going to be
>> prioritizing enhancements.
>>
>> 	P1 = We definitely want this. It's a major
feature, and it's
>> obvious that it would be useful to everybody.
>>
>> 	P2 = We want this, but it's not totally clear or
extremely
>> important.
>>
>> 	P3 = This isn't a bad idea, and maybe we'll want
to implement
>> it at some point in the future, but it's not
near-term roadmap
>> material. Some core Bugzilla developer may work on
it.
>>
>> 	P4 = This isn't a terrible idea, but it's not
important to our
>> long-term plans for Bugzilla. We would review a
patch if somebody
>> posted it, but a core developer is unlikely to work
on it.
>>
>> 	P5 = We basically never want this. If somebody
implements it
>> and asks for review, we *might* look at it.
>>     
>
> I'm wondering - there are cases when it might be useful
to use
> Enhancement_Urgent, Enhancement_Needed,
Enhancement_Wanted,
> Enhancement_Not_Likely as the severity rather than
changing the meaning
> of Priority based on the status?  I'm saying this
because I know of a
> number of Bugzilla users that have service level
agreements set up in
> such a way so that the customer determines severity and
the developer
> determines priority.  
<snip>

This is exactly why bug 9412 needs to be done.
-
To view or change your list settings, click here:
<http:
//bugzilla.org/cgi-bin/mj_wwwusr?user=bondyahoo.com>

Bill - I don't disagree, however, that requires code changes
in order to
implement.  My suggestion requires no code changes and can
be
implemented today (assuming that BMO product/component
owners agree).  I
have been shifting toward features by bug_type in my own
installations.
I'm also implementing default bug types per classification,
but that
code is still very early in the coding stages.

Kevin Benton
Senior Software Developer
MSS Silicon Design Engineering
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily
reflect the
view of Advanced Micro Devices and have not been reviewed by
management.
This communication may contain sensitive and/or confidential
and/or
proprietary information.  Distribution of such information
is strictly
prohibited without prior consent of Advanced Micro Devices. 
This
communication is for the intended recipient(s) only.  If you
have
received this communication in error, please notify the
sender, then
destroy any remaining copies of this communication.
 

> -----Original Message-----
> From: developers-ownerbugzilla.org
[mailto:developers-ownerbugzilla.org]
> On Behalf Of Bill Barry
> Sent: Tuesday, February 27, 2007 4:46 PM
> To: developersbugzilla.org
> Subject: Re: Priority System for Enhancements
> 
> Benton, Kevin wrote:
> >
> >> 	To assist this (or basically implement it),
I'm going to be
> >> prioritizing enhancements.
> >>
> >> 	P1 = We definitely want this. It's a major
feature, and it's
> >> obvious that it would be useful to everybody.
> >>
> >> 	P2 = We want this, but it's not totally clear
or extremely
> >> important.
> >>
> >> 	P3 = This isn't a bad idea, and maybe we'll
want to implement
> >> it at some point in the future, but it's not
near-term roadmap
> >> material. Some core Bugzilla developer may
work on it.
> >>
> >> 	P4 = This isn't a terrible idea, but it's not
important to our
> >> long-term plans for Bugzilla. We would review
a patch if somebody
> >> posted it, but a core developer is unlikely to
work on it.
> >>
> >> 	P5 = We basically never want this. If
somebody implements it
> >> and asks for review, we *might* look at it.
> >>
> >
> > I'm wondering - there are cases when it might be
useful to use
> > Enhancement_Urgent, Enhancement_Needed,
Enhancement_Wanted,
> > Enhancement_Not_Likely as the severity rather than
changing the
meaning
> > of Priority based on the status?  I'm saying this
because I know of
a
> > number of Bugzilla users that have service level
agreements set up
in
> > such a way so that the customer determines
severity and the
developer
> > determines priority.
> <snip>
> 
> This is exactly why bug 9412 needs to be done.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.bentonamd.com>
> 



-
To view or change your list settings, click here:
<http:
//bugzilla.org/cgi-bin/mj_wwwusr?user=bondyahoo.com>

On Tue, 27 Feb 2007 13:47:59 -0800 Max Kanat-Alexander
<mkanatbugzilla.org> wrote:
> 	P1 = We definitely want this. It's a major feature,
and it's
> obvious that it would be useful to everybody.
> 
> 	P2 = We want this, but it's not totally clear or
extremely
> important.

	So, I've gone through all the enhancements that were listed
as
P1 and P2, and triaged them so that P1 and P2 actually now
*mean*
the above.

	So you can now see the features that we most want (now or
ever)
by this URL:

	http://tinyurl.com/2bfu7n

	(That's a search for all open enhancements at P1 or P2 in
the
Bugzilla product.)

	There are 1500 open enhancements in Bugzilla, so I haven't
triaged all of them yet.  If you
think that there's a bug clearly
missing from that list, feel free to email me and point out
(in two or
three sentences maximum) why you think your bug should be on
that list.
I'm sure there are some missing. (As I said--1500
enhancements. I
haven't looked at more than 200 of them or so.)

	-Max
-- 
http://www.everythin
gsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else,
too.
-
To view or change your list settings, click here:
<http:
//bugzilla.org/cgi-bin/mj_wwwusr?user=bondyahoo.com>

On Wed, 07 Mar 2007 16:10:27 +0100 Frédéric Buclin
<lpsolitgmail.com>
wrote:
> Or set the priority yourself if you have editbugs
privs.

	Right, of course.  Although
it may be adjusted by a reviewer
at some point if the setter is not a reviewer.

	-Max
-- 
http://www.everythin
gsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else,
too.
-
To view or change your list settings, click here:
<http:
//bugzilla.org/cgi-bin/mj_wwwusr?user=bondyahoo.com>