Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Russavia]

Erik

On Thu, Aug 14, 2014 at 5:32 AM, Erik Moeller  wrote:

>
> This is why on all major sites, you see a gradual ramp-up of a new
> feature, and continued improvement once it's widely used. Often
> there's an opt-in and then an opt-out to ease users into the change.
> But once a change is launched, it very rarely gets rolled back unless
> it's just clearly not doing what it's supposed to.


Are you are familiar with the Flickr experience in the last 12 months by
any chance? I think that is a very pertinent and prominent example of what
goes against what you say. The Flickr attitude was much the same as the
WMF's. That ended up in a revolt, much like the WMF is seeing against it.
In the end, they ended up doing what Erik?

Also, the other day I received a Flickr email from someone wishing to use
an image which I had not taken, but which I had uploaded to Commons. They
mentioned that they saw the photo on Commons.

When I told them that I am not the author, and that they would need to
contact Joe Bloggs, their response: "I'm sorry, this is SO confusing to me."

I put that down to MediaViewer and its adding irrelevant information, and
also the fact that file information is more difficult to find.

Russavia
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] how global.js works? (was: Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you)

[Magnus Manske]

Ah, I believe when the Italian (?) Wikipedia started using my JS-based
also-search-on-wikidata tool. A dependency JS file was hosted on Tools
Labs, effectively DDOSing it to a halt. Moved file to en.wp, cache can
handle it easily now.

So, not technically a Wikipedia server, but a Wikimedia server with
lots'o'tools got unresponsive for a while. Last one I can think of.

Cheers,
Magnus


On Thu, Aug 14, 2014 at 7:55 AM, John Mark Vandenberg 
wrote:

> On Thu, Aug 14, 2014 at 1:41 PM, Gerard Meijssen
>  wrote:
> > Hoi,
> > The big question is not so much where and when things happen, the big
> > question is who supports all the muck. There have been enough instances
> > where changes to for instance common.js brought down servers.
>
> Out of interest, when was the last time that a common.js change
> brought down the servers?
>
> --
> John Vandenberg
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Pine W]

FYI, Lila had chosen to engage in discussion on her meta talk page.
Numerous editors are commenting there. Discussion also continues on the
meta RFC and on the English Wikipedia arbitration workshop page.

Pine
On Aug 14, 2014 12:03 AM, "Russavia"  wrote:

Erik

On Thu, Aug 14, 2014 at 5:32 AM, Erik Moeller  wrote:

>
> This is why on all major sites, you see a gradual ramp-up of a new
> feature, and continued improvement once it's widely used. Often
> there's an opt-in and then an opt-out to ease users into the change.
> But once a change is launched, it very rarely gets rolled back unless
> it's just clearly not doing what it's supposed to.


Are you are familiar with the Flickr experience in the last 12 months by
any chance? I think that is a very pertinent and prominent example of what
goes against what you say. The Flickr attitude was much the same as the
WMF's. That ended up in a revolt, much like the WMF is seeing against it.
In the end, they ended up doing what Erik?

Also, the other day I received a Flickr email from someone wishing to use
an image which I had not taken, but which I had uploaded to Commons. They
mentioned that they saw the photo on Commons.

When I told them that I am not the author, and that they would need to
contact Joe Bloggs, their response: "I'm sorry, this is SO confusing to me."

I put that down to MediaViewer and its adding irrelevant information, and
also the fact that file information is more difficult to find.

Russavia
___
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Clarification by Lila Tretikov about MediaViewer

[Richard Farmbrough]

The community too is asking for kindness and consideration.  Riding
roughshod over community consensus does not equate to kindness, or even
wisdom, unless it it that of Niccolò Machiavelli!

The Mission Statement of the Foundation says


*The mission of the Wikimedia Foundation is to empower and engage people
around the world to collect and develop educational content under a free
license  or in the public
domain, and to disseminate it effectively and globally.*
If the WMF would remember the word "empower" we would not get these
issues.   The Foundation needs to empower the community to disseminate
content not dictate to the community how content will be disseminated.

All the best,  Rich Farmbrough.


On 13 August 2014 13:01, Thehelpfulone  wrote:

> Forwarding on request.
>
> --
> Thehelpfulone
> https://meta.wikimedia.org/wiki/User:Thehelpfulone
>
> Begin forwarded message:
>
> > From: Ad Huikeshoven 
> > Date: 13 August 2014 12:40:14 BST
> > To: wikimedia-l-ow...@lists.wikimedia.org
> > Subject: Clarification by Lila Tretikov about MediaViewer
> >
> > Dear fellow Wikipedians and Wikimedians,
> >
> > Your work in creating the awesome thing Wikipedia is very much
> appreciated and you're all recognized for contributing towards it's
> success. Last weekend I have been to Wikimania. I really enjoyed the
> presentation by Fabrice Florin about A Culture of Kindness [1]. One of the
> slide contains a picture of Jimmy Wales holding a sheet of paper on which
> he has written 'be kind to everyone, including the annoying ones'.
> >
> > There have been multiple threads on this list with many postings about
> actions on the German Wikipedia with respect to MediaViewer. On meta Lila
> Tretikov has posted several remarks including an additional clarification
> [2], which I copy below:
> >
> > 
> > * Our overall communication, design, prioritization, testing, roll-out
> mechanisms and general product development practices are insufficient and
> must be brought on-par with our user’s expectations. We are not planning
> any new major deployments until some of those basic improvements are put
> into place. This will be done in the open; it is fundamental and urgent.
> I've touched on it at Wikimania.
> > * We are not removing MV.  It has been in production for months. Its
> removal will cause more problems and confusion for our users.  We will hold
> ourselves accountable to getting it to the level of quality that is
> expected of the top site.
> > * We are working to post next steps to clarify development and
> deployment process including rights and responsibilities; you can expect
> more information in coming days.
> > * I encourage you to help us improve our process as a whole as well as
> this specific feature by offering your time, advice, and collaboration. We
> will be engaging you on it. Please refrain from making unassisted changes
> to  the feature’s configuration.
> > 
> >
> > What Fabrice and Jimmy ask for is to be kind. What I would like to
> express is that many of the postings about MediaViewer do annoy me, and
> some are very annoying. What I do ask of my fellow Wikipedians is to
> continue to contribute to Wikipedia in a kind way, to pay attention to what
> Lila has posted on meta and which I copied above.
> >
> > Some of you might be curious to learn to know the ideas of Lila. She
> made a presentation at Wikimania, which can be viewed on line [3]. Please
> collaborate in the development of processes in a kind way. Thank you.
> > ---
> > [1]
> https://wikimania2014.wikimedia.org/wiki/Submissions/A_Culture_of_Kindness
> > [2]
> https://meta.wikimedia.org/w/index.php?title=User_talk%3ALilaTretikov&diff=9501584&oldid=9501543
> > [3] http://new.livestream.com/wikimania/saturday2014
> > --
> > Ad Huikeshoven
> >
> > Bestuurslid / Board member Wikimedia Nederland
> > Internationaal / International Affairs
> > Educatieprogramma / Education Program
> >
> > tel.(+31) (0)70 3608510
> > mob. (+31) (0)6 40293574
> >
> > Steun vrije kennis! Kijk op wikimedia.nl
> > Postadres:  Bezoekadres:
> > Postbus 167Mariaplaats 3
> > 3500 AD  Utrecht Utrecht
> >
> > ABNAMRO NL33 ABNA 0497164833 - Kamer van Koophandel 17189036
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 




-- 
Landline (UK) 01780 757 250
Mobile (UK) 0798 1995 792
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/

Re: [Wikimedia-l] A bunch of nobodies

[Gerard Meijssen]

Hoi,
Because you can..
 Thanks,
  GerardM
Op 13 aug. 2014 23:41 schreef "Michael Peel" :

> Why?
>
> On 13 Aug 2014, at 22:40, David Gerard  wrote:
>
> > Add evidence of your insignificance here!
> >
> > https://meta.wikimedia.org/wiki/A_bunch_of_nobodies
> >
> >
> > - d.
> >
> > ___
> > Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] A bunch of nobodies

[Fæ]

Let's not encourage using meta like it was Facebook. However, meh, looking
at the important names listing themselves, I can't get very excited about
pursuing the point. I'd rather not get even more black listed than I
already am.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] A bunch of nobodies

[Gerard Meijssen]

Hoi Fae,
For me you added a positive notch at Wikimania to your reputation. It was
good to see you and you were involved and having fun..
Thanks,
 GerardM


On 14 August 2014 11:07, Fæ  wrote:

> Let's not encourage using meta like it was Facebook. However, meh, looking
> at the important names listing themselves, I can't get very excited about
> pursuing the point. I'd rather not get even more black listed than I
> already am.
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Erik Moeller]

On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride  wrote:
> Is there anything that the German Wikipedia could do to convince you to
> disable MediaViewer there? Some percentage of active users showing up to
> say so? Some percentage of users (logged-in or otherwise) disabling the
> feature? (Presumably we can get stats of some kind.)

We are very open to continuing the discussion about how the feature
should be configured, how it should be improved, and how it should be
integrated in the site experience. Ideally we'd like to minimize
inconsistencies between wikis (because for readers who speak more than
one language, it's just a single site), so changes that help alleviate
conflict or disagreement should ideally also be of the kind that in
general are welcomed and wanted.

On the subject of opt-out numbers, you can see them here:
http://multimedia-metrics.wmflabs.org/dashboards/mmv_dewiki#opt_in_opt_out-graphs-tab

As you can see, the recent drama has contributed to a significant
increase in opt-out events. Pre-vote, about 17% of very active (>100
edit/month) users had disabled MMV. This is about the same number of
people who ultimately voted no, BTW, about 200. Post-vote it was 20%.
Since then it has climbed to 23%. In contrast, about 30% of that same
user group still use Monobook.

I think those numbers can and should reasonably inform the default for
logged in users, for sure. I don't think they should be used to
determine the default for readers.

In general, though, let's talk. The overarching principle we're not
going to budge on is that this process is really not acceptable:

1) The UI changes
2) A subset of users is upset and organizes a poll/vote
3) The poll/vote closes with a request to undo said UI Change and a
request is filed
4) WMF offers compromise or says no
5) A local hack is used to undo said UI change

