Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index

Hi, Michael,

On 11/12/13 3:53 AM, Michael Meeks wrote:
Hi Ken,

On Mon, 2013-11-11 at 11:33 -0700, Ken Springer wrote:
After using LO for awhile, I found and filed a couple of bugs/issues.  I
wanted to contribute in the area of reporting issues, but I don't have
the knowledge to fix them.  I didn't expect those problems to go to the
head of the line.  But I *did* expect them to be put in the queue and
eventually fixed.

        The problem of course is that there is no queue of bugs-to-fix. We try
to prioritize issues, so that we can see those that are seriously
debilitating and then try to fix those on a best-effort basis.

Maybe there should be a queue, and fixed on a FIFO basis. Are either of my posted bugs, or the ones that I listed in another post debilitating? No. Would I expect mine to be fixed before X number of debilitating bugs? Not in a million years. But they need to be fixed eventually, and not languish until the end of time. LOL

More than once, it's mentioned that open source projects have limited resources. That I don't mind, either. But, if you can't/won't/don't get all of the bugs squashed with the resources you have, then you need to step back and reassess the situation. You need to do 1 of 2 things:

        1.  Acquire more resources
2. Acknowledge the project has outgrown the existing resources, and it's time
                to top adding features you do not have the resources to maintain.

As I said earlier, it's better to do a few things well, than a lot of things poorly. I seriously doubt there are thousands of people with the same issues (bugs) I have. But there must be a lot of people like me for whom a feature they need doesn't work. Individually, there won't be many users per bug. But in the aggregate, you could have thousands and thousands of unhappy users. Do you feel those folks are going to give LO a good push with out adding the proverbial "but"?

What I didn't like was being told my issues were not important.  BS!
It's important to me.

        This is the interesting piece to me. Can you expand on your experience
there ? clearly all bugs are important to someone - but not all are
'Critical' or whatever from a prioritization perspective. Nevertheless,
perhaps the naming of those prioritization is needlessly offensive.
Potentially with our new bugzilla we could use P1 -> P6 or whatever -
making it clear that this is a spectrum.

This is were the word "critical" is the issue, and how it's defined. Sometimes, you can give the word a fixed, quantitative "value", if you will in some cases, in others, it's subjective. An issue may be minor and not critical from your perspective, but it could be major and very critical to your user.

What told me I was being ignored, and essentially my issues were not critical, is the fact they were never assigned to anyone for fixing, and labeled as such.

Let's say you have a car, and every 4th time you go to use it, it won't
start.  You take it to your mechanic, and each time you do, he tells you
"it's not important, he's got bigger problems to solve".  Are you going
to continue to take it to that mechanic, or are you going to find a
different mechanic?

        I'm really not sure that there are any mechanics out there that do work
for free; I've not met one. Of course - if you want to pay for a bug to
be fixed, our level-3 bug queue has only a handful of open-bugs, and
they turn over on a weekly basis. But I strongly suspect you don't want
to pay.

Don't want to pay? I bought a commercial writing program to help replace LO. Isn't that paying? <G>

        So - perhaps a more apt analogy is taking your car to a local friendly
volunteer / free mechanic down the road who helps people out of the
goodness of their heart - and berating them for not spending a week
investigating and fixing the squeak in your suspension -now- because
he's been working trying to get other people's car's to start at all ;-)

With the car analogy, it depends on how "critical" having the car working is to you. If you need to have it start every time, barring being out of gas and such (LOL), you pay to get it fixed. If the use is sporadic, and dependability of that car isn't needed, you might choose to have your neighbor tinker with it. Even then, there's an end to that path, you get your car back, and do something different. Sell it, give it away, let it rust away in your driveway.

Either way, the car eventually gets used less and less.

        Anyhow - there is no desire to offend people through the prioritization
flow; that is a really critically useful function of QA though - so
ideas on how we can improve that appreciated.

I downloaded another open source writing program, and the developers are clear they do what they want, if you want an issue fixed, you fix it yourself, one way or another. That's fine, if there's issues I need and they don't work, that's fine. They aren't telling me to use their program instead of XXXXXX. They say here it is, if it works fine, if it doesn't, please use something else.

The minute LO or any open source program says "Use us instead of XXXXXXX or YYYYYYYY", you just crossed a line where users will expect things to work. After all, you just told them you can use LO instead of XXXXXX or YYYYYYY. But in XXXXXXXX or YYYYYYY, the feature(s) the user is looking for works and in LO it is broken, and the user does not have the ability to fix it, what do you think the user is going to do?


Mac OS X 10.8.5
Firefox 24.0
Thunderbird 17.0.8

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: 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.