[Libreoffice] minutes of ESC call ...

Bjoern Michaelsen bjoern.michaelsen at canonical.com
Wed Sep 21 16:45:22 UTC 2016


On Wed, Sep 21, 2016 at 11:33:28AM +0200, Cor Nouws wrote:
> And then when the bug status also support QA work, more bugs will be
> well triaged and clean, and easy to pick and understand by developers ;)
> So both are valid.
> And what I read from Árons mail: just New is not enough for QA to see
> that a bug is properly triaged.

Well, my point is if we make that an explicit requirement (e.g. "properly
triaged bugs need to be checked for if they are crossplatform or appear on just
one") the net effects will be that devs dont yet look at the issue as it is not
properly triaged. However, platformdependant bugs are common enough that we can
optimistically assume a bug to be crossplatform by default without too much
hurt. If that assumption fails (rarely), a sane dev will notice they cant
reproduce, mention in a comment, move it to NEEDINFO asking to be better
triaged and move on.

> I bet you that there are many many bugs confirmed and set to New, to
> keep the number of unconfirmed low, but where no or hardly any real
> triage has been done.

As long as devs are not complaining, I think this is ok. FWIW, if I run in a
interesting undertriaged bug, I:
- give it a try with whatever info is there
- triage what I need in addition, but only when I feel like it
- if Im not interested the in the needed additional info, I explicitly state
  what I miss in a comment, put it back to NEEDINFO and move on.

> Nice challenge to find those and make sure the information in the
> reports is used at it's best.

Not all triage info is needed for devs in all cases. Good triage improves
chances of a bug being picked up by a dev in general, but that is not a binary
"triaged"/"not triaged" thing. Making every bug perfectly triaged on every
detail before a dev sees it will waste resources, while just giving devs the
freedom to push issues back quickly to NEEDINFO with specific details on what
exactly they would like to know beyond basic triage makes for a much more
targeted triage.

Of course, to have a specific issues that somebody cares about being fixed,
providing as much triage upfront before even explicitly requested by a dev is
still an excellent strategy[1]. This is because I (and I assume others too)
look at bibisected bugs a lot more often and longer than at other regressions,
and at regressions a lot longer than at other confirmed bugs, etc.



[1] Still no guarantees on being solved by volunteers obviously.

More information about the LibreOffice mailing list