Engaging users: initial results of the survey

snowshed wrote

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

+1

Out of 300 developers you could have two groups: one for major
bugs/regressions by priority and another for going through the bugs starting
from #1

Of course this would require a commitment to do whatever is asked by the
coordinators... On a "do what you feel like, when you feel like" spirit this
won't obviously work.

Hi Paul

Paul-6 wrote

Third, "there is nothing forcing him to work on anything but what he
wants to" is exactly the problem IMO.

Sure, but it is a problem with no solution. Unless you have blackmail
material, or bribery material (such as, say, a salary), there is very
little you can do to force someone to do something they don't want. The
best would be to come up with better incentives.

You are missing the voluntary concept. Voluntary doesn't mean that you do
what you feel like when you feel like. It means that you are volunteering
your time and/or skills for some project. Someone coordinates the tasks no
matter how uncomfortable and assigns them. Then everybody contributes to do
it on the agreed schedule.

Do you think it is a pleasure to go out at night during the Winter to
distribute food to the homeless? Yet volunteers do this...

+1 That is *exactly* the concept of volunteers. Add firefighters to this list. They may put their lives at risk entering a burning building, and they don't get paid.

You and John have missed my point.

Features vs. bugs is irrelevant in what I'm saying. I'm asking, in the example above, do you want 50 PO'ed users, or 125 PO'ed users? Nothing more. If you pick 50, then you'd rather have more PO'ed users than happy users. Time and effort comes into play only from the standpoint of, are you willing to put in the time and effort?

This, of course, factors into my comments in news://news.gmane.org:119/l5u6ck$rh8$1@ger.gmane.org Are there enough resources?

Around here, we have a saying about contractors. You can tell the successful ones, they drive the new pickups. They put in far more hours than they get "paid" for.

LO needs to decide if they want to be successful at that level. Paid or unpaid, that means lots of time. Period.

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.

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

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?

You didn't provide links to the bugs that you provided, so I really
can't tell if they're crashes every 4th time you start, "I don't like
where the mirror is placed", or something in between problems.

It never occurred to me someone would want the bug numbers. <G>

     1. 44871
     2. 44986

And yes
there is a right way to tell the customer that the issue is either not
one that you get to at this moment or that the majority prefer the
solution solved another way (usually it involves a suggestion of an
alternative technique).
But even though you treat the customer as if they are always right, that
does not mean that they are always right. Some things the customer is
wrong on.

Indeed, sometimes they are wrong. But, if you want them to return,
they are always right. :slight_smile:

I'm not sure I want somebody to return enough to bend over backwards
over a feature tweak vs taking the time to look at core functionality.
I'm pretty certain I (and Libre Office) would lose more customers than
they gain.

Then... You don't want them as a customer/user, nothing more than that. Now, if you were building your own business, is that something you want to be doing, driving customers away?

Some things are out of budget for LO, and some things are
just preferred to be done another way. The choice has been put in your
court. You can use LO or you can find another office suite that meets
your needs depending upon the issue.

As I've posted, I am looking for an alternative, and have
"candidates". LOL

And you're welcome to them. I doubt that they're going to bend over
backwards either, particularly if they are free and open source options.

No way to know how they will react, until you use them. Any other perspective is an opinion/assumption.

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.

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

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?

You didn't provide links to the bugs that you provided, so I really
can't tell if they're crashes every 4th time you start, "I don't like
where the mirror is placed", or something in between problems.

It never occurred to me someone would want the bug numbers. <G>

     1. 44871
     2. 44986

And yes
there is a right way to tell the customer that the issue is either not
one that you get to at this moment or that the majority prefer the
solution solved another way (usually it involves a suggestion of an
alternative technique).
But even though you treat the customer as if they are always right, that
does not mean that they are always right. Some things the customer is
wrong on.

Indeed, sometimes they are wrong. But, if you want them to return,
they are always right. :slight_smile:

I'm not sure I want somebody to return enough to bend over backwards
over a feature tweak vs taking the time to look at core functionality.
I'm pretty certain I (and Libre Office) would lose more customers than
they gain.

Then... You don't want them as a customer/user, nothing more than that. Now, if you were building your own business, is that something you want to be doing, driving customers away?

