[Libreoffice-qa] minutes of ESC call ...

[Bjoern Michaelsen]

Hi,

On Tue, Sep 20, 2016 at 12:55:59AM +0200, Áron Budea wrote:
> 
> I think it would make sense to keep needAdvice keyword unrestricted from states.
> 
> Reasons:
> - NEW doesn't always mean QA was able to reproduce the bug (if TRIAGED status
> was in place, that would), see bug 101898 for example.

NEW _should_ mean triaged for all matters. That it is not called the more
descriptive TRIAGED (like it is on e.g. launchpad) is due to historic reasons.
A bug on bugs.documentfoundation.org should be in NEW only if a developer could
start working on it. Otherwise it should be in UNCOFIRMED or NEEDINFO (as
should be for 101898: It was independently confirmed, but there still isnt a
reliable reproduction scenario that allows a developer to work on it).

In general, bug states should be a rather clear mapping to which group of
people is responsible to take it to the next step:

Bug State    | Who                       | What
--------------------------------------------------------------------------------------------------
UNCORFIRMED  | users and QA              | independantly confirm the bug
NEEDINFO     | users and QA              | triage bug to reproducation scenario the dev needs
NEW          | devs                      | fix the bug
ASSIGNED     | whoever is in assigned to | fix the bug [1]
REOPENED     | devs                      | fix the bug [2]
RESOLVED     | affected users and QA     | verify fix
VERIFIED     | releng                    | announce publication of fixed release (unused in LO)[3]
CLOSED       | -                         | dead issue

On first attempt it is ok to assume that a independantly confirmed bug is
triaged and can go to NEW. However, if a dev cannot go on fixing with what is
provided, it will go back to NEEDINFO.

> My suggestion is to name it something like needsDevAdvice, remove if advice
> was given, keyword was used unnecessarily or report got closed. It should
> still be used very conservatively, of course.

Yeah maybe[4]. Or needsDevTriage. Essentially this keyword means that "dev
needs to look at this issue, even though it isnt triaged" yet, marking an
explicit exception to their general guidance that the dont need to look at
UNCORFIRMED or NEEDINFO bugs (yet).

Please consider renaming keywords for esthetic reasons reasons carefully
though: Even a ninja-edit, which not creating email, adds noise to the issues
and makes it more likely a developer will give up on an issue for having to
much noise and distraction.

> What is the problem here? Is a proposed easy hack fundamentally different from an easy hack that
> lacks necessary details? Both are for the same people: the developers who have understanding of
> the relevant pieces of code.

The difference is that a 'easy hack that lacks necessary detail' was already
considered by a dev to really be easy enough. This might not at all be true for
a 'proposed easy hack'.

> What is the workflow if I see a bug report that might be easy enough to be an easy hack, but I have
> zero knowledge about the underlying code? 

In general, I dont think we lack easy hacks. The bottle neck is still mentoring
power. So as long as we dont run out of easy hack or the existing one are
stalling because nobody want to take them on, we dont have an urgent need for
new 'proposed easy hacks' anyway -- unless they come from a dev, because _that_
implies commitment to mentor the issue.

Best,

Bjoern

[1] effectively mostly irrelevant bug state, exists for historic reasons, de
    facto the same as NEW
[2] realistically, only devs that take ownership of a bug should REOPEN.
    Everyone else is much better served with filing a follow-up bug as finding a
    dev to fix a new bug cleaning stating what was missing is much easier that
    finding a dev for a bug that has a 50-comment discussion with lots of dead ends
    inbetween.
[3] And mostly redundant as the commit bot already announces the releases that
    will have a fix. Could be implemented with a bot though trivially, I guess.
[4] "There are only two hard things in Computer Science: cache invalidation,
    naming things and off-by-one errors."