Yes and no..... The initial news about bug tracker issues went out in March. Many responded, as did I, updating the bug to confirm that it was still a bug.... In fact, at the time I specifically asked why we needed to confirm the bug if in fact the bug was long stnding and nothing had been done by developers about the resolution suggested. The response was a thank you for updating.
THEN, 5 MONTHS LATER, we received post facto notice that the bug had been closed, an across the board second effort to change bug status without regard to anything that had been done in March. The March notice re 'my' bug was in fact bogus, because the bug was documented very well, and status was simply not changed because no dev took the time to address the bug. On 8/15/12 12:54 PM, Andrew Brager wrote: > > 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: [email protected] 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