That's no way to develop software, and that's no way to work together.
If you want a WMF that slavishly implements RFCs or votes to disable
features upon request, you'll need to petition to replace more than
just one person. In fact, you should petition to reduce the staff
dramatically, find an administrative ED who has no opinion on what to
do, and exclusively focus on platform-level improvements and requests
that clearly have community backing.

This is not the org we want to be. I am hopeful and optimistic that
there are enough admins and regular editors who believe in a vision of
improving the user experience iteratively, and working together
through conflict, that we can in future entirely rely on local admins
to prevent the kind of JS hacks we've seen here, working towards a
proper code review and deployment mechanism that further alleviates
the risk of escalations. Mind you, we made it very clear in this case
ahead of time that JS hacks were unacceptable, we attempted a revert
and a very explicit warning.

None of us love drama. We've been punting on this issue for a long
time, living with ambiguity that we knew was going to bite us sooner
or later. When DaB. removed the link to Beta Features on de.wp in
November, calling it "clutter", we ignored it and hoped that another
sensible admin would step in and restore it, because we didn't want to
trigger precisely this kind of conflict over minutiae. (It was only
restored a couple of days ago.) In other cases we've made simple
reverts to MediaWiki: edits and hoped they would stick. Can you
imagine how frustrating this is for developers and UX designers who
are paid using donor funds to improve the user experience?

We need rules of engagement for these types of changes, and they need
to acknowlege that WMF is a partner in them. The problem with the
sequence above is that there's no venue for negotiating compromises,
evaluating options, and establishing final agreements about what
should happen. That puts WMF in a position where we get to say "yes",
"WONTFIX" or "here's a random compromise, hope you like it". We need
better ways to discuss and negotiate when we disagree.

Please give us some time to outline some compromise options consistent
with the above. However, please don't expect us to endorse the idea of
"If WMF doesn't do what we want, we'll just enforce it by means of a
local hack". That is simply not workable, and no Wikimedia Foundation
that at all resembles the one we have today will accept it.

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

[Henning Schlottmann]

On 12.08.2014 21:41, Magnus Manske wrote:
> On Tue, Aug 12, 2014 at 5:33 PM, Henning Schlottmann 
> wrote:

>> This is serious. WMF really needs to appreciate the expertise of the
>> author community and accept their experience a important and valid. If
>> authors tell the WMF and particularly the devs, that a particular
>> function is necessary, then the devs really, really need to think.
>>
> 
> I do agree with this. Visual Editor (which works much better these days)
> and MediaViewer are not aimed at the experienced editor. They aim to make
> the reader more comfortable, and try to ease the first steps into editing.
> Winning new editors has been deemed a priority, somewhat at the expense of
> WMF-made support for the power user. This is a judgement call the
> Foundation has to make.

I do not undersign that dichotomy between readers and authors. And I
certainly do not accept any claim, that the MWF know all about what
readers need to become authors, while the authors are ignorant about
that. The results of the millions of dollars, the WMF put into their
understanding of readers interest are less than sterling in this regard.

>> A formal RfD must not be taken lightly, overruling it by creating a
>> whole new user class, and crippling the elected admins is inpermissible.
>> WMF has broken trust again and this time in a unprecedented way.
>>
> 
> As Erik pointed out, WMF had made it quite clear that they reserve the
> right to overrule the community in that specific matter, before the
> Meinungsbild was done. WMF then acted as announced, and refused to be
> "hacked" out of their own servers. An unfortunate escalation on both sides,
> but since they never promised to accept the Meinungsbild (quite the
> opposite!), it was not a breach of trust.

Frankly: I don't care the least, what Eric says. Of course the
Meinungsbild (RfD) at deWP was a vote of noconfidence after the previous
events at enWP. But the reaction by WMF was unprecedented and it was a
mistake. A serious one. It damaged the relation between the Community
and the WMF, it killed Jan's job and it made Rachel's job very difficult
if not untenable. To describe Eric's action I am tempted to use a
metaphor that includes black uniforms and heavy boots. But that would
not be appropriately written by a German to a German.

>> Until this event, I thought the dev process to be broken, not just the
>> communication around devs. But now I believe the conflict runs deeper.
>>
> 
> It points out an issue we (community and WMF) should discuss, in a more
> general sense. What should the decision process be for technical changes?
> When does the Foundation get precendence, and when should the community
> have the last word? What weight should small-scale "votes" of editors have?
> Should random polls be done, and included in such votes? Etc.
> 
> The MediaViewer "affair" itself gets blown out of proportion IMO.

I agree that this is not just about the MediaViewer but about a general
pattern of behavior perceived by the community. The WMF's decision
making regarding software and skin development is broken. Its targets
are flawed, it is not properly communicated with the community, the
actual development processes result in incredibly crappy software that
gets rolled out non the less in pre-alpha states.

Do I have to list all the broken projects? Liquid feedback, article
feedback tool, image filter, visual editor, flow, the new "thumb" layout.

How do you explain that to donors by the way?

All of them show that the devs and the management level do not
understand the features of the existing solutions, particularly the well
established tools and sometimes work arounds, authors created over the
years to deal with the very basic MediaWiki. But understanding the
actual use of MediaWiki is paramount to improving it.

Ciao Henning


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

[Ziko van Dijk]

Henning,

"To describe Eric's action I am tempted to use a
metaphor that includes black uniforms and heavy boots. But that would
not be appropriately written by a German to a German."

You may find yourself very smart with this kind of wording. Let me
tell you from a North German to a North German: "Dat bisse nich."

Ziko



2014-08-14 12:13 GMT+02:00 Henning Schlottmann :
> On 12.08.2014 21:41, Magnus Manske wrote:
>> On Tue, Aug 12, 2014 at 5:33 PM, Henning Schlottmann 
>> wrote:
>
>>> This is serious. WMF really needs to appreciate the expertise of the
>>> author community and accept their experience a important and valid. If
>>> authors tell the WMF and particularly the devs, that a particular
>>> function is necessary, then the devs really, really need to think.
>>>
>>
>> I do agree with this. Visual Editor (which works much better these days)
>> and MediaViewer are not aimed at the experienced editor. They aim to make
>> the reader more comfortable, and try to ease the first steps into editing.
>> Winning new editors has been deemed a priority, somewhat at the expense of
>> WMF-made support for the power user. This is a judgement call the
>> Foundation has to make.
>
> I do not undersign that dichotomy between readers and authors. And I
> certainly do not accept any claim, that the MWF know all about what
> readers need to become authors, while the authors are ignorant about
> that. The results of the millions of dollars, the WMF put into their
> understanding of readers interest are less than sterling in this regard.
>
>>> A formal RfD must not be taken lightly, overruling it by creating a
>>> whole new user class, and crippling the elected admins is inpermissible.
>>> WMF has broken trust again and this time in a unprecedented way.
>>>
>>
>> As Erik pointed out, WMF had made it quite clear that they reserve the
>> right to overrule the community in that specific matter, before the
>> Meinungsbild was done. WMF then acted as announced, and refused to be
>> "hacked" out of their own servers. An unfortunate escalation on both sides,
>> but since they never promised to accept the Meinungsbild (quite the
>> opposite!), it was not a breach of trust.
>
> Frankly: I don't care the least, what Eric says. Of course the
> Meinungsbild (RfD) at deWP was a vote of noconfidence after the previous
> events at enWP. But the reaction by WMF was unprecedented and it was a
> mistake. A serious one. It damaged the relation between the Community
> and the WMF, it killed Jan's job and it made Rachel's job very difficult
> if not untenable. To describe Eric's action I am tempted to use a
> metaphor that includes black uniforms and heavy boots. But that would
> not be appropriately written by a German to a German.
>
>>> Until this event, I thought the dev process to be broken, not just the
>>> communication around devs. But now I believe the conflict runs deeper.
>>>
>>
>> It points out an issue we (community and WMF) should discuss, in a more
>> general sense. What should the decision process be for technical changes?
>> When does the Foundation get precendence, and when should the community
>> have the last word? What weight should small-scale "votes" of editors have?
>> Should random polls be done, and included in such votes? Etc.
>>
>> The MediaViewer "affair" itself gets blown out of proportion IMO.
>
> I agree that this is not just about the MediaViewer but about a general
> pattern of behavior perceived by the community. The WMF's decision
> making regarding software and skin development is broken. Its targets
> are flawed, it is not properly communicated with the community, the
> actual development processes result in incredibly crappy software that
> gets rolled out non the less in pre-alpha states.
>
> Do I have to list all the broken projects? Liquid feedback, article
> feedback tool, image filter, visual editor, flow, the new "thumb" layout.
>
> How do you explain that to donors by the way?
>
> All of them show that the devs and the management level do not
> understand the features of the existing solutions, particularly the well
> established tools and sometimes work arounds, authors created over the
> years to deal with the very basic MediaWiki. But understanding the
> actual use of MediaWiki is paramount to improving it.
>
> Ciao Henning
>
>
> ___
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> 

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Cuenca]

Erik,

I'm impartial about the mediaviewer, but I have the feeling that this is a
recurring a pattern:
1) contributors ask for some change to improve their experience or the
reader's experience
2) their request is ignored because either it doesn't fit in the big
picture, or there is no mechanism for them to voice a request other than to
fill a bugzilla or start a rfc that will be gathering dust till the end of
the days
3) the changes are implemented anyhow in a hackish way, or not implemented
at all
4) technical debt builds up until there is the need to find a stable
solution
5) the wmf steps in with a good technical solution, or comes up with some
unrequested neat feature, but without gathering grassroots support
6) some editors are presented the tool, nobody complains because it is a
feature still in development
7) the feature is rolled out hoping it will be accepted -> if it is not ->
conflict

It would be more sensible to let contributors participate in the tech
roadmap in more formal and empowered way than now, because without that
early participation there is no possibility for later consensus. After the
experience with the Wikisource Community User Group, I can say that with
some effort promoting dialogue at international level, it is possible for
the community to come up with a set of priorities and that builds up
legitimacy. However that is all for nothing if that consensus has no impact
in the development plan.

