[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