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

classic Classic list List threaded Threaded
51 messages Options
Next » 123
marcgrober marcgrober
Reply | Threaded
Open this post in threaded view
|

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


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.

> Dear bug submitter!
> Due to the fact, that there are a lot of NEEDINFO bugs with no answer within
> the last six months, we close all of these bugs.
> To keep this message short, more infos are available @
> https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement
> Thanks for understanding and hopefully updating your bug, so that everything is
> prepared for developers to fix your problem.
> Yours!
> Florian


--
For unsubscribe instructions e-mail to: [hidden email]
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

Andreas Säger Andreas Säger
Reply | Threaded
Open this post in threaded view
|

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

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.




--
For unsubscribe instructions e-mail to: [hidden email]
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

Leif Lodahl Leif Lodahl
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by marcgrober
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


On 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.
>
> If I had the time I would go through and re-open every one of these
> simply to give Florian something to do.
>
>> Dear bug submitter!
>> Due to the fact, that there are a lot of NEEDINFO bugs with no answer within
>> the last six months, we close all of these bugs.
>> To keep this message short, more infos are available @
>> https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement
>> Thanks for understanding and hopefully updating your bug, so that everything is
>> prepared for developers to fix your problem.
>> Yours!
>> Florian
>


--
For unsubscribe instructions e-mail to: [hidden email]
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

Gordon Burgess-Parker Gordon Burgess-Parker
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Andreas Säger
On 14/08/12 21:13, Andreas Säger wrote:
> I'm going to upgrade all our production systems to AOO 3.4.1

What is "AOO"?


--
For unsubscribe instructions e-mail to: [hidden email]
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

Leif Lodahl Leif Lodahl
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Andreas Säger
2012/8/14 Andreas Säger <[hidden email]>

>
>
> +1
>
> Today I got 16 such mails.
>
>
> Hi,
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

--
For unsubscribe instructions e-mail to: [hidden email]
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

marcgrober marcgrober
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Leif Lodahl
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.

On 8/14/12 12:32 PM, leif wrote:

> 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
>
>
> On 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.
>>
>> If I had the time I would go through and re-open every one of these
>> simply to give Florian something to do.
>>
>>> Dear bug submitter!
>>> Due to the fact, that there are a lot of NEEDINFO bugs with no answer
>>> within
>>> the last six months, we close all of these bugs.
>>> To keep this message short, more infos are available @
>>> https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement
>>> Thanks for understanding and hopefully updating your bug, so that
>>> everything is
>>> prepared for developers to fix your problem.
>>> Yours!
>>> Florian
>>
>
>


--
For unsubscribe instructions e-mail to: [hidden email]
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

marcgrober marcgrober
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Andreas Säger
AOO is the apache open office.....


--
For unsubscribe instructions e-mail to: [hidden email]
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

Andreas Säger Andreas Säger
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Gordon Burgess-Parker
Gordon Burgess-Parker wrote
On 14/08/12 21:13, Andreas Säger wrote:
> I'm going to upgrade all our production systems to AOO 3.4.1

What is "AOO"?
http://lmgtfy.com/?q=AOO
jmadero jmadero
Reply | Threaded
Open this post in threaded view
|

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

This post has NOT been accepted by the mailing list yet.
I would like to apologize on behalf of myself and the QA team. I was one of the ones involved with this and I guess we jumped the gun and didn't think things through clearly. I'm sure Florian is sorry and we should have waited for more input....at times input can take weeks if not longer and on the QA side it can become frustrating. The bugs that were closed were (as far as I know) ones that we had specifically requested more information and they were just languishing in NEEDINFO status. This was in NO WAY meant to say we don't care, more as a way to organize the bugs in a better manner as it was voiced by at least one other person (going to avoid names) that marking NEEDINFO and not getting a response from the bug reporter or anyone else for weeks or months wasn't very useful either. This isn't justifying the decision at all and again I am sorry. I thought that it would be more useful to have the bugs marked as INVALID after weeks/months of inactivity in NEEDINFO status than to just leave them in the status and make it harder for us to really know what's a current bug and what's just a bug that was reported 5 months ago but the user didn't provide all the information that we needed.