If I run a Mexican restaurant and won't change the menu on the fly to cajun/spanish/chinese/japanese for each and every random person who comes in, that doesn't mean that I don't want them as a customer. Similarly speaking LibreOffice wants the people who would like to see Outlook/Publisher clones included in the suite; they've just decided that adding those would strain the project too much. You seem to confuse FOSS developer with personal concierge.

Some things are out of budget for LO, and some things are
just preferred to be done another way. The choice has been put in your
court. You can use LO or you can find another office suite that meets
your needs depending upon the issue.

As I've posted, I am looking for an alternative, and have
"candidates". LOL

And you're welcome to them. I doubt that they're going to bend over
backwards either, particularly if they are free and open source options.

No way to know how they will react, until you use them. Any other perspective is an opinion/assumption.

I've been around a couple of FOSS projects in my time. Threatening to leave because one or two issues which don't break the program won't fly with them either. In fact, I don't know of many paid software companies that will do that unless you're the one paying for the custom made software.

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.

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

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?

You didn't provide links to the bugs that you provided, so I really
can't tell if they're crashes every 4th time you start, "I don't like
where the mirror is placed", or something in between problems.

It never occurred to me someone would want the bug numbers. <G>

      1. 44871
      2. 44986

And yes
there is a right way to tell the customer that the issue is either not
one that you get to at this moment or that the majority prefer the
solution solved another way (usually it involves a suggestion of an
alternative technique).
But even though you treat the customer as if they are always right,
that
does not mean that they are always right. Some things the customer is
wrong on.

Indeed, sometimes they are wrong. But, if you want them to return,
they are always right. :slight_smile:

I'm not sure I want somebody to return enough to bend over backwards
over a feature tweak vs taking the time to look at core functionality.
I'm pretty certain I (and Libre Office) would lose more customers than
they gain.

Then... You don't want them as a customer/user, nothing more than
that. Now, if you were building your own business, is that something
you want to be doing, driving customers away?

If I run a Mexican restaurant and won't change the menu on the fly to
cajun/spanish/chinese/japanese for each and every random person who
comes in, that doesn't mean that I don't want them as a customer.
Similarly speaking LibreOffice wants the people who would like to see
Outlook/Publisher clones included in the suite; they've just decided
that adding those would strain the project too much. You seem to
confuse FOSS developer with personal concierge.

No, if you ran a Mexican restaurant, you forgot to include the tortilla when you made the burrito. Fix the burrito.

Or, I ordered a burrito, you gave me an uncooked fajita.

It's not about changing the menu, it's fixing the offerings on the menu.

I disagree. I am not a developer, but I have never been reminded that I
am of secondary importance for the project. And I do think that this is
just a biased perception based on the fact that developers are not good
at communicating, and sometimes they use the wrong words (which should
not happen, of course). People should not stop in front of the words of
a developer, if they are really interested in contributing.

+1.

Also let's all keep in mind that there are *vast* areas of the project
one can contribute without being a developer.

Best,

>> Then... You don't want them as a customer/user, nothing more than
>> that. Now, if you were building your own business, is that
>> something you want to be doing, driving customers away?

Actually, if you are building your own business, and are a smart
business person, you *really* do want to drive away the type of
customer who expects you to bend over backwards for him all the time.
If you do it the first time, he will just be back, over and over again,
expecting you to bend over backwards for him every time. The quicker
you show him that there are certain things you will and won't do, the
quicker you can either have him as a respectful client with whom you
have a good business relationship, or the quicker he goes away and you
can concentrate on your other cutomers with whom you do have a good
business relationship.

No, if you ran a Mexican restaurant, you forgot to include the
tortilla when you made the burrito. Fix the burrito.

Or, I ordered a burrito, you gave me an uncooked fajita.

It's not about changing the menu, it's fixing the offerings on the
menu.

Actually, it seems to be about you being upset that the bugs you
reported haven't been fixed. Meanwhile lots of other people are quite
happy with the many, many bugs that have been fixed, and the many, many
requested features that have been added. The analogies are breaking
down here, people.

> I've been around a couple of FOSS projects in my time. Threatening
> to leave because one or two issues which don't break the program
> won't fly with them either. In fact, I don't know of many paid
> software companies that will do that unless you're the one paying
> for the custom made software.

Pretty true. If you are paying for custom written software you get to
dictate what gets fixed in what order. Otherwise, FOSS software and
commercial alike, it's all at the whims of the developers. LO is no
different to any other software in that regard. And it happens to be
working pretty well, from what I can see.

