Re: [libreoffice-users] Re: Excuse me, but your opinion is simply unimportant. Start over and you can expect more of the same.

I was curious as to what the commotion on this subject was so I looked 
at the bug submitted wherein I found the automated message:

   Björn Michaelsen 2011-12-23 12:27:51 UTC
   [This is an automated message.]
   This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
   started right out as NEW without ever being explicitly confirmed.
   The bug is
   changed to state NEEDINFO for this reason. To move this bug from
   NEEDINFO back
   to NEW please check if the bug still persists with the 3.5.0 beta1
   or beta2
   prereleases.
   Details on how to test the 3.5.0 beta1 can be found at:
   http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

   more detail on this bulk operation:
   http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html


Seems pretty clear to me.  In fact, if one actually goes to the trouble 
of clicking on the bulk operation link, one finds complete information 
regarding what was done and why.  To make it more convenient for you 
all, I present a portion of the information here:

> here is an urgent request for comments. We still have ~2400 bugs in 
> state NEW
> from the pre-Bugzilla 4.0 days. Back then we had no initial state 
> UNCONFIRMED,
> so unfortunately they started with NEW. This is changed now for new 
> bugs, but
> the old ones are still in state NEW because we did not want to spam the
> subscribers of 2400 bugs just by changing those bugs. This leaves us 
> in the
> unfortunate situation to having to check dates etc. to see what the 
> status
> really means, which is really bad.
>
> So here is my proposal: I want to batch change all those old 
> unconfirmed bugs
> (without the now obsolete CONFIRMED in whiteboard status) to state 
> NEEDINFO.
> We can then be sure that a bug in state NEW is actually confirmed. 
> This is
> urgent, because I think we have a good opportunity right now.
> I want to do the bulk change with this comment:
>
> [This is an automated message.]
> This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
> started right out as NEW without ever being explicitly confirmed. The 
> bug is
> changed to state NEEDINFO for this reason. To move this bug from 
> NEEDINFO back
> to NEW please check if the bug still persists with the 3.5.0 beta1 
> prerelease.
> Details on how to test the 3.5.0 beta1 can be found at:
> http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1
>
> By doing this, we would:
>  a) get our bug data consistent (all NEW bug would have basic 
> confirmation)
>  b) lure a lot more people into participating in the beta1 bug hunt
>  c) do so without spamming a lot of people in vain.
>  d) could get rid of the confusing UNCONFIRMED,CONFIRMED tags in 
> whiteboard status
>
> To be effective for the bug hunting session this would have to be done 
> rather
> fast. Thus, if nobody vetos this, I would do that tommorrow in ~500 bug
> batches.
>
> Objections? Vetos? Comments?
>
> Best,
>
> Bjoern
This at least provides the history of how things got from there to here 
and so could help provide a better understanding.

I do agree that there needs to be better information regarding how to 
change the status, as it's unclear (to me at least) how the status got 
changed to "RESOLVED INVALID", other than the fact that Leif stated very 
clearly in this particular bug:

> _Not actually a bug _but more an easy improvement to the user interface.

Perhaps that's the reason it became "invalid".  I'm simply guessing.

It would seem any perceived problems stem from Bugzilla and attempts to 
make improvements to the bug fixing process.  Where it may have broken 
down is in the uncertain area of what happened when Leif responded to 
the NEEDINFO request.  The question becomes, did Bugzilla change the 
status to NEW as Bjoern implies would happen and then a developer 
further changed the status to RESOLVED INVALID?  If so, then perhaps 
that particular status needs better detail from the developer (or QA) as 
Leif requests - something like "Not a bug, but an enhancement request".  
And then perhaps a pointer to how to submit enhancement requests.  To 
me, a better status message would have simply been "ENHANCEMENT REQUEST" 
and then left in that state as an open request rather than "RESOLVED".  
That way developers could easily find such requests.

Obviously I'd have to look at each individual bug to see if these 
comments apply, but since Andreas stated in another post that this bug 
was...
> The perfect example for what went wrong here. Someone tagged it 
> blindly as "NEEDINFO" although the request for improvement is 
> perfectly clear even for me who never used Impress for anything but 
> viewing. 
... I thought I'd take a look at "the perfect example".  We now see why 
it was "tagged blindly".


Leif is perfectly right when he states:

> Half the problem is communication. If the process has been more clear 
> and accurate it wouldn't have been a problem. Why not explain the 
> process and the reason for closing these issues? Why not explain what 
> it means that the issue has been closed? Why not explain what the 
> owner could do to re-invoke the issue? Why not find another status 
> that "RESOLVED INVALID".

In essence, it seems that the developers were in a tight spot and lacked 
enough input from the user base to make good decisions.  It looks like 
they are now getting that info. from this discussion - hopefully they're 
paying attention to it.

I'm just trying to provide some objective perspective.  I hope I've helped.


On 8/15/2012 11:05 AM, leif wrote:
> Hi Stuart,
> I agree that when we report bug we should do what we can to supply as 
> much information as possible. The problem here - from my point of view 
> - is that a lot of issues was marked as NEEDINFO by mistake. I have at 
> least one (and its my impression that there are more) that doesn't 
> need any info. All it needs is a little attention from the QA/devs.
>
> I have posted some issues over time but I don't think I will bother in 
> the future. My time seems to be not appreciated?
>
> https://bugs.freedesktop.org/show_bug.cgi?id=39523
>
> The bug has never been commented by humans and all later activity was 
> automated (except the once from my hand).
>
> If QA and dev groups think this approach is the right way to go then I 
> am afraid that we will have huge difficulties finding new 
> non-programmers participate in the QA-process.
>
> Half the problem is communication. If the process has been more clear 
> and accurate it wouldn't have been a problem. Why not explain the 
> process and the reason for closing these issues? Why not explain what 
> it means that the issue has been closed? Why not explain what the 
> owner could do to re-invoke the issue? Why not find another status 
> that "RESOLVED INVALID". These issues are not resolved nor invalid.
>
> i try to encourage people to submit issues if they have problems. I 
> also try teach them to give enough information. But some are not very 
> good at English and others are not very technical minded. These 
> "amateurs" got scarred and will stay away in the future. That is not 
> what we need at current. We need to embrace and encourage - not scare 
> away.
>
> Cheers,
> Leif
>
>
>
>
> On 15-08-2012 19:20, V Stuart Foote wrote:
> > Yes the apology was issued over on the Dev and QA lists--inserted below.
> > But we folks on the QA and User side do have a responsibility to 
> > follow our
> > bugs when posted, and to participate when calls for NEEDINFO are 
> > issued. And
> > also, that when bugs are closed we reopen them with careful attention 
> > to the
> > information needed to fully describe the bug and the quality of 
> > detail the
> > Devs will needs to resolve.
> >
> > Otherwise, let's move on folks!
> >
> > Stuart


--
For unsubscribe instructions e-mail to: users+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted