[Libreoffice-qa] Bug Triage Process Update

[Petr Mladek]

Rainer Bielefeld píše v Út 08. 11. 2011 v 20:17 +0100:
> > It looked like the step 3 from the Bug Triage process.
> 
> More or less. But explications on that page and others are too 
> "businesslike". We should show interested new users that it's really 
> simple and no special skills (except some carefulness) are required. But 
> currently BugTriage Page is ok, we should create a more elaborated and 
> inviting introduction on a different page.

I fully agree. I have already started some changes. Please, see the current main QA
http://wiki.documentfoundation.org/QA. I have made it pretty simple. My
idea was to make it encouraging and allow to easy to find where people
could help.

It points to pages like
https://wiki.documentfoundation.org/QA/Testing/Regression_Tests. This
page gives more detailed introduction about what the job is about. Then
it describes practical steps how to do it.

IMHO, we need simple or well structured pages to do not scare people.
The real process must be described in few steps. These steps must be
easy to find from the main QA page. If anything needs extra elaboration,
we should describe it in extra page or section and just make a link. 

Feel free to improve the pages. I like your fluent sentences, for
example at http://wiki.documentfoundation.org/QA-Projects-Incubator So,
I am looking forward to see your input :-)


> > Do we really want to triage bugs in the state NEW or ASSIGNED?
> 
> No, that's nonsense, of course.

Ok, I updated the query. Removed check for NEW, ASSIGNED and prolonged
it to two weeks. It gives more than 160 bugs, so it is quite enough. Of
course, your query mentioned below will be better. Well, the list of
all unconfirmed bugs might be a bit scary ;-)


> A first draft showing what kind of bugs 
> need Review you find here:
> <https://wiki.documentfoundation.org/images/1/1b/BugsNeedingReview.svg>
> 
> more detailed explication and matching query coming soon.

I really like your systematic approach! Maybe, I should wait for the
explanation but I can't resist :-)

I understand the picture that it describes conditions when you need to
review a bug.

1. What do you mean with the CC: QA-member, CC: developer, ... bubble?

   People in CC want to watch the bug. It does not says if they are
   able to confirm it or not. So, I would remove any CC from the condition.


2. Whiteboard does not mention CONFIRMED

   This should be needed only for bugs reported before 1011-Nov. I
   prefer to keep the process intuitive, so we should remove this
   extra step for new bugs. Nobody would know about this Whiteboard
   stuff without reading documentation.


3. I would take care of the NEEDINFO state only when there was no
   comment last 4 weeks. It requires information from a particular
   person, so others need not spend time on it.

   The situation is different if the information is not provided
   within one month. In this case I suggest to close the bug with
   some friendly message, for example:

   "We are sorry but we could not solve this bug without the requested
    information. Feel free to reopen it with the provided answer."

   We use this in openSUSE and it works quite well. Non-interesting bugs
   stay closed. The interesting bugs move forward.

Otherwise, it makes perfect sense.


> Until End of week I will star (no, I hope that I will be able to start) 
> Some Wiki-Pages:
> 
> - User-QA (Who we are, what we do)
>   - How we get a report "ready for Developers needs"
>   - how everybody can contribute
>    - bug reporting
>    - bug triage

Take your time. Just to be sure. Do you want to start new pages? I
would prefer to clean up the existing pages:
http://wiki.documentfoundation.org/QA
http://wiki.documentfoundation.org/BugReport
http://wiki.documentfoundation.org/BugTriage

Otherwise people will be lost in the many pages :-)


> > Do we still need to put CONFIRMED to the Whiteboard?
> > IMHO, the bug is confirmed when the status is not UNCONFIRMED.
> 
> No, we should change that, please see a.m. Query picture draft. We have 
> approximately 2000 old NEW bugs where the main differentiation between 
> those who need review and those what do not. Changing proceeding will 
> need some preparation

You are right. I would solve this with an extra query for the older bugs
and use the easier approach for new bugs.

IMHO, people mostly triage only recent bugs. The old mess could be
fixed only by special actions, e.g. during your bug hunting sessions.

By other words, I think that we do not need preparation. We will be
able to find unconfirmed bugs in the stable NEW even later (bugs
created before Nov 2011, and (not assigned or Whiteboard does not mention
CONFIRMED)).


> > 5. NEEDINFO handling:
> 
> Yes, Currently I also think we should use the status for incomplete bug 
> reports, where info is required from reporter. The key word can be used 
> for other needs. But also here we have lots of bugs with key word 
> Needinfo, and a change is simple, but causes lots and lots of Mails, so 
> I am thinking about a slow "phasing out". But at least for me that's not 
> an important search criterion, we can switch immediately

OK, I updated the wiki page. It suggests using the status "NEEDINFO"
instead of the keyword now.

We might do the clean up during a bug hunting session and close
outdated NEEDINFO bugs as suggested above.


> > I am not sure if the is a good idea to assign all bugs to the few people
> > on the http://wiki.documentfoundation.org/FindTheExpert page.
> 
> That's something developers have to handle. As long as nobody else is 
> known bugs will be assigned to those few people. Currently I see that 
> working very well for Calc with Kohei and Markus, they get managed that 
> problem "somehow".

I do not understand how Kohei and Marcus do it effectively :-)

> But for futere may be Component related mailing lists 
> as "pre-assignees" may be a better solution (your suggestion 1). 
> Develpers busy in that area can subscribe "their" lists to be up to date 
> concerning bugs that passed QA review. Your suggestion 1 seems to be the 
> most clear and simple soulution.

I agree. Let's leave it as is until the affected developers complain.

Thanks a lot for input and your great work.


Best Regards,
Petr