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

Thanks for your comments.  What still remains unclear to me (not that it 
matters as I have no influence/authority on anything done by anyone  - 
I'm simply trying to help you all sort it out so somebody in a position 
to do something can then do it) is whether the bug status was changed in 
that 5 month period between when you re-confirmed the bug, and when it 
was closed.

In other words, did it get changed from NEEDINFO to NEW when you 
reconfirmed the bug, as was implied should have happened?  Or did it go 
from NEEDINFO to CLOSED with no intervening status?  If the latter, then 
in my opinion there's a bug in bugzilla as (I would think) it should 
have changed when you reconfirmed the bug.  If the former, then there's 
a problem with the process, not the tool.  The answers to those 
questions will answer the question "which one needs fixing?"  If the 
process needs fixing, then in my opinion there needs to be additional 
status flags and additional feedback from the developers as I previously 
wrote.

Based on Florien's post, it sounds like he only closed those that were 
in the NEEDINFO state, which implies there's a bug in bugzilla as I 
state above.


On 8/15/2012 2:18 PM, Marc Grober wrote:
> 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


--

Andrew Brager

Green Gold Capital & Real Estate

Bakersfield, CA 93307

661 412 3304

PPP starting at 1M; FC Bank Instruments; Loan Takeovers; Note 
Purchasing; Purchase of Historic Chinese & Mexican Bonds;

/DISCLAIMER: Sender is NOT a Securities Dealer or US Investment Adviser. 
Sender makes no warranties or representations. This message contains 
confidential information and is intended only for the individual named. 
If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately by 
e-mail if you have received this e-mail by mistake and delete this 
e-mail from your system./

/IMPORTANT NOTICE: This is an unofficial response to a request for 
information from the intended party, and/or a private, proprietary, 
legally privileged confidential communication and is for information or 
educational purposes only. Any other disclosure, reproduction, 
transmission, or use of this message or the files attached is 
prohibited. If you are not the intended recipient, be aware that 
interception of e-mail is a crime under the Electronic Communications 
Privacy Act, 18 U.S.C. 2510-2521 and 2701-2709. If you have received 
this in error, please immediately notify us by return e-mail, fax and/or 
telephone and destroy this transmission and its attachments without 
reading or saving in any manner. This communication and any files 
included in the message are considered a trade secret as defined by H.R. 
3723 that was signed by the President of the USA on October 11, 1996 and 
is not to be redistributed under any circumstances. This message 
includes information from sources believed to be accurate and reliable 
as of the date of dissemination but, in some cases, no independent 
verification has been made and its accuracy and completeness cannot be 
guaranteed. Stated terms, conditions and information are subject to 
change without notice. Information VOID where prohibited by law. This is 
not intended to be, and must not be construed to be in any form or 
manner as a solicitation of investment funds, a securities offering, or 
a request to engage in any transaction involving the purchase or sale of 
financial instruments. Nothing in this message should be interpreted as 
a digital or electronic signature that can be used to authenticate a 
contract or other legal document. Any statements made herein should not 
be construed in any way as advice or commitment. The author is not a 
licensed broker/dealer, registered financial adviser, attorney or 
accountant, and strongly recommends any prospective party intending to 
participate in any financial transaction seek competent independent 
review and professional counsel prior to engaging in such activity. 
Although this message and any attachments are believed to be free of any 
virus or other defect that might affect any computer system into which 
it is received and opened, it is the responsibility of the recipient to 
ensure that it is virus free, and no responsibility is accepted by this 
firm or individual for any loss or damage arising in any way from its use./


--
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