This whole discussion seems to be about the fact that a couple of
people disagree with the priorities of the developers when it comes to
fixing bugs. They have a couple of bugs that haven't been fixed in a
couple of years, and are crying foul. Meanwhile, most of the people are
happy with the pace and focus of the bug system in LO.

Unfortunately, those couple of people have latched on to the idea that
the LO developers do what they like only, which I am sure is completely
false. Probably my fault, as I made a comment about not being able to
*force* them to do something, and now everybody is up in arms about
them *only* doing what they like, trying to argue that we should force
them to work on specific bugs (their chosen bugs, of course), and how
they have a silly mindset that is alienating users. Of course this is
not true, and I never meant to imply it (and didn't really, people just
misunderstood what I actually did say). I would say the majority of
people are perfectly happy with the priorities of the developers and it
is only a few edge cases that are left (for one reason or another) to
linger for a long time. I do think if any developers are reading this,
they should take notice and maybe re-look at their bug prioritisation
system, I think there can be some improvements, but I *don't* think the
system is totally wrong, and that the developers are arrogant sods who
don't care about the users, and just do whatever they think will be
most fun, as it seems some are suggesting.

Bear in mind that all car and Mexican restaurant analogies aside, we're
really talking about the developers leaving a handful of bugs unfixed
for a couple of years. That's all.

You are missing the voluntary concept. Voluntary doesn't mean that
you do what you feel like when you feel like. It means that you are
volunteering your time and/or skills for some project. Someone
coordinates the tasks no matter how uncomfortable and assigns them.
Then everybody contributes to do it on the agreed schedule.

Do you think it is a pleasure to go out at night during the Winter to
distribute food to the homeless? Yet volunteers do this...

Sigh. You miss the point. Yes, volunteer firefighters go selflessly
into burning buildings without pay, because it is their job. Volunteers
go out at night in winter distributing food to the homeless, without
pay, because they have volunteered. But you are still relying on their
goodwill. If they decide that it is too much effort, they can quit at
any time. The same for the developers. If they become too frustrated
with the bugs they are working on, they can just stop working. For a
couple of days, weeks, months, even years. Or just never come back to
the project. One wants to avoid that. And it also means that one can't
*force* a developer to work on something. If I volunteer as a
firefighter, and get to a burning building, and decide I don't want to
go in, there is nothing stopping me from just taking my firefighter kit
off and leaving. It's bad form, but you're missing the point that you
can't stand there telling me I *have* to go in. We are relying on at
least some goodwill from the developers. Don't spit on that.

And if I volunteer as a firefighter, and get to an apartment complex
that is burning, and the fire chief decides that we need to go into the
top level apartments first, due to structural integrity concerns,
people being in them, etc, you can't, as a member of the crowd gathered
to watch, start insisting that I go into one of the middle floor
apartments to rescue your daughter's doll. I may be a volunteer, but
that doesn't mean you can force me.

Because that is what we are talking about. Hey, it's your analogy.
Well, actually the firefighter analogy was Ken's.

Remember, you are not a developer. The developers fix bugs. When you
fix bugs, you get to choose which ones you work on. The developers fix
the bugs, so they get to choose which ones they work on. And they
*don't* just choose whichever one they want. They have a process for
deciding. One that most people think works pretty well. Maybe it can
stand a few improvements, but on the whole it is pretty good. And you,
as a user, get to jump up and down and make noise about your bug all
you want, and hope they will notice it and prioritise it, but you can't
*force* them to work on it. And you may feel that it is the most
important thing right now, but they have a bigger picture, and if they
say it goes to the back of the queue, it goes to the back of the queue.
Same as any software, commercial or FOSS. Unless you are doing
it yourself (fixing the bugs), or paying for it yourself, you don't get
to decide. The people who make it do. And they decide based on what is
going to sell more.

Paul-6 wrote
>> I'm suggesting that a compromise based volunteer model is applied
>> to all, not just to developers. Then you might start to see a
>> change and a real community :wink:
> I'm not following; who apart from the developers would you apply
> this to? To what end?

To anyone contributing to this project. It is quite obvious by your
comment that anyone who can't code isn't an important part of this
project. Someone like myself who helps irregularly on AskLO. Someone
who helps irregularly on Translation. Someone who helps on
Documentation... all those useless non-developers...