Besides there seems to be a communication barrier between the contributors
and the wmf that shouldn't be there, and I don't think the best way to
remove it is to add more privileges or constraints, because that makes the
barrier higher, not lower.

TBH, I hope that the compromise options that you are drafting stop this
drama, but it is also important to learn from how it came to be, so it
doesn't repeat again.

Cheers,
Micru



On Thu, Aug 14, 2014 at 11:57 AM, Erik Moeller  wrote:

> On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride  wrote:
> > Is there anything that the German Wikipedia could do to convince you to
> > disable MediaViewer there? Some percentage of active users showing up to
> > say so? Some percentage of users (logged-in or otherwise) disabling the
> > feature? (Presumably we can get stats of some kind.)
>
> We are very open to continuing the discussion about how the feature
> should be configured, how it should be improved, and how it should be
> integrated in the site experience. Ideally we'd like to minimize
> inconsistencies between wikis (because for readers who speak more than
> one language, it's just a single site), so changes that help alleviate
> conflict or disagreement should ideally also be of the kind that in
> general are welcomed and wanted.
>
> On the subject of opt-out numbers, you can see them here:
>
> http://multimedia-metrics.wmflabs.org/dashboards/mmv_dewiki#opt_in_opt_out-graphs-tab
>
> As you can see, the recent drama has contributed to a significant
> increase in opt-out events. Pre-vote, about 17% of very active (>100
> edit/month) users had disabled MMV. This is about the same number of
> people who ultimately voted no, BTW, about 200. Post-vote it was 20%.
> Since then it has climbed to 23%. In contrast, about 30% of that same
> user group still use Monobook.
>
> I think those numbers can and should reasonably inform the default for
> logged in users, for sure. I don't think they should be used to
> determine the default for readers.
>
> In general, though, let's talk. The overarching principle we're not
> going to budge on is that this process is really not acceptable:
>
> 1) The UI changes
> 2) A subset of users is upset and organizes a poll/vote
> 3) The poll/vote closes with a request to undo said UI Change and a
> request is filed
> 4) WMF offers compromise or says no
> 5) A local hack is used to undo said UI change
>
> That's no way to develop software, and that's no way to work together.
> If you want a WMF that slavishly implements RFCs or votes to disable
> features upon request, you'll need to petition to replace more than
> just one person. In fact, you should petition to reduce the staff
> dramatically, find an administrative ED who has no opinion on what to
> do, and exclusively focus on platform-level improvements and requests
> that clearly have community backing.
>
> This is not the org we want to be. I am hopeful and optimistic that
> there are enough admins and regular editors who believe in a vision of
> improving the user experience iteratively, and working together
> through conflict, that we can in future entirely rely on local admins
> to prevent the kind of JS hacks we've seen here, working towards a
> proper code review and deployment mechanism that further alleviates
> the risk of escalations. Mind you, we made it very clear in this case
> ahead of time that JS hacks were unacceptable, we attempted a revert
> and a very explicit warning.
>
> None of us love drama. We've been punting on this issue for a long
> time, living w

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Gerard]

On 14 August 2014 13:56, David Cuenca  wrote:

> It would be more sensible to let contributors participate in the tech
> roadmap in more formal and empowered way than now, because without that
> early participation there is no possibility for later consensus.


A pattern we see over and over is that the developers talk at length
about what they're working on in several venues, then it's released
and people claiming to speak for the community claim they were not
adequately consulted. Pretty much no matter what steps were taken to
do so, and what new steps are taken to do so. Because there's always
someone who claims their own lack of interest is someone else's fault.


- d.

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] Board statement on the Media Viewer roll out

[Jan-Bart de Vreede]

Hi all,

Some of you have asked the Board and its individual members for feedback. Some 
of us are already in conversation with you or are planning to answer on 
different pages. This is our general common statement:

The Board supports the decision to protect the Media Viewer roll out. Our 
platform powers a top-5 website. We need operational protocols that are 
consistent with this position. This includes making improvements, rather than a 
tendency towards reverting to the status quo. 

At the Board meeting before Wikimania, Lila laid out her strategy to put in 
place best practices for product development. We will communicate sooner, we 
will prioritize smarter, we will test more, and we will achieve better 
outcomes. Her vision is to involve the community at each step of product 
development, including more structured feedback stages and reviews. We endorse 
this vision.

We realize that there is concern about the superprotect user right and how it 
affects power balance and influence on content and administration. We recognize 
the concern that we need to explain and introduce our measures better. However, 
stability of the platform is necessary as we seek to improve our sites, and, 
for that reason, we support the creation of this tool. We also understand that 
with more robust rollout plans and better staged community feedback - as Lila 
envisions - the tool should rarely be used.
We urge you to focus on specific improvements you'd like to see in the Media 
Viewer and the roll-out process. Lila intends to incorporate that feedback as 
she plans to improve Media Viewer and the process for future product roll outs.
The Wikimedia Foundation needs to be in a position to make software and 
configuration changes for which it is responsible. We expect restrictions of 
MediaWiki code-level editing to be a temporary step to enable us to move 
forward with improvements. As we say, Media Viewer should be improved; our 
procedures to date have not yet met the high standards we want to set for 
ourselves. Lila wants to address both now, and we need to give her the space to 
do so. She has our full support and confidence as she tackles this tough 
challenge.

On behalf of the Wikimedia Board of Trustees

Jan-Bart de Vreede
Chair
Board of Trustees
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] We have an awesome Translation Tools....made for English speakers first

[Charles Andrès]

Dear all,

I would like to draw your attention on the Translation Extension for Mediawiki, 
since 2 years now, community members ask to improve this extension by adding 
the possibility to select the original language.  
https://bugzilla.wikimedia.org/show_bug.cgi?id=35489

We are in a movement where the knowledge exchange is a primary concern, we have 
a really good tools to facilitate the translation of the documentation, but 
today we are still obliged to first translate "manually" in English before 
being able to use the Translate extension.

I’m not a Tech guy, I try to read the bug's page linked before, and the only 
message I can get from is « you, non English speakers, are not our priority ».

The ability to translate in multiple language the documentation created by non 
English speakers is a major challenge, we need to make it happen more often. 

Everyday I heard French speaker saying that they do not belong to the Wikimedia 
Community because it’s all in English/all for English, I do not pretend that 
improving the Translate extension will solve this issue, but it could be a 
little step forward.

thank for your attention


Charles


___

Charles ANDRES, Chief Science Officer
"Wikimedia CH" – Association for the advancement of free knowledge –
www.wikimedia.ch
Office +41 (0)21 340 66 21
Mobile +41 (0)78 910 00 97
Skype: charles.andres.wmch
IRC://irc.freenode.net/wikimedia-ch
http://prezi.com/user/Andrescharles/


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Todd Allen]

On Aug 14, 2014 3:58 AM, "Erik Moeller"  wrote:
>
> On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride  wrote:
> > Is there anything that the German Wikipedia could do to convince you to
> > disable MediaViewer there? Some percentage of active users showing up to
> > say so? Some percentage of users (logged-in or otherwise) disabling the
> > feature? (Presumably we can get stats of some kind.)
>
> We are very open to continuing the discussion about how the feature
> should be configured, how it should be improved, and how it should be
> integrated in the site experience. Ideally we'd like to minimize
> inconsistencies between wikis (because for readers who speak more than
> one language, it's just a single site), so changes that help alleviate
> conflict or disagreement should ideally also be of the kind that in
> general are welcomed and wanted.
>

Provided they're what you would have done anyway. Otherwise, they're
"welcomed" with WONTFIX and superprotection.

> On the subject of opt-out numbers, you can see them here:
>
http://multimedia-metrics.wmflabs.org/dashboards/mmv_dewiki#opt_in_opt_out-graphs-tab
>
> As you can see, the recent drama has contributed to a significant
> increase in opt-out events. Pre-vote, about 17% of very active (>100
> edit/month) users had disabled MMV. This is about the same number of
> people who ultimately voted no, BTW, about 200. Post-vote it was 20%.
> Since then it has climbed to 23%. In contrast, about 30% of that same
> user group still use Monobook.
>

I'm glad you know why people choose to opt out. I don't see that in the
data you cited, how was that data gathered?

> I think those numbers can and should reasonably inform the default for
> logged in users, for sure. I don't think they should be used to
> determine the default for readers.
>

What should inform the default for "readers" are the communities who care
enough about those readers to volunteer millions of hours per month
generating, curating, and protecting the world's largest ever educational
work for the benefit of those very same readers. Yet WMF dismisses and
belittles those volunteers as "power users" who couldn't care less, but
hey, WE know best, now get out of our way or else!

Then, of all things, the next question is "Gee, why can't we retain good
editors and attract new ones?"

> In general, though, let's talk. The overarching principle we're not
> going to budge on is that this process is really not acceptable:
>
> 1) The UI changes
> 2) A subset of users is upset and organizes a poll/vote
> 3) The poll/vote closes with a request to undo said UI Change and a
> request is filed
> 4) WMF offers compromise or says no
> 5) A local hack is used to undo said UI change
>

Nor is this:

1) The UI changes
2) A given project rejects or requests modification to the change
3) WMF crams it right down their throat regardless.
4) Local admins do what they can to implement the consensus, as they are
selected by the community to do.
5) WMF throws a fit and threatens those admins or gives itself "super"
authority.

In your scenario, it's unacceptable that we ever reach step 5. The
community, not the WMF, must be the final authority on each project.

> That's no way to develop software, and that's no way to work together.
> If you want a WMF that slavishly implements RFCs or votes to disable
> features upon request, you'll need to petition to replace more than
> just one person. In fact, you should petition to reduce the staff
> dramatically, find an administrative ED who has no opinion on what to
> do, and exclusively focus on platform-level improvements and requests
> that clearly have community backing.
>

If there were a mechanism for a vote of no confidence, I think you'd see
exactly that take place right now. But yes, if the current WMF will not
back down from this position, we need a better one, and one with far less
power to provide a temptation for abuse. That is not a desirable outcome,
but it seems a necessary one more each day.

Except in cases where legal issues are at play, WMF must not overrule local
communities.

> This is not the org we want to be.

That's unfortunate. We have always operated as a community centered and
consensus driven project, and that has worked not only well but stunningly
well.

