Engaging users: initial results of the survey

users
#51

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)

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 point.

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?

#52

You also have to ask if bugs B-Z are "bugs" or feature requests.

#53

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:

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

The best thing about LO is that
you don't have to drop one to take on another. And not even Microsoft
or Adobe would drop everything and start changing code just because one
user wants a change.

Changes are one animal, fixes are another.

#54

Sometimes (often?) a fix entails a change...

#55

You also now have 25 bugs to fix, which is probably going to take
*considerably* longer than just fixing bug A.

And you're forgetting about bugs/feature requests AA through ZZ, so
yes, this analogy will fall down at some point.

Again, the developers have limited resources to fix bugs, which
includes time and knowledge of the specific parts of the system, and
they have a lot of bugs and feature requests to get through. Either way
they slice it, someone is going to be unhappy. So they do the best they
can, and I'm sure that best involves a lot of discussion and decision
making, with a much better understanding of the tradeoffs than we have.

#56

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.

So you're upset because your issues were not considered "critical"?

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

Well, then as pointed out, you could simply have put that money towards
having a developer prioritise your issues. What's the problem here?

The minute LO or any open source program says "Use us instead of
XXXXXXX or YYYYYYYY"

And when exactly have they said this? I mean, I for sure advocate using
LO instead of MSO, but I'm not sure this is an official party line.

With LO quite some effort is made to give users the best experience, and
to give them some choices around that, but it just can't fit everybody's
needs. If it doesn't fit yours, you are free to go elsewhere. As you
have said you are doing. As that other software you spoke of says. So
how is it ok for the other software to basically say "here you go, if
it's broke, don't bother us, we don't care", but it's not ok for LO to
say "here you go, if it's broke, we'll do our best to fix it, but
please bear in mind that we can't fix everything"? It just keeps
sounding like you have a double standard.

As far as I can see, you're upset because you think your bugs (well, the
ones you reported) are important enough that they should be critical,
but the developers don't agree, and you're upset because after a couple
of years the bugs are still in the queue, not assigned yet. I just
can't see that as a heinous crime. For some projects the lack of action
speaks of a disregard of the users, sure, but here there is plenty of
action on bugs, just not on those bugs. That doesn't speak of a
disregard of the users, it speaks of those particular bugs not being
valued highly by the developers. Perhaps that is wrong of them, sure,
and perhaps those bugs should be bumped a little to get some action on
them, but perhaps they just haven't had enough users reporting those
issues for anyone to notice next to the flood of other issues that are
being dealt with daily. I haven't looked at your specific bug reports,
so I really don't know.

I'm just trying to see why you are so upset about this, when it clearly
doesn't seem reasonable to me. Is it because it has happened to a string
of bugs, and you feel like there is a pattern of ignoring the bugs you
submit, and have generalised that to mean there is a pattern of
ignoring all users bugs? Is it because you feel your particular issues
really are *that* critical that the developers should have sat up and
taken notice by now? Is it because you feel you were given false
expectations of LO that haven't been lived up to?

Paul

#57

Maybe there should be a queue, and fixed on a FIFO basis.

That would be a terrible idea, at least without some prioritisation.
Otherwise you'd have periods of just catching up on myriad small bugs
while big issues languish.

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.

Why? Why must absolutely *all* the bugs be squashed before you
continue? Then there'd probably be no forward progress and we'd have a
bunch of people complaining about LO being years behind everything
else, and nobody would be using it.

As I said earlier, it's better to do a few things well, than a lot of
things poorly.

Then, by definition, you don't want an office suite...

#58

First, it's not *my* bug. The bug is the software. The software is
not mine.

Well said, and very true.

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.

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?

#59

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.

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.

#60

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

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

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.

Charles-H, if you are reading this: this is one of the reasons it's hard do
engage users. At some point they are reminded that they are not developers
and therefore secondary in this project...

Best regards,
Pedro

#61

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.

#62

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.

#63

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.

#64

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.

#65

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.

#66

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.

#67

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.

#68

+1.

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

Best,

#69

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

#70

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?