[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
