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

On 01/21/2013 10:13 PM, Rainer Bielefeld wrote:
> 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
There are quite a few issues with these new rules, mostly due to 
limitations with FDO but also because of situations we hadn't 
considered. All of this will be discussed on Friday and we'll hopefully 
have a final procedure down.

One of the main issues is that FDO doesn't allow you to go from RESOLVED 
- WORKSFORME back to UNCONFIRMED. This is quite a large problem as our 
QA team is using WFM quite a bit more these days as we work through 
UNCONFIRMED bugs but then a user says "no no no it's still a problem! 
and then opens it back up as REOPENED", this is incorrect as REOPENED 
should only be used when a developer is assigned and has said a patch 
fixed something and then a user says "no that patch didn't fix my 
problem". Any bug that is unassigned but set to REOPENED is incorrectly 
marked -- and we're discussing how to handle these.

This being said, there may be two options:

1) Ask Tollef to enable us to use UNVERIFIED after a bug is set to REOPENED

2) Ask use to change to NEEDINFO and then to UNVERIFIED - hassle

3) Something else that I haven't thought about

The current procedure is definitely in need of further update.


Thanks for the feedback.


Best Regards,
Joel