launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

A while ago I made the observation (I don't think it was original)
that bugs with imperatives in their title/description are poor bug
reports.

They are poor for a couple of reasons:
 - they age badly ('foo should bar' becomes incomprehensible within months)
 - there is a high correlation between bugs with imperatives and bugs
without a clear statement of symptoms

Now, we have roughly 3 classes of bugs:
 - bugs that report a problem in the implementation of the system
 - bugs that report a limitation in the design of the system (aka
feature requests)
 - bugs that are placeholders for QA - short lived workitems.

In recent months, I've seen a lot of the workitem style bugs which are
very opaque, and presume that the very detailed workitem is a)
comprehensible and b) the right way forward.

I propose a personal experiment: please take the same care in filing a
workitem bug as you would documenting a system limitation or defect in
the current implementation. Document what it is you cannot do, or that
happens incorrectly, and propose at least one way forward. I wager
that you will often see the thing you are working on more clearly by
doing this. And your colleagues will be less confused ;).

-Rob