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
_______________________________________________
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
