Wikimedians are rightfully wary

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Wikimedians are rightfully wary

bawolff
[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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Ryan Lane-2
> 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.

>>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.
>

Not all of the feedback is negative, but the majority is. This is
actually fairly natural, though. All software has this problem. People
tend to provide negative feedback far more often than positive
feedback (think restaurants or seller reviews). What we need is more
positive feedback telling us what's going right, rather than mostly
hearing what's going wrong.

Positive feedback makes developers feel good. That may sound cheesy,
but it's pretty demeaning when people give nothing but bad feedback.
Positive feedback is far less likely to be ignored, and having a mix
of positive and negative feedback makes it more likely that negative
feedback won't get ignored due to numbness.

>>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.
>

When I'm doing an ops change that is user facing I write a blog post
and I post something to wikitech-l. I don't bother using village pump.
There's a reason for that. There's a *lot* of village pumps. Hundreds.
In different languages. I can't possibly handle that many different
conversations in that many languages. Even if I only post to 2-3 of
them, I still have to have the same conversation over and over again
with different sets of people.

We need a global system for communication for things like this.
Everyone should be a part of a single communication thread about
changes. All posts in the thread should be able to be translated in a
crowd-sourced manner.

Thankfully, there's messaging and notification systems planned (and
being built currently?) that will bring us part of the way there. Of
course, MZ's Op-Ed harshly criticized the Op-Ed that discussed these
systems, so it seems my point about this is kind of being proven ;).

>>> 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.

- Ryan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Platonides
In reply to this post by bawolff
On 21/08/12 23:50, bawolff wrote:

>> 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)

This is an important point. Pretty much everyone here can "accept" a bug
(by coding the feature), but when to "reject" it?
I'm sure there's a number of "bad-ideas" bugs which nobody closed.
Because "who am I to decide on this?", "this might be implemented in an
extension if it's really needed...", etc.

I don't think it's a problem for "clearly wrong bad ideas", IMHO they
are properly closed (even then, I prefer that several people chime in
saying so before closing, showing that there is consensus in not doing it).
But there's a gray area inbetween. Some even had commits or got implemented.


(LQT had a lead developer, so it would have been much easier, but I
wanted to center into the general case)


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Sumana Harihareswara-2
In reply to this post by Ryan Lane-2
On 08/21/2012 06:29 PM, Ryan Lane wrote:

> When I'm doing an ops change that is user facing I write a blog post
> and I post something to wikitech-l. I don't bother using village pump.
> There's a reason for that. There's a *lot* of village pumps. Hundreds.
> In different languages. I can't possibly handle that many different
> conversations in that many languages. Even if I only post to 2-3 of
> them, I still have to have the same conversation over and over again
> with different sets of people.
>
> We need a global system for communication for things like this.
> Everyone should be a part of a single communication thread about
> changes. All posts in the thread should be able to be translated in a
> crowd-sourced manner.

Just a quick note that the wikitech-ambassadors list
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors is
helping with this, and is going to be helping more -- I'll wait for
Guillaume to lead the conversation about this, hopefully in the next 2
weeks.

--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Quim Gil
In reply to this post by Ryan Lane-2
On Tue, Aug 21, 2012 at 3:29 PM, Ryan Lane <[hidden email]> wrote:
> 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.

In fact users filing bugs feel really ignored when nobody reacts to
their reports. Getting a WONTFIX means that someone cared enough in a
context where there is no lack of issues to deal with. Making this
point clear to anybody getting a WONTFIX is a first step toward a
happy ending.

> 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.

Most people filing bugs do understand this, specially after someone
explains this point to them once. They usually understand it even
better when such explanation doesn't come necessarily from the
powerful professional maintainer but from another peer with just a
little more experience.


>>>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.

The expression "the foundation and the community" is at the core of
the problem. If there is one problem and two sides then it's too easy
for any independent contributor to be in a different page than a WMF
employee. In practice what everybody wants is one community and a
myriad people with different levels and tonalities of engagement,
expertise and focus.

Engaged and skillful developers not working for the WMF are as
important for this biosphere as motivated ambassadors willing to test
and follow new developments. In many or most cases they are in a
better position to tell other contributors why something deserves a
WONTFIX or more constructive criticism, and get a positive response.
Of course this only works when core developers are sharing, discussing
and working together at least with those most engaged contributors.
And when those contributors feel informed and entitled to answer more
junior (or more upset) community members.

In the context of the http://maemo.org community we have got plenty of
chances to fall into non-productive fights between @nokia.com
developers and upset users. Having  some layers of empowered community
members in between (including a Bugsquad team entirely made of
volunteers [1]) helped a lot to build a common understanding and more
constructive discussions.

[1] http://wiki.maemo.org/Bugsquad

--
Quim Gil /// http://espiral.org

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

bawolff
In reply to this post by Ryan Lane-2
On Tue, Aug 21, 2012 at 7:29 PM, Ryan Lane <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Federico Leva (Nemo)
About colleagues vs. customers: I don't think it can be considered a
misunderstanding by the community, it's largely due to what the WMF
really wants.
The WMF, as the article puts it, doesn't [necessarily] want to work
better with the existing community (-> colleagues) by providing what's
felt useful /for them/ to get things done; instead, it largely assumes
that what's disliked or even plainly harmful now is actually good, if it
can attract a new demographic of users which will like it (-> new
customers).
And more: changing the demographic by ignoring the existing one is
sometimes the very aim of changes; community is assumed broken (it
scares people off), consensus even more so (we can't get anything
decided, we need "leaders" – surely not pre-emptive consensus), nobody
is indispensable (we have a big turnover, we only need to improve "_new_
editors retention"). And yes, this sometimes borders social experiments
(eugenetics? :-) ).
I'm not going to prove all this*; it's nasty to "the community", but
there's also a lot of truth in it and all in good faith.

Nemo

(*) I could quote individual WMF developers or officers but that would
be tough and unnecessary: it's the official strategy, just seen from a
different perspective (by stretching it a bit perhaps).

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Trevor Parscal-2
The idea that we are trying to attract new users at the detriment of the
existing ones is putting words in our mouths, but I do know what you mean.
The good news is that many of us are very conscious about these issues.

Here are some excerpts, for instance from the VisualEditor software design
document[1]:

   - "Visual editing should first improve the usability of the most common
   tasks. Less frequent tasks may still be performed using a source code
   editing mode."
   - "Visual editing should enhance, not degrade, the ability to inspect
   what was changed between revisions."
   - "At the very least, a visual editor should not make more work for
   administrators and editors who are reviewing edits done by others."

VisualEditor isn't alone in these beliefs, but I realize also that they are
not held widely (yet) enough either.

[1] http://www.mediawiki.org/wiki/VisualEditor/Software_design#Objectives

- Trevor

On Wed, Aug 22, 2012 at 3:11 PM, Federico Leva (Nemo) <[hidden email]>wrote:

> About colleagues vs. customers: I don't think it can be considered a
> misunderstanding by the community, it's largely due to what the WMF really
> wants.
> The WMF, as the article puts it, doesn't [necessarily] want to work better
> with the existing community (-> colleagues) by providing what's felt useful
> /for them/ to get things done; instead, it largely assumes that what's
> disliked or even plainly harmful now is actually good, if it can attract a
> new demographic of users which will like it (-> new customers).
> And more: changing the demographic by ignoring the existing one is
> sometimes the very aim of changes; community is assumed broken (it scares
> people off), consensus even more so (we can't get anything decided, we need
> "leaders" – surely not pre-emptive consensus), nobody is indispensable (we
> have a big turnover, we only need to improve "_new_ editors retention").
> And yes, this sometimes borders social experiments (eugenetics? :-) ).
> I'm not going to prove all this*; it's nasty to "the community", but
> there's also a lot of truth in it and all in good faith.
>
> Nemo
>
> (*) I could quote individual WMF developers or officers but that would be
> tough and unnecessary: it's the official strategy, just seen from a
> different perspective (by stretching it a bit perhaps).
>
>
> ______________________________**_________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l>
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Strainu
In reply to this post by Sumana Harihareswara-2
2012/8/22 Sumana Harihareswara <[hidden email]>:

> On 08/21/2012 06:29 PM, Ryan Lane wrote:
>> When I'm doing an ops change that is user facing I write a blog post
>> and I post something to wikitech-l. I don't bother using village pump.
>> There's a reason for that. There's a *lot* of village pumps. Hundreds.
>> In different languages. I can't possibly handle that many different
>> conversations in that many languages. Even if I only post to 2-3 of
>> them, I still have to have the same conversation over and over again
>> with different sets of people.
>>
>> We need a global system for communication for things like this.
>> Everyone should be a part of a single communication thread about
>> changes. All posts in the thread should be able to be translated in a
>> crowd-sourced manner.
>
> Just a quick note that the wikitech-ambassadors list
> https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors is
> helping with this, and is going to be helping more -- I'll wait for
> Guillaume to lead the conversation about this, hopefully in the next 2
> weeks.

You guys (and by that I mean "anybody who doesn't regularly edit a
text-producing project[1], but needs to make announcements from time
to time"; this includes most of the WMF employees) seem to have a
problem with village pumps and instead invent all kind of alternative
communication methods, like mailing lists, IRC meetings, Meta, WMF
wiki etc., with the sole excuse being "they're hundreds of them".

Well, let me tell you in plain English with no regard to political
correctness: your excuse sucks.

It sucks mainly because automation was invented half a century ago -
I've said this here before and I'm saying it again: it takes at the
very most 2 days to write and test a script that can post a message to
any number of pages. There could be thousands of projects, the effort
from the poster would be the same.

It also sucks because the vast majority of contributors don't
know/don't want to use IRC, mailing list or even other wikis [2].
Those who know and want to use those alternative methods are
discouraged by the scarce organization of the information.

Finally, it sucks because you basically expect people to look for your
announcements and extract the information, when the whole idea of an
announcement is to push the information from the originator to the
receiver.

Sumana, my understanding of the "ambassador" concept is someone that
takes the information from you and puts it on their home wiki(s).
That's great, except it's unlikely you will find users from all the
200+ languages and even if you do, people quit, go on vacations etc.,
leading to information loss. An automated English message on the pump,
translated on the spot would be much better.

Strainu

[1] text-producing projects are all language versions of Wikipedia,
Wiktionary, Wikinews, Wikiquote, Wikibooks, Wikisource, Wikiversity
and Wikispecies
[2] The Romanian community recently decided to lock the
Romanian-language mailing list because of the many people that were
not aware what a ML is and were replying to every email asking not to
be contacted again.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Tei-2
Well. duh.

A community will always give incremental features. This is the bazaar
thing, where you can find everything, and is not a bad thing if the
architecture support a bazaar (like a command line).
When you are actually building a cathedral, you need a central entity
that take all the input, and then proceed to do whatever he damn
please.

PR as a role here, as you can tell people "we are taking all the
input, studying it, and designing a system with the best ideas that
make the more sense", actually reserving to you the role to design,
not acting as a proxy for others.

http://theoatmeal.com/comics/design_hell

Bazaar is not always the solution.

--
--
ℱin del ℳensaje.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Tilman Bayer
In reply to this post by Strainu
On Thu, Aug 23, 2012 at 4:27 AM, Strainu <[hidden email]> wrote:

> 2012/8/22 Sumana Harihareswara <[hidden email]>:
>> On 08/21/2012 06:29 PM, Ryan Lane wrote:
>>> When I'm doing an ops change that is user facing I write a blog post
>>> and I post something to wikitech-l. I don't bother using village pump.
>>> There's a reason for that. There's a *lot* of village pumps. Hundreds.
>>> In different languages. I can't possibly handle that many different
>>> conversations in that many languages. Even if I only post to 2-3 of
>>> them, I still have to have the same conversation over and over again
>>> with different sets of people.
>>>
>>> We need a global system for communication for things like this.
>>> Everyone should be a part of a single communication thread about
>>> changes. All posts in the thread should be able to be translated in a
>>> crowd-sourced manner.
>>
>> Just a quick note that the wikitech-ambassadors list
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors is
>> helping with this, and is going to be helping more -- I'll wait for
>> Guillaume to lead the conversation about this, hopefully in the next 2
>> weeks.
>
> You guys (and by that I mean "anybody who doesn't regularly edit a
> text-producing project[1], but needs to make announcements from time
> to time"; this includes most of the WMF employees) seem to have a
> problem with village pumps and instead invent all kind of alternative
> communication methods, like mailing lists, IRC meetings, Meta, WMF
> wiki etc., with the sole excuse being "they're hundreds of them".
>
> Well, let me tell you in plain English with no regard to political
> correctness: your excuse sucks.
>
> It sucks mainly because automation was invented half a century ago -
> I've said this here before and I'm saying it again: it takes at the
> very most 2 days to write and test a script that can post a message to
> any number of pages. There could be thousands of projects, the effort
> from the poster would be the same.
>
> It also sucks because the vast majority of contributors don't
> know/don't want to use IRC, mailing list or even other wikis [2].
Yes, that's true, it has been a major learning for WMF in recent years
that while all these (and also the Wikimedia blog) can be useful
channels, many Wikipedians don't leave their home wikis and expect
really important announcements to be delivered there in some form. In
our Wikimania talk, MZMcBride and I gave an overview of the mechanisms
that are currently available to do so.

> Those who know and want to use those alternative methods are
> discouraged by the scarce organization of the information.
>
> Finally, it sucks because you basically expect people to look for your
> announcements and extract the information, when the whole idea of an
> announcement is to push the information from the originator to the
> receiver.
>
> Sumana, my understanding of the "ambassador" concept is someone that
> takes the information from you and puts it on their home wiki(s).
> That's great, except it's unlikely you will find users from all the
> 200+ languages and even if you do, people quit, go on vacations etc.,
> leading to information loss. An automated English message on the pump,
> translated on the spot would be much better.
>
> Strainu
https://meta.wikimedia.org/wiki/Global_message_delivery (a bot
operated by MZMcBride) can do exactly that.

It was used by the WMF engineering department to inform all of the
projects about the IPv6 deployment in June (e.g.
https://fr.wikisource.org/wiki/Wikisource:Scriptorium/Juin_2012#Update_on_IPv6
), and all non-Wikipedia projects about changes they needed to make to
their main page in order for it being displayed properly on mobile
devices (e.g. https://nl.wiktionary.org/wiki/WikiWoordenboek:De_Kroeg/archief19#Mobile_view_as_default_view_coming_soon
)

This still relies on local Wikimedians translating that village pump
message into their language, many are doing so with those
announcements. And, as Ryan says, it is difficult to follow up on
discussions in all those (ca. 600) village pumps, so those messages
need to point back to a central venue for feedback.

And, this is obviously a channel which can only be used for
announcements of some degree of importance. One might be tempted to
create a separate "Wikitech ambassadors village pump" and have the bot
post there. But the new broadcasting functionality that is being
developed as part of the Echo and Flow projects will offer a much
better solution (basically, as user on a Wikimedia project you will be
able to subscribe to receive notifications from information channels
across projects, and I'm  sure that one of these channels could offer
such tech updates).

--
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Strainu
2012/8/23 Tilman Bayer <[hidden email]>:

> On Thu, Aug 23, 2012 at 4:27 AM, Strainu <[hidden email]> wrote:
>> 2012/8/22 Sumana Harihareswara <[hidden email]>:
>>> On 08/21/2012 06:29 PM, Ryan Lane wrote:
>>>> When I'm doing an ops change that is user facing I write a blog post
>>>> and I post something to wikitech-l. I don't bother using village pump.
>>>> There's a reason for that. There's a *lot* of village pumps. Hundreds.
>>>> In different languages. I can't possibly handle that many different
>>>> conversations in that many languages. Even if I only post to 2-3 of
>>>> them, I still have to have the same conversation over and over again
>>>> with different sets of people.
>>>>
>>>> We need a global system for communication for things like this.
>>>> Everyone should be a part of a single communication thread about
>>>> changes. All posts in the thread should be able to be translated in a
>>>> crowd-sourced manner.
>>>
>>> Just a quick note that the wikitech-ambassadors list
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors is
>>> helping with this, and is going to be helping more -- I'll wait for
>>> Guillaume to lead the conversation about this, hopefully in the next 2
>>> weeks.
>>
>> You guys (and by that I mean "anybody who doesn't regularly edit a
>> text-producing project[1], but needs to make announcements from time
>> to time"; this includes most of the WMF employees) seem to have a
>> problem with village pumps and instead invent all kind of alternative
>> communication methods, like mailing lists, IRC meetings, Meta, WMF
>> wiki etc., with the sole excuse being "they're hundreds of them".
>>
>> Well, let me tell you in plain English with no regard to political
>> correctness: your excuse sucks.
>>
>> It sucks mainly because automation was invented half a century ago -
>> I've said this here before and I'm saying it again: it takes at the
>> very most 2 days to write and test a script that can post a message to
>> any number of pages. There could be thousands of projects, the effort
>> from the poster would be the same.
>>
>> It also sucks because the vast majority of contributors don't
>> know/don't want to use IRC, mailing list or even other wikis [2].
> Yes, that's true, it has been a major learning for WMF in recent years
> that while all these (and also the Wikimedia blog) can be useful
> channels, many Wikipedians don't leave their home wikis and expect
> really important announcements to be delivered there in some form. In
> our Wikimania talk, MZMcBride and I gave an overview of the mechanisms
> that are currently available to do so.

Can you please point me to the location of the slides (if available)?

>
>> Those who know and want to use those alternative methods are
>> discouraged by the scarce organization of the information.
>>
>> Finally, it sucks because you basically expect people to look for your
>> announcements and extract the information, when the whole idea of an
>> announcement is to push the information from the originator to the
>> receiver.
>>
>> Sumana, my understanding of the "ambassador" concept is someone that
>> takes the information from you and puts it on their home wiki(s).
>> That's great, except it's unlikely you will find users from all the
>> 200+ languages and even if you do, people quit, go on vacations etc.,
>> leading to information loss. An automated English message on the pump,
>> translated on the spot would be much better.
>>
>> Strainu
> https://meta.wikimedia.org/wiki/Global_message_delivery (a bot
> operated by MZMcBride) can do exactly that.

Great! What's the holdup to using it more?

>
> It was used by the WMF engineering department to inform all of the
> projects about the IPv6 deployment in June (e.g.
> https://fr.wikisource.org/wiki/Wikisource:Scriptorium/Juin_2012#Update_on_IPv6
> ), and all non-Wikipedia projects about changes they needed to make to
> their main page in order for it being displayed properly on mobile
> devices (e.g. https://nl.wiktionary.org/wiki/WikiWoordenboek:De_Kroeg/archief19#Mobile_view_as_default_view_coming_soon
> )

Hmmm, I remember the message, but I hadn't realized it was delivered
by a bot at the time.

>
> This still relies on local Wikimedians translating that village pump
> message into their language, many are doing so with those
> announcements. And, as Ryan says, it is difficult to follow up on
> discussions in all those (ca. 600) village pumps, so those messages
> need to point back to a central venue for feedback.

Agreed! Why not use a standard message for the feedback link, that
could be translated once and reused?

>
> And, this is obviously a channel which can only be used for
> announcements of some degree of importance. One might be tempted to
> create a separate "Wikitech ambassadors village pump" and have the bot
> post there.

I'm all in favor of "some importance" being less rather than more :) I
don't think 10 or 15 messages per month would be considered too much,
if the information is relevant to the project (i.e. don't send
Wikisource-specific updates to Wikipedias)

> But the new broadcasting functionality that is being
> developed as part of the Echo and Flow projects will offer a much
> better solution (basically, as user on a Wikimedia project you will be
> able to subscribe to receive notifications from information channels
> across projects, and I'm  sure that one of these channels could offer
> such tech updates).

I don't know many details about those, but I do have 2 observations
here. First, the fact that sometime in the future there will be a
better solution should not stop us from implementing quicker fixes.
Second, if there isn't a history of those somewhere easily reachable,
people will quickly forget about notifications.

Strainu

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Platonides
On 23/08/12 16:02, Strainu wrote:
> Second, if there isn't a history of those somewhere easily reachable,
> people will quickly forget about notifications.

Good point. If someone complains about an unknown new feature that
wasn't announced and is directed to that channel, it should be possible
to view previous announcements. Just like you can view old entries when
subscribing to a new rss feed.
(I don't know if that's already contemplated in the current plans)

Regards

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Ryan Lane-2
In reply to this post by Strainu
> You guys (and by that I mean "anybody who doesn't regularly edit a
> text-producing project[1], but needs to make announcements from time
> to time"; this includes most of the WMF employees) seem to have a
> problem with village pumps and instead invent all kind of alternative
> communication methods, like mailing lists, IRC meetings, Meta, WMF
> wiki etc., with the sole excuse being "they're hundreds of them".
>
> Well, let me tell you in plain English with no regard to political
> correctness: your excuse sucks.
>

It's not an excuse. It's a problem to be solved. Let's discuss
solutions, rather than laying blame.

> It sucks mainly because automation was invented half a century ago -
> I've said this here before and I'm saying it again: it takes at the
> very most 2 days to write and test a script that can post a message to
> any number of pages. There could be thousands of projects, the effort
> from the poster would be the same.
>

Writing a bot that handles two way communication is not a simple
problem. Especially when you consider that talk pages can be formatted
in any way imaginable. Having an automated bot to post something is
perfectly fine if we want to talk /at/ the communities, but it's not a
solution if we want to talk /with/ the communities.

Also, when considering changes/features, it's important for each
community to understand the needs of other communities as well. I
think that's something that's completely ignored right now. Each
community only cares around their own needs. Developers need to
consider the needs of all of the communities, and in some cases need
to balance the needs of communities against each other. It's best if
all of the communities see the discussions and can be involved in a
project as a whole, rather than only their portion of the discussion.

> It also sucks because the vast majority of contributors don't
> know/don't want to use IRC, mailing list or even other wikis [2].
> Those who know and want to use those alternative methods are
> discouraged by the scarce organization of the information.
>

I don't think IRC or mailing lists are a good solution to the problem
either. A global discussion system is. We need to consider the current
situation, though. I think the ambassadors idea is a good interim
solution, even though it's a massive game of telephone that's very
likely to cause miscommunication and confusion:

https://meta.wikimedia.org/wiki/Talk:Tech/Ambassadors

This idea also doesn't let the communities be involved in the
discussion with other communities.

> Finally, it sucks because you basically expect people to look for your
> announcements and extract the information, when the whole idea of an
> announcement is to push the information from the originator to the
> receiver.
>

This is my problem with a bot that pushes a message out too. It's not
two way communication. It's us sending a message out, then having no
way to have a discussion.

> Sumana, my understanding of the "ambassador" concept is someone that
> takes the information from you and puts it on their home wiki(s).
> That's great, except it's unlikely you will find users from all the
> 200+ languages and even if you do, people quit, go on vacations etc.,
> leading to information loss. An automated English message on the pump,
> translated on the spot would be much better.
>

If we can't crowdsource this, then it's never going to happen. This is
how our community scales. We have less people on the entire Wikimedia
staff than we have projects (by a very large number). We can't
possibly hire enough people to properly cover discussions in every
single project.

- Ryan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Strainu
2012/8/23 Ryan Lane <[hidden email]>:
> Writing a bot that handles two way communication is not a simple
> problem. Especially when you consider that talk pages can be formatted
> in any way imaginable. Having an automated bot to post something is
> perfectly fine if we want to talk /at/ the communities, but it's not a
> solution if we want to talk /with/ the communities.

Your idea is a great one, except... I was going to say "you can't see
the forest for the trees", but actually it's the other way around. I
think you're too focused on the big picture (communicating with the
community) to see that smaller steps can help a great deal.

Sure, it's great to have lots of peopled involved in the discussion
leading to a big change, but it's not bad at all to have some people
involved in the decision making, but _everybody_ in the loop about the
decision taken. Think of it as law-making: some people gather, discuss
and take a decision, which is then made public for all interested
parties before it comes into force.

As I said to Tilman: don't ignore or postpone small fixes just because
you're waiting for a great new version sometime in the future.

> If we can't crowdsource this, then it's never going to happen. This is
> how our community scales. We have less people on the entire Wikimedia
> staff than we have projects (by a very large number). We can't
> possibly hire enough people to properly cover discussions in every
> single project.

This makes sense and is probably the right solution for the
Community->WMF channel. However, the 2 directions need not be
perfectly symmetrical. It is far more important for the WMF->Community
channel to be reliable, timely and deliver the message as close to the
destination as possible. There are many reasons for this, the most
important one being that the WMF takes decisions that affect the
community, but not the other way around.

Strainu

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Ryan Lane-2
> Your idea is a great one, except... I was going to say "you can't see
> the forest for the trees", but actually it's the other way around. I
> think you're too focused on the big picture (communicating with the
> community) to see that smaller steps can help a great deal.
>

I haven't seen any small step solution that improves the situation,
though. Unless there's two way communication then it's the WMF telling
people "here's what we're going to do" without any way for them to
give us proper feedback. We can't possibly host discussions with all
of our communities, and it's really unfair to only select the biggest
ones.

> Sure, it's great to have lots of peopled involved in the discussion
> leading to a big change, but it's not bad at all to have some people
> involved in the decision making, but _everybody_ in the loop about the
> decision taken. Think of it as law-making: some people gather, discuss
> and take a decision, which is then made public for all interested
> parties before it comes into force.
>

I really feel that the blog is the best place for announcements like
this. At least everyone can give feedback in the comments. It's a
single communication location that has a relatively small amount of
traffic that is very specifically focused on community matters.

> As I said to Tilman: don't ignore or postpone small fixes just because
> you're waiting for a great new version sometime in the future.
>

That's why I recommended the ambassador's route. It's the best interim
solution proposed so far.

>> If we can't crowdsource this, then it's never going to happen. This is
>> how our community scales. We have less people on the entire Wikimedia
>> staff than we have projects (by a very large number). We can't
>> possibly hire enough people to properly cover discussions in every
>> single project.
>
> This makes sense and is probably the right solution for the
> Community->WMF channel. However, the 2 directions need not be
> perfectly symmetrical. It is far more important for the WMF->Community
> channel to be reliable, timely and deliver the message as close to the
> destination as possible. There are many reasons for this, the most
> important one being that the WMF takes decisions that affect the
> community, but not the other way around.
>

I think the most important thing is to enable the communities to give
feedback. There's a number of decent ways to notify the community of
changes. The blog is likely the easiest route for that.

I think WMF->community communication isn't a good way to handle
things, unless it's simply announcements. Many of the complaints
raised can be linked to poor communication. We need two way
communication.

- Ryan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Michel Vuijlsteke-2
On 23 August 2012 23:01, Ryan Lane <[hidden email]> wrote:

> > Your idea is a great one, except... I was going to say "you can't see
> > the forest for the trees", but actually it's the other way around. I
> > think you're too focused on the big picture (communicating with the
> > community) to see that smaller steps can help a great deal.
> >
>
> I haven't seen any small step solution that improves the situation,
> though. Unless there's two way communication then it's the WMF telling
> people "here's what we're going to do" without any way for them to
> give us proper feedback. We can't possibly host discussions with all
> of our communities, and it's really unfair to only select the biggest
> ones.


"Here's what we're proposing to do.
[please note: this message was posted here by a bot. If you want to discuss
this -- here's where it's at: ___. Sory for the hassle.]"

:)

Michel
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Platonides
On 23/08/12 23:24, Michel Vuijlsteke wrote:

> On 23 August 2012 23:01, Ryan Lane <[hidden email]> wrote:
>> I haven't seen any small step solution that improves the situation,
>> though. Unless there's two way communication then it's the WMF telling
>> people "here's what we're going to do" without any way for them to
>> give us proper feedback. We can't possibly host discussions with all
>> of our communities, and it's really unfair to only select the biggest
>> ones.
>
>
> "Here's what we're proposing to do.
> [please note: this message was posted here by a bot. If you want to discuss
> this -- here's where it's at: ___. Sory for the hassle.]"
>
> :)
>
> Michel

Yep. Just asking for the replies to be made at a dedicated page at meta
seems a good solution. Much better than expecting everyone to follow the
blog IMHO.



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

David Gerard-2
In reply to this post by Michel Vuijlsteke-2
On 23 August 2012 22:24, Michel Vuijlsteke <[hidden email]> wrote:

> "Here's what we're proposing to do.
> [please note: this message was posted here by a bot. If you want to discuss
> this -- here's where it's at: ___. Sory for the hassle.]"


+1

It's not two-way communication, but it sure beats zero-way
communication. And is trivially upgradeable to two-way as the
hypothesised community accretes.


- d.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Wikimedians are rightfully wary

Ryan Lane-2
In reply to this post by Michel Vuijlsteke-2
> "Here's what we're proposing to do.
> [please note: this message was posted here by a bot. If you want to discuss
> this -- here's where it's at: ___. Sory for the hassle.]"
>

Seems reasonable. What's the procedure for doing this?

- Ryan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12