On 11/12/13 5:51 AM, Paul wrote:
I think there's a dangerous perception here: The perception that the LO
developers work on nothing except what they want to work on.
I'm pretty sure that that is very false. They work on LO because they
want to work on LO, and they probably choose what to work on based on
at least the following:
a) How many people report a specific bug
b) How serious that bug is to people's productivity
c) How in line that bug is with current roadmaps
d) Regression bugs probably have higher priority
e) What parts of the system they know the best
f) How much time they have at the moment, and how big the bug is
g) How much fun they think it will be (or more likely, which bug will
be the least annoying to fix)
On Tue, 12 Nov 2013 04:24:03 -0800 (PST)
Pedro <firstname.lastname@example.org> wrote:
The logic that "a bug is not important because not many people report
it" has a big flaw: most people give up without bothering to
report... (and in the case of Bugzilla, reporting requires quite a
lot of effort)
This logic may not be true in an absolute sense, but consider that it's
not normally a question of how important the bug is on its own merits,
but how important the bug is compared to other bugs. If 50 people have
reported bug A and only 2 people have reported bug B, while bug B may
still be important, and there may be another 20 people who haven't
reported it, it is not as important as bug A, and there may be another
20 people who haven't reported bug A as well.
Here's the fault with this logic.
I'm going to up the number of people for bug B just for illustrating my
50 people have issues with bug A. 5 people have issues with bug B.
Extrapolate... 5 people with bug C, 5 with D, all the way though Z.
You now have 125 people unhappy with 25 bugs.
If the goal is to increase the usage of LO, is it better to have 50
unhappy people over A not being fixed, or 125 unhappy people over bugs
C-Z. Which group is more likely to pass along negative impressions?
In other volunteer based organizations (humanistic, animal
protection, etc), people agree to do work on tasks attributed to them
even if that is not what they feel like doing. The "do whatever you
feel like" model doesn't work.
And I don't think anybody is suggesting that that model is the
predominant one here.
I have pointed out in the past that you cannot expect a developer to
work on your bug, because there is nothing forcing him to work on
anything but what he wants to, but that doesn't mean that is all he
does. It means you can't *force* him to work on what *you* want him to
work on. I'm sure the developers *do* give careful consideration to
what they work on, it just might not be what you feel they should work
on, but they've got a bigger picture than you.
Remember, we do have to keep the developers happy to some extent,
otherwise they leave. This is true even if they are getting paid (I've
left more than one company which was paying me, because I was unhappy
with some other aspect of the situation), and especially true if they
are not getting paid. Also, just because they don't prioritise the bugs
you think are important, doesn't mean they are cherry-picking just the
bugs they like, it probably just means they had other, more important
things to deal with.
Just something to keep in mind.
Mac OS X 10.8.5
To unsubscribe e-mail to: email@example.com
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
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