Excuse me, but your opinion is simply unimportant. Start over and you can expect more of the same.

users
#1

This (see the quote below) is simply unacceptable. In fact, with respect
to the bug on which I received this little gem quite a few people had
been at pains to clearly identify the problem and the potential
solution, and neither having changed at all, there had been no changes
to the bug report save angry responses everytime someone tried to close
it because it had not been updated. What is Florian really saying? It
would appear to be either that the product is SOOOOO buggy we have
decided to ignore all the bug reports OR that users are SOOOO stupid
that we are going to ignore all bug reports.... Thank you, Florian, for
the vote of confidence.

If I had the time I would go through and re-open every one of these
simply to give Florian something to do.

#2

Am 14.08.2012 20:48, Marc Grober wrote:

This (see the quote below) is simply unacceptable. In fact, with respect
to the bug on which I received this little gem quite a few people had
been at pains to clearly identify the problem and the potential
solution, and neither having changed at all, there had been no changes
to the bug report save angry responses everytime someone tried to close
it because it had not been updated. What is Florian really saying? It
would appear to be either that the product is SOOOOO buggy we have
decided to ignore all the bug reports OR that users are SOOOO stupid
that we are going to ignore all bug reports.... Thank you, Florian, for
the vote of confidence.

+1

Today I got 16 such mails.

LibreOffice is out of control. Everybody is free to fix things that are not broken. Like the "supporters" on this list, the QA testers do not know the software, let alone any new "features" added without specification nor investigation on side effects. Some of the QA people are not even able to run a macro to check out an issue.

I'm going to upgrade all our production systems to AOO 3.4.1 which works as expected with all the features I need.

#3

Hello Marc,

I feel the same as you. some of these bugs are not closed because they "need info" but because we need developers. We can't do much about that, but we should not behave like this to our polite bug reporters. This is not a serious way to embrace community members.

I can understand that the developers and QA team needs a better overview of bugs - but this is not the best way to deal with the problem. Perhaps better communication or something else could help, but not this approach, please.

Cheers,
Leif Lodahl

Cheers,
Leif Lodahl

#4

What is "AOO"?

#5

Yes there has been a mistake - all mails has been send four times.

The guy made a mistake and he apologized for that and I'm pretty sure he
won't do that mistake next time. Mistakes happen no matter what project you
are working with - open source or commercial. Thats not the point.

The point is that these bugs has been closed just because nobody picked
them up. Thats not fair and it will be de-motivating if this procedure is
accepted. If "the project" don't care about me spending time reporting a
bug, then I don't care about filling a bug report next time.

Cheers,
Leif

#6

Leif,

First, I may be inconsequential, but I did not see any apology.
Perhaps it only went out on the dev list.....
Second, I am not concerned about receiving multiple iterations of the
bug closing, but as you suggest, by the closing of a bug simply because
it was too much trouble to address.
Third, the bug in question in my case was not only clearly identified,
but a solution proposed months ago.
Fourth, the bug was reclassified in March because the bug tracker was
redone, requiring me to reconfirm
Fifth, then a few weeks later (end of March 2012) I was asked again to
reconfirm and I did.

While I agree that whining here is not the answer, I am at a loss as to
what else we can do other than to identify the bug, identify the code
needed, and identify the source of the needed code.

I understand that my little issue is NOT a show stopper, but I am
horrified just thinking about what other bugs were simply marked
"resolved" that may be the result of even more effort than we put in on
the little item I was involved with.

I have had my little rant, for what it is worth, and I hope that there
are some devs on this list that may take the message to heart, and that
is that.

Apologies to all.

#7

AOO is the apache open office.....

#8

Gordon Burgess-Parker wrote

I'm going to upgrade all our production systems to AOO 3.4.1

What is "AOO"?

http://lmgtfy.com/?q=AOO

#9

Hi Andreas,
I am not trying to be critical but for the last 2-3 releases no email
message was received about "NEED INFO". That had been done in earlier
releases. Is there a malfunction in the bug reporting system? My
programming days are many years behind but it seems to me an automated
tracking system should send a message to the reporter when additional
information is needed. Then if a response is not received within a
specified time-frame the report could be downgraded or closed.

Thanks, Tom

#10

