On Tue, 12 Nov 2013 17:55:07 -0700
Ken Springer <email@example.com> wrote:
You and John have missed my point.
Features vs. bugs is irrelevant in what I'm saying.
No, it's not. There are limited resources, and both bugs and features
compete for those resources. Because if some features are not
implemented, they get complained about just the same as if some bugs
are not fixed.
I'm asking, in the example above, do you want 50 PO'ed users, or 125
No, you're not, because your logic is faulty.
Bugs B through Z have only a handfull of people who have reported them.
So they are not serious, and even if only a small percentage of people
who came across them reported them, that's still not many people who've
come across them. Let's say 5 people reported each bug, and in total 25
people have come across said bug. That's a total of 625 potentially
slightly unhappy users.
Bug A, which 100 people reported, is either:
a) A very serious bug, which most of the people who came across it
reported. So let's say 150 people total have come across it. Fixing it
first means 625 very slightly irritated users, and 150 happy users who
otherwise would have been completely PO'ed, enough to leave and never
b) A minor bug, which only a small percentage of people reported, but
that means many, many people have come across it. Using the same ratio,
let's say 500 people are unhappy about it. Fixing it first means 625
very slightly irritated users, and 500 happy users who would otherwise
have been very slightly irritated.
Either way, pretty good odds. Case B might not be the best outcome,
but that's assuming that the figures are correct. Nobody knows for
sure what the figures are. And that's assuming that you can do all the
bugs B through Z in the same time as you can fix A. Chances are you
could only fix about half those bugs in the same time as it takes you
to fix A. If that's the case, even case B becomes favourable to fixing
bug A first. And that's leaving out all sorts of other considerations.
So all in all, it seems a bit unfair to sit there on the outside and
complain that the developers don't know what they are doing, and that
they're doing a poor job, just because you've posted a couple of bugs
that haven't been fixed in a while (and I don't know, but I'm guessing
don't have a lot of people complaining about them), while many (if not
most) other people think the system works pretty well.
LO needs to decide if they want to be successful at that level. Paid
or unpaid, that means lots of time. Period.
You're forgetting the bit where LO is already successful at that level.
So far you're a lone voice saying it isn't. I disagree, and I'm sure
others do too.
To unsubscribe e-mail to: firstname.lastname@example.org
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
[libreoffice-users] Re: Engaging users: initial results of the survey · Ken Springer
Re: [libreoffice-users] Re: Engaging users: initial results of the survey · Michael Meeks
Re: [libreoffice-website] Re: [libreoffice-users] Re: Engaging users: initial results of the survey · Robinson Tryon
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy