[Libreoffice-qa] Minutes - QA Call 01/11/2013

[Rainer Bielefeld]

Joel Madero schrieb:

> -Status clarification (New vs. Reopened)
> **Agreed: *Reopened should only be used if the bug is assigned
> *Because of this agreement, modifications have to be made to our current
> workflow
> -*Agreed: *NEEDINFO: Used only if most the information

Hi all,

just stumbled upon these minutes.

Most of these decisions are changes of proceeding negotiated in the 
past, and so the Wiki should be amended to these changes.

With some results I agree, may some fine tuning still is possible. So I 
agree that it's appropriate to mark a report INVALID if nearby no useful 
info is included (as stated in the minutes). For a NEEDINFO I do not 
believe that "Most necessary info" has to be included. For me a 
"promising start" seems enough reason to keep a bug open with NEEDINFO. 
May be we can find and write down some indications for "promising", but 
most is a matter or instinct to decide whether there is hope

Concerning the rest, to be honest, with current knowledge I don't 
understand most of that what I read because I nowhere see a "because 
...". What were the problems that should be solved with the decisions?

I am afraid that the new definitions will no longer allow reliable queries.

An example:
In this
<http://www.bugzilla.org/docs/3.6/en/html/lifecycle.html>
graph, what was base of former decisions, NEW meant all necessary has 
been gained, QA work is done, developers can start their work. So no 
need for me to have a look. I think that was a useful usage of Status NEW.

Due to agreed items now NEW should be selected immediately if someone 
who is more or less reliable has reported or confirmed a real bug.

I saw Joel changing Status of several bugs I reported from UNCONFIRMED 
to NEW without any additional contribution of information. Thank you for 
trusting my  reports, but I have good reasons NOT to use NEW at once: I 
think that additional information should be added, may be I want to do 
further research, may be I would like to see whether the problem is 
limited to my OS ....

The result of the new proceeding is that nobody can know whether more 
info is necessary or at least might be useful (Other OS? Particular 
conditions / settings / Desktop integration / ...? Where did that 
problem start? Are there relations to other bugs what should be 
checked?). There are good reasons to follow the "2 man rule"
<http://en.wikipedia.org/wiki/Two-man_rule>, it's not only a matter of 
confirmation, the reviewer should add information from his point of view.

I'm sorry, to me that looks a little helter skelter. A more promising 
way to develop the proceedings would be to list existing problems and 
suggestions for solutions on the wiki discussion pages like 
<https://wiki.documentfoundation.org/Talk:QA/BugTriage> and then to 
improve the proceeding rules step by step with parallel discussion on 
qa-list.

CU

Rainer