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

Hi,

the question emerged, if reassigning a NEEDINFO-bug to the presumed info
provider[1] is Good or Bad. Please advise.

Nino
[1]
https://wiki.documentfoundation.org/index.php?title=BugTriage&diff=prev&oldid=42240
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

On Thu, Apr 19, 2012 at 10:23:46PM +0200, Nino Novak wrote:
> the question emerged, if reassigning a NEEDINFO-bug to the presumed info
> provider[1] is Good or Bad. Please advise.
>
> Nino
> [1]
> https://wiki.documentfoundation.org/index.php?title=BugTriage&diff=prev&oldid=42240

IMHO yes, the bug should always be assigned to the person that is required to
take action to make the bug proceed.

Best,

Bjoern
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Bjoern Michaelsen píše v Pá 20. 04. 2012 v 00:16 +0200:
I am afraid that it is not scalable. If a developer has 100 bugs
assigned, it is clear that some of them will be there for years. It
creates false feeling that someone takes care of the bug but is it not
true.

If you have too many bugs assigned, you can't even react on comments
because you would spend the whole day with it.

I personally prefer to put developers into CC if the bug is important
but do not assign it. I would leave the other bugs as is and wait until
someone pick them. I would just make sure that the severity and
component is correct.


Best Regards,
Petr

_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

On Fri, Apr 20, 2012 at 04:15:40PM +0200, Petr Mladek wrote:
Wait, wait. We are talking about bugs in NEEDINFO being assigned to the
reporter to make clear that the report is incomplete. While devs are sometimes
also reporters those are cornercases (and if indeed a dev-reported bug goes to
NEEDINFO the missing info will hopefully be reported back quickly.

Best,

Bjoern
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hello Nino, bello Bjoern, hello all,

IMHO "not change"! I can't remember that we ever discussed to modify
"Assigned to" related to "NEEDINFO", and it has never been used that
way, not in the various other projects using Bugzilla I joined, and also
not for LibO - except by Nino, who did not know how to use the Bugzilla
fields.

To be honest, I missed the change in the Wiki by Bjoern  2011-12-23,
23:59:40, I would have reverted it and asked for discussion because I
strictly disagree.

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

Of course, everything can be put on the test stand, but if you want to
modify something, you should have good reasons, but I can't see any.

a) If you believe it's an established standard to use "Assigned To" to
show from whom info is required, so please contribute examples from time
before before modification in the Wiki.
Currently I see 26 Bugs with NEEDINFO and assignee not
[hidden email], most of assignees are
developers, many of them the developer assignee seems to have forgotten
to set Status to ASSIGNED, and most other ones nave got that assignation
by Nino last days. [2] shows 3 bugs with NEEDINFO + not default
assignee, all reporters.
So I can't see that the new Wiki text describes common sense or general
use, but it defines a new standard.

b) If you believe a problem has to be solved, please tell the problem
and explain how you want to solve it and what alternatives you excluded.
Currently I can't see a problem:

b1) The NEEDINFO mostly is joined with a comment "@dearreporter, can you
please add following information ...), what can be understood by the
reporter and is much better than a use of the "Assigned to" field
different to the Help explications he reaches clicking the link in
Bugzilla.  I believe at least 99% of our Bugzilla users will expect that
information is required from reporter if nothing else is written. And
many ones.

b2) Additionally for me an assignee different from default is an
indication that this but is out of QA "responsibility" and has found a
developer (or someone else who will lead the problem to a solution) and
no further "QA-action (currently) will be required; I believe most other
Bugzilla users think the same way.

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)

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

e) I see one special case where a _self_assignition_ to "assigned to" of
a non developer can be useful and should be done (and I do so): If a bug
still needs longer, expensive research and someone decided to do that
(without having skills for a bugfix) he should add himself to "Assigned
to", what shows other users that currently here no other action is
required (what helps to avoid double expensive work on the same thing).

BTW: I do not believe that we need documented soliloquies like in Bug
Bug 47521, SCNR to leave a witty comment ;-)

So I suggest proceeding:
- only set Status NEEDINFO with text request in comment, but without
   assignation to reporter
- if info is required not from reporter ad "infoprovider" key word.
- amend Wiki

@Nino: Thank you for the hint concerning inconsistence in manuals and
proceeding.



Best regards


Rainer


Hyperlinks:
[1]
<https://bugs.freedesktop.org/buglist.cgi?list_id=67517&emailtype1=notequals&emailassigned_to1=1&query_format=advanced&bug_status=NEEDINFO&email1=libreoffice-bugs%40lists.freedesktop.org&product=LibreOffice>

[2]
<https://bugs.freedesktop.org/buglist.cgi?chfieldto=2011-12-23&chfield=bug_status&emailassigned_to1=1&query_format=advanced&chfieldfrom=2010-01-01&list_id=67523&chfieldvalue=NEEDINFO&bug_status=NEEDINFO&email1=libreoffice-bugs%40lists.freedesktop.org&product=LibreOffice&emailtype1=notequals>
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

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
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Bjoern Michaelsen schrieb:

> Assignee is and has always been the guy who "owns" the bug.


Hi Björn,

That's something to what I might agree. But when I ask John Doe to
contribute some more information, I (QA) remain "owner". But that are
quibbles.

 > This is how ~every other open source project manages ...
Can you provide evidence?

I contributed to Mozilla, OOo, Wikipedia, Libreoffice and casual other
projects, I never saw that as an established proceeding.

I did a query in bugzilla.mozilla.org over the last 60 days, in the
15000 Bugs I saw 3000 where Reporter and Assignee are identical, in a 10
items sample I only saw cases like
<https://bugzilla.mozilla.org/show_bug.cgi?id=745686> where the reporter
seems to be the one who will do the fix himselv (at least the comments
look as if). I did not see something like a NEEDINFO comment in my sample.

Please contribute evidence for your statements!

And even our developers and other experienced TDF members until now did
not proceed the way you suggest, as my queries from my last mail show.

Of course, that means nothing, may be we can improve proceeding, so my
simple question is: What is the provable "real" benefit for the workflow
we get of putting reporter into "Assigned to" together with instead of
not doing so, and what are the disadvantages of that proceeding.

For my personal workflow I do not see any benefit.

But I see disadvantages:
a) That makes the "Assigned To" field useless for many queries, in lots
of bugs it contains names nobody knows. I often use default assignee in
queries, with the new proceeding I will have to add rules related to
NEEDINFO status. Currently I do not remember a query where there should
that not be done easily, but you never know.

b) Bugzilla help might worry reporter. "The person in charge of
resolving the bug", does that mean he will have to pay a fine if he does
not "resolve the bug?" ;-)

c) If a developer Assignee needs additional info, should he reassign the
Bug to the reporter, so that we will have to check the history who might
be "really" fixing the bug?

d) Requires additional rules for dashboard handling, we should "keep it
simple". The less we use the dashboard, the less we have to write rules,
answer questions, correct operating errors, ... .

Everything we change should have apparent benefit.

Without clear approval other key players for your suggestion and
conclusive evidence of benefits I disagree with your suggestions.

Best regards

Rainer


Hyperlinks:
[1]
<https://bugzilla.mozilla.org/buglist.cgi?chfieldto=Now;chfield=[Bug%20creation];query_format=advanced;chfieldfrom=-60d>
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Rainer Bielefeld wrote (22-04-12 08:14)

> we should "keep it simple". The less we use the dashboard, the less we have to write rules,

Ah yes. As regular submitter / incidental triager, I do hardly pay
attention to rules that are not clear from the page in BugZilla. I'll
remember only ones that I see/read often, but hardly spent/have time for
study the rules.


--
  - Cor
  - http://nl.libreoffice.org

_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi Rainer,

you miss some of the most important community mechanics at work here. See
comments below.

On Sun, Apr 22, 2012 at 08:14:47AM +0200, Rainer Bielefeld wrote:
> That's something to what I might agree. But when I ask John Doe to
> contribute some more information, I (QA) remain "owner". But that
> are quibbles.

No, this is quite important and not quibbles. QA is having a very heavy
workload and we need to spread responsibilities, because:
a) we need QA(*) keyplayers and esp. you for the big picture
b) we need to trust contributors (that includes reporters) to do their part,
   not only so that we have the more skilled contributors being able to have
   time to keep an overview, but also as this is empowering them. You need to
   give people a chance to do their part -- that way you will grow the
   community and engage contributors into the project.

> I did a query in bugzilla.mozilla.org over the last 60 days, in the
> 15000 Bugs I saw 3000 where Reporter and Assignee are identical, ...

Thats ~20% of the bugs, so a very common mem.

> b) Bugzilla help might worry reporter. "The person in charge of
> resolving the bug", does that mean he will have to pay a fine if he
> does not "resolve the bug?" ;-)

_This_. Thats not a disadvantage. Its an advantage. It challenges the reporter
to get into action. Even if he has the feeling too much is asked from him, he
will do want he can and then state that he cant provide more. If that bug is
then picked up with a "thank you very much this is all we needed to push this
forward" he will be relieved and feel empowered (thinking "that was easy") and
motivated to continue contributing.

TDF/LibreOffice is a meritocraty. We are there for the people who get things
done, not to comfort those that conplain without contributing.

> c) If a developer Assignee needs additional info, should he reassign
> the Bug to the reporter, so that we will have to check the history
> who might be "really" fixing the bug?

Well, I as a dev do this usually in a two stage approach: I first just post a
comment: "@Reporter: Could you tell me, if I need foo or bar?" without changing
assignee etc. For most cases that already gets me the info I need.
If nothing happened after ~1 week, I will change the assignee to reporter, cc
myself if not already and comment "@Reporter: I cant proceed without the
foo/bar info.  Please provide it and assign the bug back to me". That usually
gets you the info very fast as:
a) the reporter already feels guilty about not answering the first time
b) he might feel a bit uncomfortable being the assignee, but providing the info
   gives him an easy way out. And being allowed (or even told) to assign a bug to
   a developer is usually very motivating for reporters -- making him feel
   great and empowered.

If he forgets to reassign, but provides the info this will not go unnoticed as
I (the dev) still is on CC.

tl;dr: This approach in the long run gets more people involved and motivated,
helping us to keep our keyplayer (like you) for the important stuff.  Yes, you
have to trust people more than we do now -- that is the way to empowerment will
make some of them contributors, growing our QA community. That is what we
really need to aim for.

Best,

Bjoern

(*) You should never think of QA as "I", even if it sometimes feels that way:
    It will be a selffulfilling prophecy and hamper community growth.
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi Guys,

can we have a decision in this matter?

Do we/you need more information/ more time - or is it just different heart
feelings?

Shall we make an operational tradeoff by defining a test period of, say, one
year?

For me, the matter itself is not that important, I can arrange with both
procedures, but I'd really like to test Bjoerns hypothesis of community
empowerment ;-)

So, please, for meritocratic reasons, Bjoern and Rainer, I believe it's up to
you to decide. (Or is ESC or whatever tdf Board the right gremium? I don't
know)

Thanks,
Nino
PS - just one thing:

> (*) You should never think of QA as "I", even if it sometimes feels that
> way: It will be a selffulfilling prophecy and hamper community growth.

or - to say it positive: Think of QA as
* qualified constructive feedback for the devs and
* important contribution to enhance and sustain quality and thus acceptance of
the software
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Nino Novak píše v Út 24. 04. 2012 v 12:14 +0200:
> Hi Guys,
>
> can we have a decision in this matter?

> So, please, for meritocratic reasons, Bjoern and Rainer, I believe it's up to
> you to decide. (Or is ESC or whatever tdf Board the right gremium? I don't
> know)

There is strong conflicting opinion between Bjoern and Rainer. I suggest
to decide this on the ESC or QA meeting.


My personal view is the following:

I think that both Bjoern and Rainer have good points. I see Bjoern's
view as too idealistic. I prefer to keep it as is because:

        + to much shuffling with many fields just cause extra work and
          complicated processes
        + people, forget to set other fields, e.g. version,
          architecture; we can't expect that will set assigned filed
          correctly; it might be intuitive but people are just lazy
        + I havn't seen any confusion about who is the needinfo
          provider, so I do not see any real benefit; yes, it might
          motivate the provider but it also creates problems when she
          never provides it; IMHO, the best motivation is to close the
          bug and ask the reporter to reopen it if she provides the
          requested information
        + wrongly assigned bugs just causes confusion; typical problem
          of the ideal solution is that the bug remains assigned to QA
          when it is reopened during verification; sometimes the
          developer is not in CC


BTW: There was wrongly described Novell bugzilla. In fact, it has the
best solution, I have ever seen, for this particular problem. It has
heavily modified the interface. If you set the state NEEDEINFO, it shows
inputbox where you are forced to enter name of the infoprovider. The bug
remains assigned to the same person as it was before, so the info
provider does not need to think whom to assign the bug back. She just
removes the NEEDEINFO state by pressing a checkbox. So, the right
handling is intuitive, friendly and enforced.


Best Regards,
Petr

_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

On Tue, Apr 24, 2012 at 04:54:23PM +0200, Petr Mladek wrote:
Yes, agreed -- its easier to resolve that directly. Just in case this wasnt
obvious: no bad blood from my side -- I hope, this is shared by others.

Best,

Bjoern
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

On Tue, 2012-04-24 at 16:54 +0200, Petr Mladek wrote:
> There is strong conflicting opinion between Bjoern and Rainer. I suggest
> to decide this on the ESC or QA meeting.

        It's on the agenda.

> BTW: There was wrongly described Novell bugzilla. In fact, it has the
> best solution, I have ever seen, for this particular problem. It has
> heavily modified the interface. If you set the state NEEDEINFO, it shows
> inputbox where you are forced to enter name of the infoprovider. The bug
> remains assigned to the same person as it was before, so the info
> provider does not need to think whom to assign the bug back. She just
> removes the NEEDEINFO state by pressing a checkbox. So, the right
> handling is intuitive, friendly and enforced.

        I'd love to push this to the list of work we want done on freedesktop
bugzilla :-) hopefully someone (Bjoern?) was building a list of tasks
we'd like to contract there - openID, and this and ... ?

        ATB,

                Michael.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

On Wed, Apr 25, 2012 at 10:34:56AM +0100, Michael Meeks wrote:
Lets not jump the gun here and make that a task after discussing it on the ESC
as that might tweak stuff a bit. And no, I have no mythical hidden list of QA
tasks, what we had so far is in the open at:

 https://wiki.documentfoundation.org/QA/Easy_Hacks

(not all of it should/could be contracted, but we can easily select from those
as the list is still rather short)
Apropos short: Adding something to that list is easy: create a bug with
"EasyHack TopicQA" in whiteboard ;)

Best,

Bjoern
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/