[Dev] Re: [Design] Calendar dogfood bugs/enhancements for 0.7
pbossut at osafoundation.org
Wed Feb 8 22:33:48 PST 2006
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.
More information about the Dev