Sheila Mooney wrote:
Phlippe, it is probably worth clarifying the definition that Mimi and
I are using for P1-P4 since there is a bit of a difference between
this and how we are prioritizing them for a release (particularly the
P3s and P4s). Maybe the bugzilla priorities aren't going to always map
directly to our priority scale.
P1 - prevents the user from experimenting with the app
P2 - prevents some users from dogfooding the calendar
P3 - stuff we need for a 1.0 calendar - we don't need all this stuff
for 0.7
P4 - stuff we need for a 2.0 calendar - we don't need all this stuff
for 0.7
Thanks for the extra precision Sheila. Right now I think it's good to
have these show up in our (devs) queue with the here above mentioned
priority so that we can evaluate and swag. It's a good first pass. We
certainly will end up with more than we can address but we'll weed out
more taking a finer comb later. Triaging such a big number of bugs is
essentially an iterative process.
The P1s and P2s really fall under the 0.7 tenets. Bugs 4947, 3651 and
3492 we still consider required for a 1.0 calendar although we might
decide not to fixe them in 0.7. In any case, we would like to know if
you don't think these should be under the 1.0 calendar bucket or you
just don't think they are a high priority for 0.7? I would prefer we
either defer them to another release rather than lowering the priority
and leaving them in for 0.7. I guess what I am saying is that at our
point of view, they are still P3.
For consistency sake, I'd rather set their priority low and keep them in
0.7. Devs are not looking at Future bugs at all right now so I don't
want those issues to disappear from the radar screen entirely before we
had a chance to look at them a little more closely. As P4 or P5, they'll
be prime candidate to punt.
Note that we reset the prio to P3 when moving to a Future release. The
reason is that Priority reflect an instant scheduling view of what needs
to be done first, then second, then third... This typically changes
depending on what the tenets of a release are and where we are in the
cycle. What does not change for a bug when moved around is it severity.
The confusion between the 2 fields is that very often severe bugs get a
P1 (immediate attention) while minor bugs have a lower priority but
that's a simple first order perspective. In reality, Priority is used by
devs to organize their work and is disconnected from the nature of the
bug while Severity is used by bug writers to indicate the nature of the
problem and its importance (which is why having "enhancement" in there
puzzle me... a missing feature can indeed be "critical", but I digress...)
Bug:4535 shouldn't really be under this calendar list at all. I agree
this is an edge case now but when we implement the ability to have
alarms for any type of item (part of the dashboard), people will
likely run into this all the time. We won't be setting alarms for
every 15 min, they will be set for a week in advance, for instance. I
think the right thing to do would be to put it as a P2 for the
dashboard tenet, which it is.
Good point. I made the change to the bug.
Similarly for the polish bugs, we could do as you suggest or just
defer a number of these. Mimi and I could maybe pick a subset for 0.7.
As you indicated, the design team may have the ability to drive the
fixes on these eventually so I am fine with leaving them as is.
Thanks.
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
