On Tue, Aug 21, 2012 at 7:29 PM, Ryan Lane <[email protected]> wrote: >> 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) >> > > Indeed. The really difficult thing here is that every time a bad idea > is WONTFIX'd it makes a community member feel that they are being > ignored. Do it too many times and you have a lot of community members > that feel this way. Don't do it enough and and the product suffers and > then there's complaints about it being bloated, difficult to use, etc. > It's difficult to win either way.
While that's certainly true some of the time, if a good reason is provided for wontfixing, there are also many users who will accept that not all bugs can be fixed, and will be happy someone took the time to look into the issue. (These types of users tend also to be the quiet type, so we hear about them less) [..] >>>> 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) >> > > Can you provide us with some examples? I'd like to see what's been > happening so that I can avoid behaving similarly. Honestly, I think its easier to see there is a problem when you look at how community treats developers, rather then developers treat the community. I think individual developers by in large do a good job here, it is more in the planning stages (and possibly deployment) where things go wrong. When you mention negativity, I think that is a symptom of the "service provider mentality" problem. After all, your internet service provider would really have to go above and beyond the call of duty before you called them up and told them what a good job they did. While I don't think the feedback is all negative, I do notice that sometimes it seems the third party re-users of MediaWiki tend to be more understanding and polite than the Wikimedia users. I'm not a Wikipedian, nor have I ever been. I follow enwikipedia politics only so much as what happens to make the Signpost. So the following may be misguided. However, with that said I think a strong contributing factor is the way that foundation projects targeting enwiki are just done, without first asking the community for permission first. From what I understand moodbar, article feedback, etc were all deployed without gathering consensus first. Gathering consensus helps ensure that the individual wiki communities feel like they own their communities, that they are in control. From this I believe would result in a more "colleague" relationship with the community as opposed to a service provider relationship. Having consensus for doing the enwiki targeted projects would also help give the foundation legitimacy in what it does. That said, I'm not advocating getting consensus for every little change. Security and performance concerns always have and always will be the realm of the developers. Similarly I don't believe new features in mediawiki that are on by default need consensus - generally such features are non-controversial, and there's a lot of them. If something gets enabled for everyone, we're usually pretty confident that people will like it, and that it doesn't need much explaining. Similarly extensions, or config changes that are going to all wikis do deserve some sort of notice, but again for the same reason as new MW features, I don't think consensus in general needs to be sought (There are of course exceptions I'm sure. And individual communities should perhaps be able to reject such deployments, but the onus should be on the community to reject). However, when one starts focusing on a single wiki, I really believe one should get permission from that wiki first. That of course has a downside - What if foundation hires X people to develop feature, and enwikipedia rejects it. After all features aren't free, and that would represent a wasted investment. I think such an "employees need consensus" policy would have the side effect of forcing employees to really make sure that what they are doing vibes with what the community wants. -- -bawolff p.s. Since I don't follow enwikipedia, or developments targeted there very closely, this email will be very embarrassing if Moodbar et al folks actually did gather consensus before deployment _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
