[Libreoffice-qa] Bug Triage best practice: Change or not change assignee?

Bjoern Michaelsen bjoern.michaelsen at canonical.com
Sat Apr 21 04:28:32 PDT 2012


Hi,

On Sat, Apr 21, 2012 at 09:53:22AM +0200, Rainer Bielefeld wrote:
> I believe it is a very bad idea to use that field to show  who
> should contribute additional information to the bug report, the
> "Assigned To" field should remain reserved for the competent person
> person who will fix the bug (or at least will manage the fixing),
> please also see Bugzilla Help, and I never saw an other usage for
> that field (and I saw a lot, you know.)

Assignee is and has always been the guy who "owns" the bug. Thats the guy who
needs to take the next action for the bug to be resolved. It doesnt make any
difference if that action is changing code, bisecting, designing a new feature
or providing additional info. And "fixing the bug" is not the "changing code"
part -- that is very easy once the issue is identified.

Additionally assigning a NEEDINFO-bug to "competent person who will fix the
bug" makes no sense at all -- as long as the bug is NEEDINFO, there is no way
to know who that would be.

> So I can't see that the new Wiki text describes common sense or
> general use, but it defines a new standard.

This is how ~every other open source project manages its bugs, so its is only
natural to do the same on LibreOffice. Diverting from that standard is want
needs justification, not the other way around. Everyting else (like this
"infoprovider"-nonsense) will only cause confusion. Dont do things you need to
explain, do things that explain themselves. Assigning the bug back to the
reporter selfevidently makes clear that he is required to take action to move
the bug along.

This is how bug tracker users everywhere have been working for ages:
 - bug needs more info to be solved => assign to reporter
 - bug is triaged => assign to dev
 - bug is fixed => assign to QA or reporter for verification
 - bug is verified => assign to the guy who makes the release for closing when
   release in the product

> c) Generally please do not modify existing proceedings without
> discussion, people like me use information in Bugzilla for queries,
> and every change breaks those queries and causes additional work
> (like this discussion, too)

Please dont expect users to do things different then everywhere else because
you would need to adjust your queries.

> d) IMHO it has become a standard that people add themselves to
> "assigned to", this standard would be broken with the proceeding due
> to Wiki

Its no standard at all, as it is not done like that anywhere else. 

> So I suggest proceeding:
> - only set Status NEEDINFO with text request in comment, but without
>   assignation to reporter

I dont see that vital, but it usually helps to bring the point across (better
than any "Dear Reporter" comment, although that helps too).

> - if info is required not from reporter ad "infoprovider" key word.

No, that would be absolutely useless. This "infoprovider" nonsense is rarely
used in bug trackers -- the only major user of this aberration is the Novell
bugzilla, all others use the sane workflow above. It is unintuitive and
uncommon and would require end users (who are the most likely infoproviders) to
read the doc -- which they do not (unlike QA volunteers). In addition it
dilutes the clear responsibility of the "assignee" field: The assignee is the
current owner of the bug and the guy who is expected to move it along. That
usually helps move things along or someone else will pick the bug up. You are
risking lots of silent deadlocks of the assignee-thinks-infoprovider-has-to-action-
this-and-infoprovider-thinks-assignee-has-to-action-this-kind by this.

If there is info needed from someone else than the reporter, it is assigned to
that guy. Thats common sense and how it is done everywhere else. If you want to
do that different for LibreOffice, you need some serious justification. Needing
to adjust queries is not one (we should never have done it like that in the
first place).

So please revert the wiki again and let LibreOffice handle this like pretty
much every other open source project. We should get over that
infoprovider-nonsense as quick as possible and good riddance.

Best,

Bjoern


More information about the Libreoffice-qa mailing list