I am open for suggestions as to how we can handle this and welcome any emails direct to me (jmadero.dev@gmail.com) or through nabble. Also, I ask anyone who has a bit of time (really only a bit) to actively participate in the QA team's activities so that we can continue moving forward and making LibreOffice the best product that it can be.

Best wishes to everyone, please aim your anger at me not at Florian or the QA team as a whole. Thanks

Joel
Thomas Taylor Thomas Taylor
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Andreas Säger
On Tue, 14 Aug 2012 22:13:01 +0200
Andreas Säger <[hidden email]> wrote:

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

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

--
“What we do for ourselves dies with us. What we do for others and the
world remains and is immortal.”  Albert Pine
--
Tom Taylor - retired penguin
AMD Phenom II x4 955 -- 4GB RAM -- 2x1.5TB sata2
openSUSE 12.1x86_64    openSUSE 12.2x86_64
KDE 4.7.2, FF 7.0      KDE 4.8.4, FF 13.0
claws-mail 3.8.0
registered linux user 263467
linxt-At-comcast-DoT-net

--
For unsubscribe instructions e-mail to: [hidden email]
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
Andreas Säger Andreas Säger
Reply | Threaded
Open this post in threaded view
|

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

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



--
For unsubscribe instructions e-mail to: [hidden email]
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
V Stuart Foote V Stuart Foote
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by marcgrober
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
Date: Tue, 14 Aug 2012 22:33:49 -0700
From: Joel Madero <jmadero.dev@gmail.com>
Subject: Bug Closing Automation - Apology

Hi All,

First off, sorry that I'm starting a new thread, I'm not sure how to "reply" to something from the digest in gmail.

A couple days ago there was a very brief discussion about NEEDINFO and that it wasn't very useful to have the NEEDINFO status sit for weeks or months on end if the users weren't responding to our requests for more information. I jumped the gun and asked if there was a way to automate closing these bugs if they were open for some period of time, another user volunteered to do this and went ahead and did it. I take full responsibility for the ill feelings, I should have waited longer for more input and thought about it more clearly before requesting if someone had the ability to automatically close these bugs. It has pissed off quite a few people, I take the blame, please direct your irritation my way and not at Florian or any other member of the QA team.

Best wishes to everyone,

Joel
Leif Lodahl Leif Lodahl
Reply | Threaded
Open this post in threaded view
|

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

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: [hidden email]
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

Andreas Säger Andreas Säger
Reply | Threaded
Open this post in threaded view
|

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

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.


--
For unsubscribe instructions e-mail to: [hidden email]
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

marcgrober marcgrober
Reply | Threaded
Open this post in threaded view
|

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

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



On 8/15/12 10:50 AM, Andreas Säger wrote:

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


--
For unsubscribe instructions e-mail to: [hidden email]
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

Andrew Brager Andrew Brager
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Leif Lodahl

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: [hidden email]
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

marcgrober marcgrober
Reply | Threaded
Open this post in threaded view
|

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

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: [hidden email]
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

Andrew Brager Andrew Brager
Reply | Threaded
Open this post in threaded view
|

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: [hidden email]
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

marcgrober marcgrober
Reply | Threaded
Open this post in threaded view
|

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

On 8/15/12 1:57 PM, Andrew Brager wrote:

> 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

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

--
For unsubscribe instructions e-mail to: [hidden email]
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

Andrew Brager Andrew Brager
Reply | Threaded
Open this post in threaded view
|

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

On 8/15/2012 3:20 PM, Marc Grober wrote:

> On 8/15/12 1:57 PM, Andrew Brager wrote:
>> 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.



--
For unsubscribe instructions e-mail to: [hidden email]
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

Next » 123