I am hopeful and optimistic that
> there are enough admins and regular editors who believe in a vision of
> improving the user experience iteratively, and working together
> through conflict, that we can in future entirely rely on local admins
> to prevent the kind of JS hacks we've seen here, working towards a
> proper code review and deployment mechanism that further alleviates
> the risk of escalations. Mind you, we made it very clear in this case
> ahead of time that JS hacks were unacceptable, we attempted a revert
> and a very explicit warning.
>

And we made it clear ignoring the results was unacceptable. If you want to
stop escalations, don't handwave away the people who day to day run the
projects. T

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Cuenca]

On Thu, Aug 14, 2014 at 3:35 PM, David Gerard  wrote:

> A pattern we see over and over is that the developers talk at length
> about what they're working on in several venues, then it's released
> and people claiming to speak for the community claim they were not
> adequately consulted. Pretty much no matter what steps were taken to
> do so, and what new steps are taken to do so. Because there's always
> someone who claims their own lack of interest is someone else's fault.
>

Talking in several venues about what one is doing cannot be considered
consensus building. Actually it is the opposite, because it is an extrinsic
change and as such it cannot be appropriated by any ad-hoc community. Even
worse, it gives developers the wrong impression that they are working under
general approval, when actually they might be communicating only with the
people that normally would accept their project, but not the ones that
normally would reject it.

It is of course impossible to involve everyone, but the more voices are
included the better represented will be the interests of the ones that are
not present.

Cheers,
Micru
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Board statement on the Media Viewer roll out

[Manuel Schneider]

Hi Jan-Bart,

thanks for this statement.
Thanks to all on the board and Lila working on this, the improvement of
our website and trying to recover the trust of our community.

/Manuel

Am 14.08.2014 15:42, schrieb Jan-Bart de Vreede:
> Some of you have asked the Board and its individual members for feedback. 
> Some of us are already in conversation with you or are planning to answer on 
> different pages. This is our general common statement:

[...]

-- 
Wikimedia CH - Verein zur Förderung Freien Wissens
Lausanne, +41 (21) 34066-22 - www.wikimedia.ch

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] We have an awesome Translation Tools....made for English speakers first

[Vira Motorko]

It is weird that, for example, chapters' pages on Meta should be written in
English and then translated into native language -- according to current
logic.

I agree with Charles, this change would be a step forward.
Sure, translators-l will also agree.

*Vira Motorko*

Help save natural resources - please think twice before printing this
e-mail or any attachments.


2014-08-14 16:43 GMT+03:00 Charles Andrès :

> Dear all,
>
> I would like to draw your attention on the Translation Extension for
> Mediawiki, since 2 years now, community members ask to improve this
> extension by adding the possibility to select the original language.
> https://bugzilla.wikimedia.org/show_bug.cgi?id=35489
>
> We are in a movement where the knowledge exchange is a primary concern, we
> have a really good tools to facilitate the translation of the
> documentation, but today we are still obliged to first translate "manually"
> in English before being able to use the Translate extension.
>
> I'm not a Tech guy, I try to read the bug's page linked before, and the
> only message I can get from is << you, non English speakers, are not our
> priority >>.
>
> The ability to translate in multiple language the documentation created by
> non English speakers is a major challenge, we need to make it happen more
> often.
>
> Everyday I heard French speaker saying that they do not belong to the
> Wikimedia Community because it's all in English/all for English, I do not
> pretend that improving the Translate extension will solve this issue, but
> it could be a little step forward.
>
> thank for your attention
>
>
> Charles
>
>
> ___
>
> Charles ANDRES, Chief Science Officer
> "Wikimedia CH" - Association for the advancement of free knowledge -
> www.wikimedia.ch
> Office +41 (0)21 340 66 21
> Mobile +41 (0)78 910 00 97
> Skype: charles.andres.wmch
> IRC://irc.freenode.net/wikimedia-ch
> http://prezi.com/user/Andrescharles/
>
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] Mexico facts about Wikipedia

[Ivan Martínez]

Hi folks,

For any interested, today appear in the blog Codigo Espagueti[1] a survey
about the trust in Wikipedia and the use both in Mexico and the United
States. Some facts:


   - 60% of people with internet access in Mexico has heard about Wikipedia.
   - 82% are very or somewhat confident. In contrast, only 16% have little
   or no credibility.
   - In Mexico 59% use this site to learn about different topics and 53% in
   USA.

The blog post does not indicate the method of the survey, but is a
interesting exercise.

Cheers.
[1] http://codigoespagueti.com/noticias/wikipedia-mexico-encuesta/
-- 








*Atentamente:Iván MartínezPresidenteWikimedia México A.C.wikimedia.mx
Imagina un mundo en donde cada persona del planeta
pueda tener acceso libre a la suma total del conocimiento humano. Eso es lo
que estamos haciendo . *
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Board statement on the Media Viewer roll out

[Juergen Fenn]

Only after the last editor has been been driven away
Only after the last article written by a volunteer has been published
Only after the last vandal has been reverted by a volunteer
Then will you find that money alone cannot write an encyclopædia.

See: https://de.wikipedia.org/wiki/Weissagung_der_Cree

Regards,
Jürgen.


2014-08-14 15:42 GMT+02:00 Jan-Bart de Vreede :
> Hi all,
>
> Some of you have asked the Board and its individual members for feedback. 
> Some of us are already in conversation with you or are planning to answer on 
> different pages. This is our general common statement:
>
> The Board supports the decision to protect the Media Viewer roll out. Our 
> platform powers a top-5 website. We need operational protocols that are 
> consistent with this position. This includes making improvements, rather than 
> a tendency towards reverting to the status quo.
>
> At the Board meeting before Wikimania, Lila laid out her strategy to put in 
> place best practices for product development. We will communicate sooner, we 
> will prioritize smarter, we will test more, and we will achieve better 
> outcomes. Her vision is to involve the community at each step of product 
> development, including more structured feedback stages and reviews. We 
> endorse this vision.
>
> We realize that there is concern about the superprotect user right and how it 
> affects power balance and influence on content and administration. We 
> recognize the concern that we need to explain and introduce our measures 
> better. However, stability of the platform is necessary as we seek to improve 
> our sites, and, for that reason, we support the creation of this tool. We 
> also understand that with more robust rollout plans and better staged 
> community feedback - as Lila envisions - the tool should rarely be used.
> We urge you to focus on specific improvements you'd like to see in the Media 
> Viewer and the roll-out process. Lila intends to incorporate that feedback as 
> she plans to improve Media Viewer and the process for future product roll 
> outs.
> The Wikimedia Foundation needs to be in a position to make software and 
> configuration changes for which it is responsible. We expect restrictions of 
> MediaWiki code-level editing to be a temporary step to enable us to move 
> forward with improvements. As we say, Media Viewer should be improved; our 
> procedures to date have not yet met the high standards we want to set for 
> ourselves. Lila wants to address both now, and we need to give her the space 
> to do so. She has our full support and confidence as she tackles this tough 
> challenge.
>
> On behalf of the Wikimedia Board of Trustees
>
> Jan-Bart de Vreede
> Chair
> Board of Trustees
> Wikimedia Foundation
> ___
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> 

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Board statement on the Media Viewer roll out

[Martin Rulsch]

The Board did not even consider to apologize for the rushed interference of
WMF staff on de:MediaWiki:Common.js which caused so much trouble in the
last days? No empathy for German Wikimedians who feel completely overruled
and locked out from maintaining its display and implementing community
consensus, a long established procedure btw.? No urge on WMF staff to
implement policies on who should use superprotect and when in order to
maintain our display the best, together? By just telling us that they did
what they had to do and would even repeat it identically (without warnings,
discussions, or anything) just in order to remove some bad JavaScript code
which was not covered by community consensus either and hence would have
been removed by local administrators anyway, you most likely will lose much
more trust there and globally which cannot be the goal you wanted to
achieve. Personally, I know that superprotect can be helpful in certain
circumstances because I had to deal with JavaScript abuse on Common.js'es
as a Wikimedia steward from time to time. That is why I support creating a
tool which prevents inexperienced admins from maintaining our display. But
does that necessarily be rushed which will leave an impression of attacking
the community by interfering in their originated responsibilities although
this was not intended? Without any idea which groups from now on will
maintain the display (crats? stewards? on consensus? on WMF instruction),
or does WMF staff wants to maintain all Commons.js, Vector.js, Monobook.js,
etc. on all 900 wikis alone? Some clarifications are needed in order to
solve this problem together. And that should be our goal: working together
to make Wikimedia projects are more welcome place for readers, authors, and
anyone.

Cheers,
Martin


2014-08-14 15:42 GMT+02:00 Jan-Bart de Vreede :

> Hi all,
>
> Some of you have asked the Board and its individual members for feedback.
> Some of us are already in conversation with you or are planning to answer
> on different pages. This is our general common statement:
>
> The Board supports the decision to protect the Media Viewer roll out. Our
> platform powers a top-5 website. We need operational protocols that are
> consistent with this position. This includes making improvements, rather
> than a tendency towards reverting to the status quo.
>
> At the Board meeting before Wikimania, Lila laid out her strategy to put
> in place best practices for product development. We will communicate
> sooner, we will prioritize smarter, we will test more, and we will achieve
> better outcomes. Her vision is to involve the community at each step of
> product development, including more structured feedback stages and reviews.
> We endorse this vision.
>
> We realize that there is concern about the superprotect user right and how
> it affects power balance and influence on content and administration. We
> recognize the concern that we need to explain and introduce our measures
> better. However, stability of the platform is necessary as we seek to
> improve our sites, and, for that reason, we support the creation of this
> tool. We also understand that with more robust rollout plans and better
> staged community feedback - as Lila envisions - the tool should rarely be
> used.
> We urge you to focus on specific improvements you'd like to see in the
> Media Viewer and the roll-out process. Lila intends to incorporate that
> feedback as she plans to improve Media Viewer and the process for future
> product roll outs.
> The Wikimedia Foundation needs to be in a position to make software and
> configuration changes for which it is responsible. We expect restrictions
> of MediaWiki code-level editing to be a temporary step to enable us to move
> forward with improvements. As we say, Media Viewer should be improved; our
> procedures to date have not yet met the high standards we want to set for
> ourselves. Lila wants to address both now, and we need to give her the
> space to do so. She has our full support and confidence as she tackles this
> tough challenge.
>
> On behalf of the Wikimedia Board of Trustees
>
> Jan-Bart de Vreede
> Chair
> Board of Trustees
> Wikimedia Foundation
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Mexico facts about Wikipedia

