Hi :) I was trying to postulate a possible reason why we sometimes get such extremely hostile reactions, or at best total apathy from devs sometimes. It's more about perception than reality.
Most of what normal users would call a bug is something that the devs would call something else. In order to get their support rather than their apathy or rejection then we need to start figuring out what words they would use and how they would expect it to be handled. I think that a lot of times we should be suggesting people post what they see as bugs as "feature requests", including when a feature that has been running successfully for years gets broken! To me that is upside-down. It should be the techie people that make things easier for the normal end-users rather than the other way around. However we hit a brick-wall that way Regards from Tom :) On 23 November 2014 at 23:44, Paul <paulste...@afrihost.co.za> wrote: > On Sun, 23 Nov 2014 23:30:43 +0100 > Andreas Säger <ville...@t-online.de> wrote: > > > Am 23.11.2014 um 18:14 schrieb Rob Jasper: > > > > > > Problems in defect reporting: > > > 1- Qualification of type (A bug is unexpected behaviour which does > > > not comply to the requirements; An enhancement request is new > > > development which changes both requirements and code) > > > > > > Unexpected behaviour is a bug when it was unexpected by the > > programmer. In the eyes of a user, some program may do weird and > > unexpected things but if it does the exact weird things that it has > > been programmed for then there is no bug. > > Tell that to my clients :) > > I can assure you that if a program, while acting exactly as I intended > it to when I coded it, does not do what the spec requires it to, then > the client calls it a bug, and expects me to fix it. And rightly so. > > Of course, with LO the situation is a little different, due to the lack > of a formal client and thus a formal requirements document. If a > feature doesn't work as expected by the users, but does work as > expected by the developer who implemented it, then perhaps calling it a > bug is incorrect. Instead it is merely a feature that was implemented > in a manner that proved not to be useful. It's also not an enhancement > request, really. It all comes down to what is taken as the requirement > of the feature. If the feature started life as an enhancement request, > then that, if it is complete in this regard, will be the requirement. > > If I, as a user, were logging a ticket for a feature that didn't work > the way I expected, and there was no original enhancement request or > clear feature specification, my choice of ticket type would depend on my > understanding of the feature. If I understood where the developer was > coming from, but had a different opinion of how the feature should > work, or desired an alternative implementation alongside the existing > one, I would log the ticket as an enhancement request. But if I felt > the feature should work differently, and working the way the developer > had coded it was incorrect in my opinion, then I would log it as a bug. > It would be up to those in charge of such matters to determine which > way they felt was correct, and to either fix the bug, or close the > ticket. > > -- > To unsubscribe e-mail to: users+unsubscr...@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 > > -- To unsubscribe e-mail to: users+unsubscr...@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
