I agree with Sheila's point here that the "dogfoodable" flag should
affect priority.
Some bugs have a big impact on people trying to use and test the app
(which is really what we mean by "dogfood" here). We screen for many of
these kinds of problems with functional tests, and stop and fix problems
if they cause the functional tests to fail (or don't commit code that
causes these regressions in the first place).
My understanding is that the "dogfoodable" tag is about marking bugs
that strongly impact use and testing. Many are regressions where we
don't yet have a functional test. We should use this tag sparingly, but
I think the point is to acknowledge that fixing such bugs has a high
payoff even in the short term, and to use that information when judging
the priority. Whether or not a given developer should fix a dogfood bug
vs finish other feature tasks depends on the developer and the tasks.
Cheers,
Katie
Sheila Mooney wrote:
So, not to complicate this process but I wanted to question the comment
about these bugs "not" being a higher priority than others. Is that
really true? I understand that having some metric to see how far we are
from "dogfoodable" is useful but it's really only useful if we act on it
somehow. In the end, we need our dogfooders to help us get Preview out
and making sure they can continue to use Chandler particularly once we
are feature complete is key.
I don't think this is a huge list, it's some very select group of
problems that impact dogfooders significantly. To give a very specific
example, currently when you restore shares, all published calendars are
read only. I download a new Chandler build everyday and I have to
unpublish and republish my work calendar in order to edit it. If I were
sharing with others, I would have to send them new URLs every day. At
the end of the day, it doesn't prevent me from using the app and I get
around it but if we want our dogfooders to be getting weekly checkpoints
and using them, the reality is that there probably is some urgency to
get this sort of thing fixed. From a PPD perspective, when I think of
tagging bugs as "dogfood", this is the type of item I am thinking about.
I know that everyone is working very hard on finishing features which is
the RIGHT priority. However, I believe there might be one or two
developers who are available to fix bugs and I guess I am asking - "In
this case, are these dogfoodable bugs not a guide on what to work on
first"? This is different then having someone stop working on a feature
to fix a dogfood bug, which I am not suggesting. I would imagine these
bugs to be assigned to those who have time to look at them, not
necessarily developers who are on critical path feature work.
In any case, I would like to hear others thoughts on this.
On Jan 19, 2007, at 12:07 PM, Philippe Bossut wrote:
Hi,
During Chandler Engineering meeting yesterday afternoon
(http://wiki.osafoundation.org/Journal/EngineeringMeetingNotes20070118),
we thought that it would be good if we could identify the set of tasks
and bugs needed to be fixed in order to get Chandler 0.7alpha5 to a
"dogfoodable" state.
Dgfoodable means stable enough that it can be used by dogfooders, i.e.
that there's no data loss and no bugs that dogfooders can't cope with.
This is different from the Preview state where it's not only
dogfoodable but usable, i.e., there's no bugs with workaround or
half-there functionalities (things that dogfooders can live with).
For this, I created a new flag in Bugzilla simply named: dogfoodable.
PPD and QA will use it to flag all the bugs that are really required
to get to that stage. Everyone though is welcome to use it if you see
a bug you think that, as a user, you can't cope with.
Note that bugs flagged that way are not "blockers" or "higher
priority" than others, it's just a way to evaluate how far we are from
this dogfoodable state. So devs, though you're welcome to take a
special look at those, there's no immediate urgency for you to act
when you see a Bugzilla message saying that one of your bug has been
flagged.
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