[Tanweer Morshed]

Thanks Ivan for sharing the interesting survey. After Britain, the survey
in Mexico and US unveils that Wikipedia is still a major online platform
for learning and majority of people have faith on it.

Regards,
Tanweer


On Thu, Aug 14, 2014 at 8:16 PM, Ivan Martínez  wrote:

> Hi folks,
>
> For any interested, today appear in the blog Codigo Espagueti[1] a survey
> about the trust in Wikipedia and the use both in Mexico and the United
> States. Some facts:
>
>
>- 60% of people with internet access in Mexico has heard about
> Wikipedia.
>- 82% are very or somewhat confident. In contrast, only 16% have little
>or no credibility.
>- In Mexico 59% use this site to learn about different topics and 53% in
>USA.
>
> The blog post does not indicate the method of the survey, but is a
> interesting exercise.
>
> Cheers.
> [1] http://codigoespagueti.com/noticias/wikipedia-mexico-encuesta/
> --
>
>
>
>
>
>
>
>
> *Atentamente:Iván MartínezPresidenteWikimedia México A.C.wikimedia.mx
> Imagina un mundo en donde cada persona del planeta
> pueda tener acceso libre a la suma total del conocimiento humano. Eso es lo
> que estamos haciendo . *
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 




-- 
Regards -
Tanweer Morshed
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] How to change the world

[Andrea Zanni]

This is a talk from Rick Falkvinge, founder of the Swedish Pirate Party, at
the TEDx in Oslo last year.
I thought it was worth sharing with you all:
http://tedxtalks.ted.com/video/Changing-the-world-through-swar

It would be really interesting to apply these methods within Chapters and
the overall Wikimedia community :-)

Hope to see you soon again,
always great to be at Wikimania.

Aubrey
Wikimedia Italia
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Richard Farmbrough]

Erik said:

>We are very open to continuing the discussion about how the feature
>should be configured, how it should be improved, and how it should be
>integrated in the site experience

The message that is being given, though is, to quote Mathilda "I'm smart;
you're dumb; I'm big, you're little; *I'm right, you're wrong*, and there's
nothing you can do about it."

And this continues in this post.  Assuming for example that those who do
not opt-out "support" the media viewer.

Let me just make my position on the media viewer clear, since I am being
uncharacteristically vocal on this subject.  I am undecided, but I think it
is probably a good thing.  However when I hear respected communities saying
there are functional and legal problems, I am inclined to believe them.  I
support therefore the "not-yet" faction.  Personally I find it irritating
(and at the same time potentially very cool), but I keep it on because I
want to see what the bulk of our readers see.

So there are interconnecting layers of issues here - and I think they are
clear, but I will lay them out in case we are talking at cross purposes.

1. Erik's actions.  This sort of thing happens a lot on on-line communities
(and elsewhere - see the Crimea!)  and I did not get too excited about the
socially inept blundering on en:WP.  But to repeat the same script on
German Wikipedia within a few days shows a lack of wisdom unbecoming to
"Deputy Director".

2. The specific question of Media Viewer.  That I believe can be resolved,
and is all about "not yet", it should never have been allowed to cause
drama. I would like to see some metrics for the value delivered by the
Media Viewer, though, rather than "Flikr does it, it must be good".  I am
disappointed after a mostly unusable Visual Editor was released with
content breaking bugs that another project is being forced down the same
path - Erik's comment "That's no way to develop software" rings rather
hollow in this context.

3.  The ongoing question of software development.  The WMF is supposed to "to
empower and engage" the communities to  disseminate content "effectively
and globally."  It is not supposed to run with its own agenda.  Bugs and
feature requests by the community are allowed to stand unattended for years
- one was closed (WONTFIX) because of an off-hand comment made by a dev on
a mailing list!  Meanwhile "nice to have" features absorb apparently huge
amounts of financial and staff resoruces. In the style re-work, extensive
feedback was solicited and provided - and ignored when it didin't suit.
(Notably a/b testing, mixing serif and sans, and using typefaces where the
glyphs are more distinct)

4. The culture at the Foundation needs to be more focussed on collaborative
and collegial work with the communities. The Foundation  is an essential
part of the Movement, if it did not exist it would be necessary to invent
it.  However it is not the senior partner, certainly not in terms of age or
resource, and, due to the open licensing, not in content.  To work
effectively with the community the Foundation needs to consider the
community as its customer, be responsive to its needs and wants, in this
way it can deliver on its charitable objectives.

Note: This does not mean a namby-pamby relationship, but rather a robust
one, where evidence based decisions can be made jointly and collegialy.
Indeed one value add from having an organisation like the WMF is the
resource to gather significant evidence on usability, readability,
accessibility, clarity, interrogability and so forth.


On 14 August 2014 14:35, David Gerard  wrote:

> On 14 August 2014 13:56, David Cuenca  wrote:
>
> > It would be more sensible to let contributors participate in the tech
> > roadmap in more formal and empowered way than now, because without that
> > early participation there is no possibility for later consensus.
>
>
> A pattern we see over and over is that the developers talk at length
> about what they're working on in several venues, then it's released
> and people claiming to speak for the community claim they were not
> adequately consulted. Pretty much no matter what steps were taken to
> do so, and what new steps are taken to do so. Because there's always
> someone who claims their own lack of interest is someone else's fault.
>
>
> - d.
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>



-- 
Landline (UK) 01780 757 250
Mobile (UK) 0798 1995 792
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] Superprotect user right, Coming to a wiki near you

[Tim Davenport]

Re: Erik Möller's remark: "In general, though, let's talk. The overarching
principle we're not
going to budge on is that this process is really not acceptable:

1) The UI changes
2) A subset of users is upset and organizes a poll/vote
3) The poll/vote closes with a request to undo said UI Change and a
request is filed
4) WMF offers compromise or says no
5) A local hack is used to undo said UI change

That's no way to develop software, and that's no way to work together"

=

I could spend 10,000 words on this. I'll try to keep it (comparatively)
short.


The reason this dysfunctional situation develops, Erik, is because there
are no steps A, B, C, D, E, F, and G preceding #1 on the list.

As things currently stand, this is the way the software development process
at WMF seems to me to work:

* Engineers collecting paychecks obviously need something to do.
* Someone comes up with a bright idea that sounds good on paper.
* Engineers decide to make that idea a reality and start work.
* Inadequately tested software, sometimes of dubious utility, is
unilaterally imposed on volunteers.
* If new software is problematic enough, volunteers revolt by any means
necessary.
* WMF forces changes down throat of volunteers by any means necessary.

This is truly "no way to develop software" and "no way to work together."

-

Here is the way the process SHOULD begin:

* WMF staffers, plural, identify by user names/IP addresses the 10,000 or
so very active volunteers across all projects and database them.

* WMF staffers further divide this group into coherent "types": content
writers, gnome-type copy editors, structural adapters (template people, bot
operators, etc.), quality control workers (NPP, AfD), vandal fighters,
behavioral administrators (ArbCom, Ani, the various Admin pages), and drone
bees who do nothing but Facebook-style drama mongering. Multiple categories
may apply to single individuals and this list is not necessarily exhaustive.

* Once identified, WMF staffers frequently and regularly poll very active
users in each category about WHAT THEY NEED. Different surveys for
different volunteer types.

* Software development starts ONLY when a real need is identified.

* Software should be introduced on En-WP, De-WP, or Commons ONLY when it is
Alpha-grade, debugged and ready to roll. (Test things on the smaller Wikis
first).

-

Moreover, there should be some polling mechanism to summarize and analyze
what the 500 million or whatever readers worldwide feel that they like and
feel they are missing. "User experience" changes with primary impact on
readers rather than volunteers (such as MediaViewer) should be made with
them in mind first and foremost; editing and structural tools should be
made to actually assist the active volunteers, not created on a whim.

Sometimes the needs of the Readers and the needs of the Volunteers are
different, let us frankly say. In no case should WMF assume the views and
criticism of the latter are insignificant or wrong simply because
500,000,000 > 10,000.

Remember this because according to the same logic: 10,000 > 240.

-

We all agree that we need a bigger pool of very active volunteers. Most
readers are never going to be very active volunteers, nor do we want them
to be, since we need specialized skill sets. Most people using the editing
software are only going to make one or a very few changes a year and they
are never going to even "see" the backstage world of Wikipedia. That is
normal and fine.

We do need expert contributors on esoteric topics and we need solid
contributors from the developing world and we need to replenish the people
doing copy editing and quality control work.

We don't need tools that nobody asked for and nobody wants shoved down our
throats just because engineers needed something to do.



240 Paid Staff + 10,000 Serious Volunteers + 500,000,000 Readers and
occasional minor contributors

Three groups with differing needs.


Tim Davenport /// "Carrite" on WP /// "Randy from Boise" on WPO
Corvallis, OR
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

[Mike Godwin]

Henning writes:

> To describe Eric's action I am tempted to use a
> metaphor that includes black uniforms and heavy boots. But that would
> not be appropriately written by a German to a German.

My experience over the last quarter century suggests that this
metaphor rarely works out well.


--Mike Godwin

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

[Andrea Zanni]

On Thu, Aug 14, 2014 at 5:37 PM, Mike Godwin  wrote:

> Henning writes:
>
> > To describe Eric's action I am tempted to use a
> > metaphor that includes black uniforms and heavy boots. But that would
> > not be appropriately written by a German to a German.
>
> My experience over the last quarter century suggests that this
> metaphor rarely works out well.


I'm sorry, can I say "LOL"?

Cheers, Aubrey

>
>
> --Mike Godwin
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

[Trillium Corsage]

14.08.2014, 13:33, "Ziko van Dijk" :
> Henning,
>
> "To describe Eric's action I am tempted to use a
> metaphor that includes black uniforms and heavy boots. But that would
> not be appropriately written by a German to a German."
>
> You may find yourself very smart with this kind of wording. Let me
> tell you from a North German to a North German: "Dat bisse nich."