Don't put words in my mouth!
I have *never* said that only people who can code count. I have *never*
even implied that. And I certainly don't believe it.
And I'll thank you to not slander me in the future.

If there is a sense of responsibility and commitment so that you can
actually feel that people are doing whatever is needed within a
defined schedule (not just " what they want, when they want") then
you can create a real community and move forward much faster.

I still don't get the relevance. We were talking about the developers
not fixing a few bugs for some years. I was arguing that we can't
force them to fix any specific bugs, and that they are doing a good job
of prioritising bugs. You were arguing that we should force them to
work on whichever bugs you thought they should work on. How does the
rest of the community factor into this?

Sigh. I give up.

You are right. You can't tell people what to do. That is how voluntary work
is done.
And there is no point in applying this to the whole community.

Sorry for wasting your time.

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
PO'ed users?

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
look back.

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.

For me I tried to navigate bugzilla to report continuing bugs where
2 formatting issues occur regularly:

Oogie,

without having completely read (and even less understood) your problem,
I'd suggest first to try creating a new spreadsheet from scratch and
then copy-pasting the data from the old sheet into the new one. Just to
exclude there is some ancient inconsistency in your document which
causes the problem.

[...]

Unfortunately bugzilla is worse than difficult to use and now it's
even harder to find out how to do that.

Bugzilla is a bug database. So what you have to do is filing a bug with
a description which allows developers (and QA people) to reproduce your
bug reliably. There is a detailed Howto in the wiki[1]. However, it's a
rather extensive description trying to cover most eventualities, so if
you have questions, please don't hesitate to ask them e.g. here.

[1] https://wiki.documentfoundation.org/BugReport

Regards,
Nino

You are right. You can't tell people what to do. That is how
voluntary work is done.

I'm happy so long as nobody is going around complaining that the devs
are a bunch of lazy, arrogant anarchists who ignore users in order to
do whatever they like. Noticing the trend for that implication in the
arguments was genuinely concerning.

And I realise some of what was being argued about was misconstruction
of some of my comments. Perhaps they were not required. I hope I have
corrected any misperceptions that have arrisen.

And there is no point in applying this to the whole community.

No indeed not. The community already works that way, and works quite
well, I think.

I do hope we're all on the same page about slagging the developers.

Paul

Sigh. I give up.

Me too.

What's sad and disappointing is, I really wanted LO to work for me. Rather feels like all the time I've spent with it, is ultimately wasted, since it won't work for me.

No replies to this are necessary, as soon this post appears, I'll be deleting the list from my news.gmane.org account.

Huh, I'd forgotten you can do that. And yes, if I have a cell with
mixed fonts, selecting the cell and changing the font or size affect
all the contents in the cell. Selecting all cells changes all cells
that have only one font or size, but affects only the parts of the
mixed cells that haven't been individually changed. I guess this could
be desired, if you have individually changed part of a cell, and then
want to change the default, you don't want to affect the changed part
of the cell, but also you may want to set everything back to default,
and you can't. The same behaviour is exhibited with bold.

Aha!

But if you first select all cells, then right click and "Clear Direct
Formatting", then everything returns to normal font, size and
bold-ness. Of course this gets rid of all other types of formatting
too, like cell backgrounds...

Hrm...

This may be a complicated issue, as in the correct functionality
depends on what you are trying to achieve, and would be hard to guess
at beforehand.

How do I just log into the bug reporting system and search it? Anyone?

This is a list of all LibreOffice bugs

<https://bugs.freedesktop.org/buglist.cgi?query_format=
specific&order=relevance+desc&bug_status=__open__&product=
LibreOffice&content=>.

thanks, but I didn't ask for that...

You would eventually discover that when "Getting Involved"...

Nope... clicked that link, still couldn't find a 'Bugzilla Login Page'
that I can simply log into (with my user account), then search bugs, check
status of or work with bugs I've reported, etc...

Freedesktop.org Bugzilla log-in page <https://bugs.freedesktop.org/> (click
"Log in top right hand corner)
-> click "Search"
-> Select "LibreOffice" in the "Product" drop down and search you heart out.

OR

Use the Search field in the previous link.

Is that really so hard to find?

It is when 'the previous link' is NOWHERE TO BE FOUND ON THE LIBREOFFICE WEBSITE.

Maybe you should actually READ a thread before responding with condescending irrelevant responses.