On Tue, Aug 21, 2012 at 7:29 PM, Ryan Lane <email@example.com> 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
[..] >>>> 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
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.
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