Man musst nicht Norddeutscher sein verstehen zu koennen dass das 
Quatschvergleichung ist.

Trillium Corsage

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Board statement on the Media Viewer roll out

[Richard Farmbrough]

This is all very nice "going forward", but it completely misses the salient
points.

1. It is an egregious social blunder to act as Erik has done - he
apologised (sort of) on  the English Wiki, he should at the very least have
the grace to do so on the German,

2. There are concerns about the MV software breaking attribution (among
other things).  These need to be taken seriously.  I am not familiar with
the detail, but if they are supported by fact the Media VIewer should be
withdrawn until it is fixed. Breaking the law is not what the free content
movement is about.

3. The Mediawiki community are knowledgeable, intelligent and experienced
as a group.  They are not objecting because they are reactionary old farts,
but because there are significant issues.  It is standard software
development practice to have a roll-back plan in place in case of just such
an event.  It is not and should not be seen as a "defeat" or "climbdown" to
disable a new component while  improvements are made.  It is a learning
opportunity.

4. Superprotect. The suggestion that all software on the projects needs to
go through code review is absurd posturing that points up the cultural
difficulties.  If there are features that should not be accesible to
Admins, then the software should not expose them.  Traditionally, though,
such features have resulted in a divisive environment with chages to
configuration requested and denied by devs on the grounds that "we know
best".

5. Development.  Note that the community does not have head-to-head clashes
with legal, financial and other parts of the Foundation. The development
team includes some of the best and the brightest of Wikipedians recruited
over the years.  I have had the pleasure of talking to several of them at
Wikimanias, and despite the fact that they are lovely people, there is a
sense that they have become increasingly out of touch with the  community,
and convinced that they are the guardians of the one-true-flame.  I might
cite the developer  who changed his mind three times during the Hifa
Wikimania over the solution to the "parser function" problem.  His sole
decision  resulted in considerable effort being directed in a way that took
years to deliver a result, when what we were asking for could have been
delivered in ten minutes.

6.Mission statement. The mission is to "encourage and empower" the
community.  Not to bully and coerce it. I believe that during the time the
WMF has turned its gaze outwards, to attempt (mostly unsuccessfully) to
grow and diversify the editor base it lost focus on its mission.  We need
to refocus so that the WMF can encourage and empower the community
efficiently.  We need to ask the difficult questions on Gender Gap, on
content, on translation, on advocacy, on wiki-culture - and yes on HCI
too.  We need to work with academic partners, talented volunteers,
contractors and staff  to build evidence on which to base our decisions.
We need to build the software development structure Lila talks of.  We need
to engage in content building strategies.  All this will be a thousand
times as fruitful with an "encourage and empower" dynamic than  the present
confrontational one.

All the best, Rich Farmbrough.



On 14 August 2014 15:00, Manuel Schneider 
wrote:

> Hi Jan-Bart,
>
> thanks for this statement.
> Thanks to all on the board and Lila working on this, the improvement of
> our website and trying to recover the trust of our community.
>
> /Manuel
>
> Am 14.08.2014 15:42, schrieb Jan-Bart de Vreede:
> > Some of you have asked the Board and its individual members for
> feedback. Some of us are already in conversation with you or are planning
> to answer on different pages. This is our general common statement:
>
> [...]
>
> --
> Wikimedia CH - Verein zur Förderung Freien Wissens
> Lausanne, +41 (21) 34066-22 - www.wikimedia.ch
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>



-- 
Landline (UK) 01780 757 250
Mobile (UK) 0798 1995 792
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Yaroslav M. Blanter]

On 14.08.2014 15:35, David Gerard wrote:

On 14 August 2014 13:56, David Cuenca  wrote:


It would be more sensible to let contributors participate in the tech
roadmap in more formal and empowered way than now, because without 
that

early participation there is no possibility for later consensus.



A pattern we see over and over is that the developers talk at length
about what they're working on in several venues, then it's released
and people claiming to speak for the community claim they were not
adequately consulted. Pretty much no matter what steps were taken to
do so, and what new steps are taken to do so. Because there's always
someone who claims their own lack of interest is someone else's fault.


- d.



This is actually not correct. Take pending changes on the English 
Wikipedia as an example - people used to complain a lot on how RfC's 
were closed, but this is the business of the community. I have never 
heard anybody complaining that the trial sucked, or that PC itself does 
not work properly. There was a discussion, there was a trial, everything 
was properly announced, and everything from the developers's side was 
done perfectly or close to perfectly.


Take Phase I Wikidata - this is smth I was actively participating in 
and watched it from the close distance. Everything went smoothly, with 
the Hungarian Wikipedia trial starting first, the Italian Wikipedia a 
bit later, when feedback was taken into account, and then other 
Wikipedias followed. Again, no problem with the developers whatsoever.


Now compare this with VE, AFT, Mediaviewer, and Flow will be probably 
the next disaster of a comprable scale - despite the fact that WMF is 
pretty open about Flow, and there are many people answering questions 
basically in real time.


Cheers
Yaroslav

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

[Peter Southwood]

It would work for me.
Peter Southwood

-Original Message-
From: wikimedia-l-boun...@lists.wikimedia.org 
[mailto:wikimedia-l-boun...@lists.wikimedia.org] On Behalf Of rupert THURNER
Sent: 13 August 2014 07:21 PM
To: Wikimedia Mailing List
Subject: Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

Am 13.08.2014 15:56 schrieb "Magnus Manske" :
>
> On Wed, Aug 13, 2014 at 6:51 AM, rupert THURNER 
> 
> wrote:
>
> > On Tue, Aug 12, 2014 at 6:26 PM, Erik Moeller 
wrote:
> > > On Tue, Aug 12, 2014 at 4:57 PM, Magnus Manske 
> > >  wrote:

> > >> It's probably fine for "modern" viewing, although it's hard to 
> > >> guess
> > that
> > >> you get to the file page via the little Commons icon for people 
> > >> who
(in
> > all
> > >> likelihood) have never seen that icon, or visited Commons.
> >
> > > Indeed, the icon to the File: page is currently very opaque. We're 
> > > preparing for a round of possible changes to the viewing 
> > > experience, potentially including
> > > - moving caption above the fold so readers don't have to hunt for 
> > > it
> > > - moving disable action above-the-fold
> > > - potentially eliminating the below-the-fold panel entirely
> > > - emphasizing the File: page more prominently as the canonical 
> > > source of metadata
> > > - separating out download/use actions more clearly
> > >
> > > These changes will need to be carefully tested/validated. If you 
> > > want to take a look at an early early (!) prototype (!!), see 
> > > http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but 
> > > please
> >
> > magnus, do these changes make you turn it on again? if not, what 
> > would
need
> > to be better?
> >
>
> I think this is a non-issue. It took one click to get to the image 
> page; now it takes two. That's my main "problem" with it.
> As I said, I'm not the target audience for this. I hope.

to give back the one click experience one would need two entry points. a tab or 
a toolbox link to start mediaviewer, and standard behavior on the images. for 
one link more in the gui everybody would be happy?

rupert
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4744 / Virus Database: 4007/8026 - Release Date: 08/13/14


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Gerard]

On 14 August 2014 16:27, Richard Farmbrough  wrote:

> 3.  The ongoing question of software development.  The WMF is supposed to "to
> empower and engage" the communities to  disseminate content "effectively
> and globally."  It is not supposed to run with its own agenda.  Bugs and
> feature requests by the community are allowed to stand unattended for years
> - one was closed (WONTFIX) because of an off-hand comment made by a dev on
> a mailing list!  Meanwhile "nice to have" features absorb apparently huge
> amounts of financial and staff resoruces. In the style re-work, extensive
> feedback was solicited and provided - and ignored when it didin't suit.
> (Notably a/b testing, mixing serif and sans, and using typefaces where the
> glyphs are more distinct)


Although I concur with Erik's and WMF's actions in this particular
case (and I really don't see how it could have worked out any other
way), it's worth noting for the general case that local communities
*do* need to be able to add local enhancements to MediaWiki - because
the developers, WMF and volunteer, simply don't scale. This has been
observable even for simple administrative actions that happen to
require shell use, let alone adding new functionality.

So locally-editable site JavaScript, for locally-important gadgets and
so forth, is in fact something that's needed. This particularly
applies to non-Wikipedia wikis that get no paid developer attention
from WMF.

Of course, in an ideal world this would be later reviewed and possibly
centralised. But blocking it in general will immediately make
Wikimedia sites worse, not better, in important ways.


- d.

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Marc A. Pelletier]

On 08/14/2014 02:36 PM, David Gerard wrote:
> So locally-editable site JavaScript, for locally-important gadgets and
> so forth, is in fact something that's needed.

That seems reasonable, but it's less clear to me that this should be
bundled with / part of the 'editinterface' right, at least as it is
currently managed (the ability to be able to change wording of system
message is only related to being able to change javascript/CSS by way of
hysterical raisins).

Regardless of which process, in the end, is adopted to make management
of sitewide customization to javascript etc, separating that from
"normal" editinterface seems to me to be prerequisite.

-- Marc


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Gerard]

On 14 August 2014 20:27, Marc A. Pelletier  wrote:
> On 08/14/2014 02:36 PM, David Gerard wrote:

>> So locally-editable site JavaScript, for locally-important gadgets and
>> so forth, is in fact something that's needed.

> That seems reasonable, but it's less clear to me that this should be
> bundled with / part of the 'editinterface' right, at least as it is
> currently managed (the ability to be able to change wording of system
> message is only related to being able to change javascript/CSS by way of
> hysterical raisins).
> Regardless of which process, in the end, is adopted to make management
> of sitewide customization to javascript etc, separating that from
> "normal" editinterface seems to me to be prerequisite.


This is true, but prerequisite to what? What I'm saying is that
switching off local scripting in general until [unspecified condition]
is met is going to be an immediately bad thing for every WMF wiki that
doesn't get lots of WMF attention, which is most of them. So that's a
thing that shouldn't be done just because admins on two wikis are
acting like my daughter just before I withdraw her computer access.


- d.

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] [Wikimedia Announcements] This Month in GLAM: July 2014

