And now someone has jumped on my bug and changed my reporting so that it shows 
that it is only in 3.3 - that's the last straw. I will not have anything 
further to do with bug reporting. All those fine devs can choke on their bloody 
buggy product. Congratulations! You have alienated yet another volunteer.



On Aug 16, 2012, at 12:20 AM, Tom Davies <tomdavie...@yahoo.co.uk> wrote:

> Hi :)
> Interesting thought and a good diagram, thanks :)  
> 
> Something i have wondered for a while is how to utilise what this particular 
> list has to offer, perhaps confirming bug-reports could be partially done 
> through this list?
> 
> Occasionally someone new on this list expresses an interest in getting more 
> involved or somehow repaying the community.  Also this list is quite good at 
> eventually pinning-down exactly what an initial question was probably really 
> asking.  
> 
> People here generally don't have much time or experience but might be willing 
> to push a couple of buttons to see if something really doesn't work, 
> especially if it's not risky.  
> 
> Could we have a weekly report listing  unconfirmed bug-reports generated 
> during the week?  Would it be easier to have a link that listed all the 
> 'thousands' of unconfirmed bug-reports?  Is it thousands or (as i suspect) 
> much much lower?  
> 
> Ideally it would be great to have devs doing development rather than devs 
> spending time trying to work at customer-relations and guessing at what 
> people meant by certain bug-reports.  
> 
> Just my 2pence-worth
> Regards from
> Tom :)  
> 
> 
> --- On Thu, 16/8/12, Andrew Brager <apb3...@bak.rr.com> wrote:
> 
> From: Andrew Brager <apb3...@bak.rr.com>
> Subject: Re: [libreoffice-users] Re: Excuse me, but your opinion is simply 
> unimportant. Start over and you can expect more of the same.
> To: users@global.libreoffice.org
> Date: Thursday, 16 August, 2012, 1:16
> 
> 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: users+h...@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
> 
> 
> -- 
> For unsubscribe instructions e-mail to: users+h...@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
> 

-- 
For unsubscribe instructions e-mail to: users+h...@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

Reply via email to