Sometimes developers have a prickly relationship with their users. Users
may have unrealistic, or overly demanding, requests that can be difficult
to respond to. The most vocal of these users are often
unwilling to take "no"—or even "not yet"—for an answer. Some
KDE developers are currently struggling with that problem, and trying
to find ways to smooth the dialog between users and developers.
In a posting to the kde-devel mailing list,
Pau Garcia i Quiles wondered where KDE 3 features that were missing from
KDE 4 should be collected. He noted that there are various places users
were complaining about these missing features (including an openSUSE
web page that collects them), but no central location for KDE to track such
things. His suggestion: "Can we start something like that in
UserBase, for people to tell us
what they miss in KDE4 from KDE3? Or have a special category in
That set off a bit of a rant from Aaron
J. Seigo about user complaints:
[...] there's a certain sort of
bullying going on there where certain individuals, fewer with each release i
might add, feel that if they just SHOUT LOUD AND ANNOYINGLY ENOUGH AT US that
we'll relent, break our designs, go back on what we're trying to do and give
them what they are used to at the expense of everyone else.
[...] but i won't go back on various design decisions and throw out all the
we're reaping due to those decisions. i refuse to fall into some misguided
knee-jerk-to-the-latest-random-user-moaning design "methodology"
Seigo also noted that the openSUSE list doesn't "mention _at all_ the
actually useful features that are missing", and, that, when he
commented on that wish list item, he "got yelled at by two different
people on the report, completely without cause". Frustration is
obvious in his posting, and he noted that it was probably not quite the
response Garcia expected, but he wanted to make it clear that the current
options were not working:
now, i'm all for a proper feature request system. bugzilla is not that, a wiki
is not that, random emails are not that, a blog is not that. FATE, as used by
opensuse, gets pretty damn close though (and it even has a kde client). one
day i'll probably just say "screw bugs.kde.org for feature requests" and have
someone set up a FATE install for plasma. and then we can get on to the
business of proper feature request work flow.
Anne Wilson noted that the users Seigo is
referring to are just a "*very* vocal minority" that
"can only be ignored". She is concerned with the users who
are trying to make a difference with their bug reports and feature
requests, only to be treated as if they are part of that loud minority.
She disagreed with Seigo's suggestion that users should either write—or
pay for—the code, or just be patient:
Unkind and unrealistic. Without bug/wish reports how do you know what
features people value? Again, just a kind reply of 'coming, but not yet' is
not too much to ask, but often too much to get.
But, Seigo sees things somewhat differently. He points to this vocal minority as part of the
reason that KDE projects aren't "paying much attention to
feature requests made on bugs.kde.org". Once again, he places the
blame largely at the feet of the user community:
the user community that interacts with F/OSS projects such as KDE really needs
to start understanding how this all works and taking some responsibility in
their actions. as developers we're expected to be paragons of behavior, but
really it's cooperative between all of us. except that the user community
tends to still lack a clear set of shared values and ethics when it comes to
There was some discussion of changing various bug tags, particularly
WONTFIX, as it is regularly misinterpreted, to try to alleviate the
problem. That is unlikely to mollify the users who are most vocal, though.
Trying to ensure that features and bugs closed as WONTFIX get some
kind of explanation will probably help with, but not eliminate, the
problem, as well.
Andreas Pakulat points out that it is a
social problem: "people are getting used to be
able to shout, rant and moan on the net without ever being held
responsible for the possible damage they do with that".
One idea that seems to be gaining some
traction is to use KDE
Brainstorm, which was suggested as a place to gather features by Stefan
Majewsky. Aside from some usability issues that seem like they could be
dealt with relatively easily, Brainstorm provides a means to discuss
new (or missing KDE 3) features, while allowing users to vote on those they
find most important. Seigo sees it as a
[...] it needs workflow improvements, but at
least it's collaborative, it's positive, it's easy for users to use and it
looks pretty. we need to improve things like brainstorm and see more systems
But the problem is more than just work flow. From the postings in the
thread, some KDE developers are finding it difficult to work with the user
community, largely because of the behavior of a few of its members.
Parker Coates is unconvinced that a
tool-driven process will eliminate the problem:
[...] But even if we developed a whole plethora of tools
that encourage positive contribution, respect for others, world peace,
community spirit and ponies, we would still have to deal with the
appearance of trolls who'll crap on everyone's parade with negativity
and shortsightedness. In today's Internet culture I see no way around
it, so we can't hold the community responsible for their existence. Of
course every individual in the community is responsible for how they
respond to and deal with such types, so maybe that's where we should
be focusing our efforts
Due to the very vocal, and largely negative, reaction to the release of KDE
4 more than a year and a half ago, there is still a great deal of
frustration within the project—for both users and developers.
While there are certainly some important points in the developers'
messages, the tone is such that they also
could be taken as an indictment of all users—something
that is clearly not intended.
This is a problem that certainly isn't limited to KDE, as other
projects have or will run into the same kinds of problems. There is a
delicate balance between ignoring the "vocal minority" and ignoring the
user community as a whole. The latter could easily lead a project to
completely lose touch with the needs of its users, to the point where those
users end up walking away. That is an outcome both sides want to—and
should—avoid. Finding better ways to handle feature requests, while
avoiding the conflicts with the few who will not be civil, is a good step
on that path.
to post comments)