[The 'This Month in GLAM' team]

*This Month in GLAM* is a monthly newsletter documenting recent happenings
within the GLAM project, such as content donations, residencies, events and
more. GLAM is an acronym of *G*alleries, *L*ibraries, *A*rchives and *M*useums.
You can find more information on the project at glamwiki.org.

*This Month in GLAM – Issue VII, Volume IV – July 2014*
--


France report: Mass-upload
http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/France_report

Germany report: Exhibition photography
http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/Germany_report

Italy report: Reaching museums' national associations
http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/Italy_report

Netherlands report: Expedition Wikipedia content donations and course;
Naturalis; GLAMwiki Toolset Workshop
http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/Netherlands_report

Sweden report: Slow summer in Sweden
http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/Sweden_report

UK report: Skye boat song, tanks, feminist film, surgery for skeptics and
survey results
http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/UK_report

USA report: New York City Report
http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/USA_report

Open Access report: JATS 4 Reuse; Automated import into Wikisource and
Commons
http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/Open_Access_report

Calendar: August's GLAM events
http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/Events


--


Single page view
http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Single

Twitter
http://twitter.com/ThisMonthinGLAM

Add your story / Work on the next edition
http://outreach.wikimedia.org/wiki/GLAM/Newsletter/Newsroom


-- 
The *This Month in GLAM* team
http://outreach.wikimedia.org/wiki/GLAM/Newsletter
___
Please note: all replies sent to this mailing list will be immediately directed 
to Wikimedia-l, the public mailing list of the Wikimedia community. For more 
information about Wikimedia-l:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
___
WikimediaAnnounce-l mailing list
wikimediaannounc...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Chris Keating]

On 14 Aug 2014 14:50, "David Cuenca"  wrote:
>
> On Thu, Aug 14, 2014 at 3:35 PM, David Gerard  wrote:
>
> > A pattern we see over and over is that the developers talk at length
> > about what they're working on in several venues, then it's released
> > and people claiming to speak for the community claim they were not
> > adequately consulted. Pretty much no matter what steps were taken to
> > do so, and what new steps are taken to do so. Because there's always
> > someone who claims their own lack of interest is someone else's fault.
> >
>
> Talking in several venues about what one is doing cannot be considered
> consensus building. Actually it is the opposite, because it is an
extrinsic
> change and as such it cannot be appropriated by any ad-hoc community. Even
> worse, it gives developers the wrong impression that they are working
under
> general approval, when actually they might be communicating only with the
> people that normally would accept their project, but not the ones that
> normally would reject it.

how should this be solved?

To me it's saying that no matter who is informed, the WMF can never expect
that their work won't be overruled.

That is problematic (regardless of who has the final authority)


> Cheers,
> Micru
> ___
> Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] Deployment targets and preferences (was: Superprotect user right, Comming to a wiki near you)

[Seb35]

Hi,

I propose some constructive ideas to improve the deployment of new features:

* granular deployments: create "user profiles" where the users can choose
  if they want an overall appearance:
  * "never ever change my interface": some experienced authors do not like
 when one change every month their workflow if they are happy with it,
  * "experienced editor": some experienced editors want new features or see
 what the newbies see,
  * "newbie": the newbies/editors-to-be could expect an editing environment
 possibly different than the reader environment,
  * "reader": the readers have their own expectations for easy reading,
  * etc.
  The features could be deployed only for some groups, giving more flexibility
  to deploy "reader features" for readers, etc. Obviously there are
  preferences, but the newbies have no experience about it, and the
  experienced editors have to be discover new preferences on a case-by-case
  basis, making it difficult to everybody to track the preferences.

* implement global preferences (and the possibility to change locally or
  globally, like in Mailman) [bug 14950][]

* when a new feature is introduced, propose to users (not in "never ever
  change my interface") if they want the new feature, locally or globally,
  possibly using the Notifications bar, or with some message in the prefs
  page and highlighting it on the prefs page

* work on a better organisation of the preferences, e.g. add an exhaustive
  preference panel similarly to Firefox’s about:config to permit the
  developers to add more preferences and hence offering more customisation
  possibilities for advanced users, by nullifying the argument "the
  preferences page is too complicated for new users"

* as it was proposed, add a review process for the gadgets+JS pages to avoid
  performance, security, usability issues, possibly with the help of the tech
  staff, and possibly with the general MediaWiki code review
  (gerrit/Phabricator) with some gateway between it and the MediaWiki
  websites [bug 69445][] [bug 20153][]


In other words, improve the deployment targets and give easy choices to users
to opt-in/opt-out/etc the new features depending on their willingness to
change their environment.

And although I’m neither a loudly people neither the community, I vote to
remove the superprotect right and any other enforcement of this type in the
future. It’s like an edit war where one party has the power to silence the
other, and like all edit wars there are at least two wrong versions.


[bug 69445]: https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
[bug 14950]: https://bugzilla.wikimedia.org/show_bug.cgi?id=14950
[bug 20153]: https://bugzilla.wikimedia.org/show_bug.cgi?id=20153

~ Seb35

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Isarra Yos]

On 14/08/14 16:07, Yaroslav M. Blanter wrote:
This is actually not correct. Take pending changes on the English 
Wikipedia as an example - people used to complain a lot on how RfC's 
were closed, but this is the business of the community. I have never 
heard anybody complaining that the trial sucked, or that PC itself 
does not work properly. There was a discussion, there was a trial, 
everything was properly announced, and everything from the 
developers's side was done perfectly or close to perfectly.


Take Phase I Wikidata - this is smth I was actively participating in 
and watched it from the close distance. Everything went smoothly, with 
the Hungarian Wikipedia trial starting first, the Italian Wikipedia a 
bit later, when feedback was taken into account, and then other 
Wikipedias followed. Again, no problem with the developers whatsoever.


Now compare this with VE, AFT, Mediaviewer, and Flow will be probably 
the next disaster of a comprable scale - despite the fact that WMF is 
pretty open about Flow, and there are many people answering questions 
basically in real time.


Cheers
Yaroslav


It may be that specific teams, not just legal and whatnot but also 
including within engineering itself, are better at handling this sort of 
thing than others. Have there been any patterns with how well things go 
depending on who is involved? If so, perhaps the others could learn from 
them...


-I

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[svetlana]

On Thu, 14 Aug 2014, at 23:35, David Gerard wrote:
> On 14 August 2014 13:56, David Cuenca  wrote:
> 
> > It would be more sensible to let contributors participate in the tech
> > roadmap in more formal and empowered way than now, because without that
> > early participation there is no possibility for later consensus.
> 
> 
> A pattern we see over and over is that the developers talk at length
> about what they're working on in several venues, then it's released
> and people claiming to speak for the community claim they were not
> adequately consulted. Pretty much no matter what steps were taken to
> do so, and what new steps are taken to do so. Because there's always
> someone who claims their own lack of interest is someone else's fault.
> 
> 
> - d.

How could presence of interest help people to fix media viewer?
From its early beta testing, I wrote numerous feedback about how going 
fullscreen is a misleading redundant step.
It was not implemented.
What more interest could I have?

It's not like I care about this too much, but I'm curious as to what you expect 
me to be able to do to display my "interest".

svetlana

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[svetlana]

On Fri, 15 Aug 2014, at 09:47, svetlana wrote:
> On Thu, 14 Aug 2014, at 23:35, David Gerard wrote:
> > On 14 August 2014 13:56, David Cuenca  wrote:
> > 
> > > It would be more sensible to let contributors participate in the tech
> > > roadmap in more formal and empowered way than now, because without that
> > > early participation there is no possibility for later consensus.
> > 
> > 
> > A pattern we see over and over is that the developers talk at length
> > about what they're working on in several venues, then it's released
> > and people claiming to speak for the community claim they were not
> > adequately consulted. Pretty much no matter what steps were taken to
> > do so, and what new steps are taken to do so. Because there's always
> > someone who claims their own lack of interest is someone else's fault.
> > 
> > 
> > - d.
> 
> How could presence of interest help people to fix media viewer?
> From its early beta testing, I wrote numerous feedback about how going 
> fullscreen is a misleading redundant step.

confusing wording; i mean: they still coded it to go fullscreen nomatter what
i wanted them to have a dialog of sorts instead

> It was not implemented.
> What more interest could I have?
> 
> It's not like I care about this too much, but I'm curious as to what you 
> expect me to be able to do to display my "interest".
> 
> svetlana

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Mexico facts about Wikipedia

[Nurunnaby Hasive]

Great news Ivan!


On Thu, Aug 14, 2014 at 8:50 PM, Tanweer Morshed 
wrote:

> Thanks Ivan for sharing the interesting survey. After Britain, the survey
> in Mexico and US unveils that Wikipedia is still a major online platform
> for learning and majority of people have faith on it.
>
> Regards,
> Tanweer
>
>
> On Thu, Aug 14, 2014 at 8:16 PM, Ivan Martínez  wrote:
>
> > Hi folks,
> >
> > For any interested, today appear in the blog Codigo Espagueti[1] a survey
> > about the trust in Wikipedia and the use both in Mexico and the United
> > States. Some facts:
> >
> >
> >- 60% of people with internet access in Mexico has heard about
> > Wikipedia.
> >- 82% are very or somewhat confident. In contrast, only 16% have
> little
> >or no credibility.
> >- In Mexico 59% use this site to learn about different topics and 53%
> in
> >USA.
> >
> > The blog post does not indicate the method of the survey, but is a
> > interesting exercise.
> >
> > Cheers.
> > [1] http://codigoespagueti.com/noticias/wikipedia-mexico-encuesta/
> > --
> >
> >
> >
> >
> >
> >
> >
> >
> > *Atentamente:Iván MartínezPresidenteWikimedia México A.C.wikimedia.mx
> > Imagina un mundo en donde cada persona del planeta
> > pueda tener acceso libre a la suma total del conocimiento humano. Eso es
> lo
> > que estamos haciendo . *
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
>
>
>
>
> --
> Regards -
> Tanweer Morshed
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>



-- 
*Nurunnaby Chowdhury Hasive*
Administrator | Bengali Wikipedia

Member | IEG Committee, Wikimedia Foundation

Social Media Interaction Moderator | The Daily Prothom-Alo