Am 15.08.2012 08:03, Thomas Taylor wrote:

Hi Andreas,
I am not trying to be critical but for the last 2-3 releases no email
message was received about "NEED INFO". That had been done in earlier
releases. Is there a malfunction in the bug reporting system? My
programming days are many years behind but it seems to me an automated
tracking system should send a message to the reporter when additional
information is needed. Then if a response is not received within a
specified time-frame the report could be downgraded or closed.

Thanks, Tom

Sorry, I have no idea how to make my bug reports any clearer. Only on very rare occasions I've had this kind of problem with the OpenOffice.org QA.
One of my NEEDINFO issues has been fixed after I added a document for a most obvious bug ("most obvous" means: apply built-in feature with options and see).
Some other guy could not copy and run a Basic snippet (facepalm).
I recognize that some other bug is intended (implicit conversion of ambiguous strings).
I recognize that *any* new feature from anybody is embraced even when it comes without documentation, without API, without reason, let alone specification.
I recognize that there are plenty of resources for proprietary file formats and unapproachable VBA compatibility.

This software is like a sandheap where some people pile up more material while others inject water. To the outside world everything looks great so far ...

#11

Marc Grober wrote

First, I may be inconsequential, but I did not see any apology.
Perhaps it only went out on the dev list.....

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

Joel Madero (to the Devs and QA lists) wrote

#12

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

#13

Am 15.08.2012 20:05, leif wrote:

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

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 open an Impress window, call 2 built-in menu commands and I do not need any more info.

#14

Ditto on mine..... this was just mindless....

#15

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.

#16

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.

#17

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.

#18

I think there is another possibility, and that is that the bug lifecycle
is dubious. See, https://bugs.freedesktop.org/docs/en/html/lifecycle.html

With respect to LO bugs, it is still unclear what the various stages of
the bug lifecycle is, and who is empowered to make various changes to
the bug status. As an unempowered user I cannot "confirm" a bug.
Moreover, there is no context help available regarding status hierarchy.

What I think I am seeing, as in so many such projects, is a disconnect
between what devs think is happening and what bug reporters think is
happening.....

#19

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.

I think there is another possibility, and that is that the bug lifecycle
is dubious. See, https://bugs.freedesktop.org/docs/en/html/lifecycle.html

That diagram is in fact interesting. Based on that diagram (which may or may not be utilized by the LO team), then the process followed by the LO team is in error. They've chosen to dump unconfirmed bugs back on the user community, instead of confirming the bugs themselves. I can understand why they've done it, the work is probably overwhelming and they're volunteers so they've chosen to let each individual user/bug submitter either resubmit or assume resolved status. Not a bad choice from their point of view, it's the path of least work for them. It makes sense from that viewpoint. The proper way to do it would have been to check each bug themselves as normally would be done prior to a production release. They took the practical, expedient approach instead and I don't think you can fault them for doing so.

With respect to LO bugs, it is still unclear what the various stages of
the bug lifecycle is, and who is empowered to make various changes to
the bug status. As an unempowered user I cannot "confirm" a bug.

Nor should you be able to confirm a bug. And that of course is where the model (or process) is broken, since as I mentioned above they've dumped the testing back on the user - with decent reasoning - but it still breaks the model as provided by the diagram. So yes, somebody on the developer's side needs to make some decisions as to how best to fix the model and/or process. Personally I don't see a problem with their decision to dump the bugs back on the user considering they themselves are volunteers, but somewhere somehow the status needs to change from NEEDINFO to NEW (which is not provided for in the model so clearly things have changed either with the model as supplied by bugzilla, or the LO team has customized their copy. So, I reiterate my previous comment that more info. is needed from the bug submitters as to what stages the status flags went through to determine whether it's the process or bugzilla that needs fixing.

Moreover, there is no context help available regarding status hierarchy.

What I think I am seeing, as in so many such projects, is a disconnect
between what devs think is happening and what bug reporters think is
happening.....

I agree with your assessment. But until someone starts providing the missing info. I fear there can be no resolution. Ultimately someone from the developer's and/or administrative side of the fence needs to figure out how to resolve this to most people's satisfaction.

#20

I too would like to know.

       It's been mentioned a few times now ... someone asks what is it, yet
no one responds :wink:
           or are they responding privately ???