[This didn't send the first time, trying again]
Re: Ryan Lane
That said, a number of the points are misguided.
FlaggedRevs is a poor
example to be used by either the foundation or the community.
FlaggedRevs is a perfect example of how design by committee (where the
committee is the community) utterly fails. FlaggedRevs should be used
by both the foundation and the community as an example of a project
that failed because the community designed something by committee and
the foundation went along with those plans. We should never forget
this lesson.
LiquidThreads was also originally community designed. The maintainer
added every feature under the sun that the community requested, which
lead it to become a bloated and difficult to maintain piece of
software...
I most definitely agree - WONTFIXING a request that is a "bad idea" is
just as important as fixing bugs, or implementing the good ideas. The
art is of course in being able to determine what constitutes a "bad
idea" and a "good idea". Its also important to keep in mind the
community is full of many people with different conflicting goals, you
can't blame them for requesting bad ideas or things they don't
actually want. (Just to be 100% clear, I'm not saying that you (or
anyone else) is blaming the community for that, just making the point)
I think the major problem with the Op-Ed is that he
points the blame
fully at the foundation when the blame is a combination of the
foundation and the community. A major part of the problem is that the
feedback from the community is almost always purely negative, and this
Op-Ed is another example of that.
I would disagree that all feedback from the community is negative. I
often get positive feedback from the community. Positive feedback in
my experience seems to most often happen for small bug fix type
changes, but I have seen it for larger changes as well. Then again I'm
a volunteer, so which side of the us vs them fence I fall on seems to
vary.
If a foundation project is solely receiving negative feedback, then
perhaps that is the community trying to tell the foundation something.
The flip side of that is that the
foundation communicates very poorly with the community. It's difficult
to effectively communicate with the community because our
communication tools suck. Our communication tools suck because it's
very difficult to change them because it's difficult to get the
community to agree with changes. Welcome to the vicious circle.
Quite frankly, the communication tools don't suck that much. It seems
that no one really uses them. When was the last time a developer
posted on the village pump asking for user feedback, or notifying
users of a change, or otherwise talking to the users? We don't even have
messages about upcoming deployments anymore [I guess that's
because they're so frequent it might be considered spam?]. Sure there's the
occasional message, but not much. Although jorm's op-ed didn't meet
with a full 100% positive response, it did seem to be a good step in
the right direction in terms of communication as far as I can tell
from the comments it received.
> One of the most important points here is about
experimenting on users; and
> it should be taken seriously. I also believe strongly that, as the author
> suggests, we should treat editors as colleagues rather than customers.
>
This assumes that we aren't currently. I challenge
the assumption. Can
we get some evidence of that being the case? During the summer of
research we worked directly with the community as colleagues. There's
numerous other examples of this being the case.
I agree with MZ on this point. Furthermore it feels this problem has
gotten worse with time. (On the flip side, there is an even more
pronounced problem with the "community" treating us as service
providers instead of colleagues - so it goes both ways)
--
-bawolff