Bangladesh Ambassador | Open Knowledge Foundation Network

Treasurer | Bangladesh Open Source Network (BdOSN) 
Task Force Member | Mozilla Bangladesh 
fb.com/nhasive | @nhasive  | Skype: nhasive
| www.nhasive.com
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Mark]

On 8/14/14, 3:35 PM, David Gerard wrote:

On 14 August 2014 13:56, David Cuenca  wrote:


It would be more sensible to let contributors participate in the tech
roadmap in more formal and empowered way than now, because without that
early participation there is no possibility for later consensus.


A pattern we see over and over is that the developers talk at length
about what they're working on in several venues, then it's released
and people claiming to speak for the community claim they were not
adequately consulted. Pretty much no matter what steps were taken to
do so, and what new steps are taken to do so. Because there's always
someone who claims their own lack of interest is someone else's fault.


I actually have not found the "beta feature" feedback pages to be very 
responsive. Is that what you had in mind? I've made an attempt to be on 
top of these things and discuss them before the rollout, lest I come to 
the party late and unhelpfully. But the beta-feature talk pages are full 
of people with questions and problems and no responses or solutions, or 
really any signs of life from anyone in a position to do anything.


On the plus side, I was driven by this frustration to figure out what 
"git" and "gerrit" are. A simple bug in December rendered the beta 
"Nearby" feature completely unusable for weeks. There were many comments 
on the Talk page for that feature complaining that it had semi-recently 
become completely broken. But nobody seemed to be acknowledging, 
explaining, or making any effort to fix it. I eventually dug into the 
matter and discovered that the recently introduced problem was obvious 
and the fix was literally a 2-line patch. Then I spent about 1000x more 
time than it took to author the 2-line patch to figure out how to submit 
these two lines through git/gerrit bureaucracy. But being sufficiently 
annoyed, I did manage to submit a patch, which was eventually applied, 
and after some delay that fixed the brokenness. But that experience led 
me to believe that nobody is really paying attention to beta feedback!


-Mark


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Board statement on the Media Viewer roll out

[svetlana]

On Thu, 14 Aug 2014, at 23:42, Jan-Bart de Vreede wrote:
> At the Board meeting before Wikimania, Lila laid out her strategy to put in 
> place best practices for product development. We will communicate sooner, we 
> will prioritize smarter, we will test more, and we will achieve better 
> outcomes.
> Her vision is to involve the community at each step of product development, 
> including more structured feedback stages and reviews. We endorse this vision.

Thanks Lila! Hope to see this in clear action very soon.

svetlana

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] Special:PageLanguage (was: [Translators-l] We have an awesome Translation Tools....made for English speakers first)

[svetlana]

On Fri, 15 Aug 2014, at 00:52, Niklas Laxström wrote:
> Translate extension has supported for a long time having any language
> as the source language. There just has not been an interface in
> MediaWiki to set the source language of a page.
> 
> The good news is that Kunal Grover, a GSoC student has created
> Special:PageLanguage to do just that. [1] I expect it will be
> available quite soon.
> [...]
> 
> [1] https://www.mediawiki.org/wiki/User:Kunalgrover05/Progress_Report

On Fri, 15 Aug 2014, at 01:50, Philippe Verdy wrote:
> This is good development, but I don't see why we need a special page to
> define what is metadata of the page itself.
> [...]

Yes, I have same question.

On Fri, 15 Aug 2014, at 01:50, Philippe Verdy wrote:
> May be it will be accessible
> from the VisualEditor; like we edit categories, but such metadata is a
> general need for lots of other applications. The general need would be to
> be able to associate metadata with a symbolic type to any page: just a few
> metadata is currently handled in MediaWiki: categories, default
> sortkeys, interwiki links, plus a few other flags inserted by using magic
> words (like __NOINDEX__).
> 
> There are also external metadata stored in Wikidata for some wiki projects.
> More are needed (e.g. for different typing sort keys).
> Any way I expect to see soon a reliable way to detect the page language
> including for translated pages; but more importantly for sources of
> translations without having to assume they are in English, or create thme
> in another language and creating a pseudo-translation to the original
> language by copying keys, then modifying the English source again but
> keeping the original text.
> At least, when we mark a new page for translation, we should immediately
> have an option asking in which language is the source; if it's not specifid
> by the new experimental Special:PageLanguage page (which is not necessarily
> needed).
> 
> And once a source page has been marked for translation, the Translate tool
> should have a simple API to query its language or the language used in the
> generated translations, And ideally, we should be able to swithc from one
> source language to another (for example some projects start in English, but
> are later managed in German or Chinese, or a local Chapter initially
> creates documents in its own local language such as French, Hindi or
> Spanish, and will not use English as the reference (this is important for
> pages reporting local projects mostly done in other languages, outside
> countries or regions with a majority of native English-speakers, i.e: most
> countries of the world, including Europe (and even North America where
> French and Spanish are very present too ; Spanish and Chinese are also
> growing fast in US, and here there are aslo local communities that would
> like to promote their own local projects in their native non-English tongue
> : do you remember that US does not have any "official" language ?).

Kunal Grover, could you please fill in about that?

svetlana


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] Statement on CIS-A2K's FDC proposal discussion

[Vishnu]

Dear Wikimedians,

We have put out a statement on the CIS-A2K's FDC proposal discussion 
here [1]. As you will note the statement reflects on some of the 
critical points of feedback that we received and outlines the steps that 
we have taken and plan to take.


On behalf of everyone at CIS, we thank the Wikimedians, WMIN EC, FDC 
Staff, FDC Members and the WMF Board who actively engaged with our FDC 
proposal. We have learnt some useful lessons because of the FDC 
discussions and assure you that we will continue to improve upon our 
programmatic efficiency, efficacy, accountability and transparency.


Apologies, that this mail is coming at least a couple of weeks late.

Best,
Vishnu [[User:Visdaviva]]
Program Director (A2K)
CIS, India

[1] http://bit.ly/1m0fQn0

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

[Gerard Meijssen]

Hoi,
I am getting so pissed off.

Let us be realistic. The user experience sucks ... It sucks big time and
even though the "community" is comfortable with it, it impedes the use by
the people we do it all for. They are the READERS.. they are not the
editors and the least this is done for are the people who are so indignant
because their experience changes.

When you look at the last year, the biggest changes are driven by the
development for mobiles. The projections make it plain this is where our
customers will be. The existing Wikipedia with its monobook and what have
you skin will not be seen, used or be relevant to them. Our traffic is
transitioning to mobile. Editing starts to happen on mobile and if it is
not clear to the "community" that future development will be in this
direction they live under a rock or they are in denial.

Have a look at a Commons page on a mobile.. It is beyond bad and beyond
useful. With the Multimedia viewer it becomes useful. (NB there are things
in there that are brain dead but that is a different story)

WAKE UP. Our world is changing. Trying to shame the WMF development in a
different direction is counter productive, ill considered and even
destructive. When you are the "community", and when this is new to you, I
hope you will sit back for a moment and consider this.  When this does not
make a difference to you, there is always the right of departure. In my
brutal opinion we have no option but to move towards a more mobile centred
appreciation. The alternative is stagnation and irrelevance. That does not
need to happen when we accept that the world changes around us.
Thanks,
 GerardM


On 14 August 2014 17:28, Tim Davenport  wrote:

> Re: Erik Möller's remark: "In general, though, let's talk. The overarching
> principle we're not
> going to budge on is that this process is really not acceptable:
>
> 1) The UI changes
> 2) A subset of users is upset and organizes a poll/vote
> 3) The poll/vote closes with a request to undo said UI Change and a
> request is filed
> 4) WMF offers compromise or says no
> 5) A local hack is used to undo said UI change
>
> That's no way to develop software, and that's no way to work together"
>
> =
>
> I could spend 10,000 words on this. I'll try to keep it (comparatively)
> short.
>
>
> The reason this dysfunctional situation develops, Erik, is because there
> are no steps A, B, C, D, E, F, and G preceding #1 on the list.
>
> As things currently stand, this is the way the software development process
> at WMF seems to me to work:
>
> * Engineers collecting paychecks obviously need something to do.
> * Someone comes up with a bright idea that sounds good on paper.
> * Engineers decide to make that idea a reality and start work.
> * Inadequately tested software, sometimes of dubious utility, is
> unilaterally imposed on volunteers.
> * If new software is problematic enough, volunteers revolt by any means
> necessary.
> * WMF forces changes down throat of volunteers by any means necessary.
>
> This is truly "no way to develop software" and "no way to work together."
>
> -
>
> Here is the way the process SHOULD begin:
>
> * WMF staffers, plural, identify by user names/IP addresses the 10,000 or
> so very active volunteers across all projects and database them.
>
> * WMF staffers further divide this group into coherent "types": content
> writers, gnome-type copy editors, structural adapters (template people, bot
> operators, etc.), quality control workers (NPP, AfD), vandal fighters,
> behavioral administrators (ArbCom, Ani, the various Admin pages), and drone
> bees who do nothing but Facebook-style drama mongering. Multiple categories
> may apply to single individuals and this list is not necessarily
> exhaustive.
>
> * Once identified, WMF staffers frequently and regularly poll very active
> users in each category about WHAT THEY NEED. Different surveys for
> different volunteer types.
>
> * Software development starts ONLY when a real need is identified.
>
> * Software should be introduced on En-WP, De-WP, or Commons ONLY when it is
> Alpha-grade, debugged and ready to roll. (Test things on the smaller Wikis
> first).
>
> -
>
> Moreover, there should be some polling mechanism to summarize and analyze
> what the 500 million or whatever readers worldwide feel that they like and
> feel they are missing. "User experience" changes with primary impact on
> readers rather than volunteers (such as MediaViewer) should be made with
> them in mind first and foremost; editing and structural tools should be
> made to actually assist the active volunteers, not created on a whim.
>
> Sometimes the needs of the Readers and the needs of the Volunteers are
> different, let us frankly say. In no case should WMF assume the views and
> criticism of the latter are insignificant or wrong simply because
> 500,000,000 > 10,000.
>
> Remember this because according to the same logic: 10,000 > 240.
>
> -
>
> We all agree that we need a bigger