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
