launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12-04-10 05:43 AM, Robert Collins wrote:
> 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.

The sense of entitlement sometimes implied by imperatives can be
irritating, but the imperative itself is not the problem.  Most
imperatives can be rephrased without changing their meaning.  For
example, "Foo should bar" can be rephrased as "Foo does not bar".  The
"should" is implied in the latter phrasing, but the meaning is
essentially unchanged.

So I think imperatives are only a hint that the bug is suboptimal.

> 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.

There are two places where we could describe a work item: the merge
proposal or the bug.  I think the merge proposal is preferable:
 - not all work items need bugs
 - merge proposals are mandatory and should describe the work well
 - merge proposals are associated with the revision that merged the
   work, not just with the branch.

I think that saying "see merge proposal baz" in a work item bug would
reduce the opacity of such bugs without adding undue work.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+HLc4ACgkQ0F+nu1YWqI2e0wCfecU72AYUhfQm6BLnHvuMUSEQ
GzAAn1AaOYtu+6GqivSnBy/YHac7gAqc
=s3Lk
-----END PGP SIGNATURE-----