I'm not disagreeing and I'm fine raising the severity and priority so
that we get to these bugs fast. If we consider those as "functional
tests that are not automated" cases, then, yes, they should be fixed
immediately.
May be we shouldn't have added the flag then, it's not adding much to
the set of existing fields.
Cheers,
- Philippe
Katie Capps Parlante wrote:
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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
