If it is true that the software deployment of the visual editor is again going hastily and with negative repercussions as a result, it is disappointing that apparently nothing has been learned from the largest failure of any software implementation in the Wikimedia movement ever: the implementation of the visual editor a year ago.There have been massively protests going on, on various wiki's. Such must had a signal to WMF that this way is totally unacceptable to the community, so why is this behaviour continued?
The visual editor is the biggest change in software in years, the community expects that such change is deployed in such way that fits: it has been tested with care, it is communicated in a proper way, deployed in a good way, and the community involved in a nice way. In 2013 it was too much rushed, in 2014 it appears to be rushed again sadly. I heard that the visual editor was deployed in 2013 because it was planned so, and a reason given to deploy it, instead of waiting until it is actually ready, was that it WMF thinks it is important to stick to how it was planned because people expect that plans are to be followed. So it appears to be that sticking to a plan is more important to WMF, than delivering a good product that has no critical problems. Mistakes can be made, but ........... If a plan is wrong, the plan should be changed, not rushing broken software, and not putting the trust of the community at stake!
Watching the communities on several wikis for more than 5 years now, it seems that they all like the idea of a visual editor very much. I think it correct to say it is the most wanted software of the past 5 years. If then such wide opposing rises up, alarm bells must go ringing: something is terrible going wrong.
And I can add, at the Dutch Wikipedia we examined the working of the visual editor on articles. In 2013 we found issues we consider critical, and recently we examined them again and still several of these issues are present. We had a voting about this with the result that as long as these critical issues exist, the Dutch community is against that the visual editor is switched on by default.
Greetings, Romaine
2014-08-11 4:12 GMT+02:00 MZMcBride z@mzmcbride.com:
Hi.
The German Wikipedia has evaluated and decided against the default use of MediaViewer on its project (preferring opt-in, rather than opt-out). Erik has made it his mission to impose MediaViewer on the German Wikipedia using Wikimedia Foundation staff coercion (cf. https://gerrit.wikimedia.org/r/153302 and https://gerrit.wikimedia.org/r/153345). Both changes have been pushed through hastily and have had negative repercussions as a result (missing translations, disrupted workflows, etc.). From a recent Bugzilla comment about the latter change, "it's clear this change was a kneejerk reaction without a lot of thought as to the effects."
The security of the entire MediaWiki infrastructure, which in turn is the security of a large portion of Wikimedia wikis, heavily relies on the idea that local administrators can be trusted. With his provocative actions, Erik has declared war on the German Wikipedia.
Given this, there are options for the German Wikipedians. This is a non-exhaustive list and may not reflect the latest waste of developer and system administrator resources coerced by Erik.
- Local disruptive accounts (such as "User:Eloquence" and "User:JEissfeldt
(WMF)") can be locally blocked by German Wikipedia administrators for conduct unbecoming.
- Global accounts can have their privileges removed by stewards, who are
intended to serve as the "root" users of Wikimedia wikis.
- While the German Wikipedia's "MediaWiki:Common.js" has been
super-protected, there are other pages such as "MediaWiki:Vector.js", "MediaWiki:Monobook.js", and "MediaWiki:Group-user.js" that can probably be used to achieve the same effect.
- Importing edits on top of an existing page should replace the content
and bypass any protection, though this theory needs additional testing.
- Certain pages in the MediaWiki namespace such as "MediaWiki:Copyright"
still allow raw HTML, which can be used for a direct "<script>" insertion.
JavaScript gadgets can be enabled by default across a wiki.
CentralNotice from Meta-Wiki can be used to deploy JavaScript to the
German Wikipedia.
There are also more extreme options available.
- Using per-user CSS or JavaScript to forcibly hijack Erik's or another
staff member's account. This can be done locally on any wiki, including sites such as Meta-Wiki.
- Disabling editing and/or reading of the German Wikipedia, using a
variety of tools. Erik's declaration of war makes this option viable, but it should likely be used only as a measure of last resort. If Erik is truly hell-bent on damaging or destroying the wiki model, perhaps the wiki should simply cease to be. Using the title blacklist, the AbuseFilter extension, site-wide JavaScript and CSS, and other techniques, it's possible to fully disable reading and/or editing of the German Wikipedia until an amicable solution can be found.
- A Wikimedia-wide vote of no confidence for Erik. Again, this is an
extreme option, but given Erik's behavior over the past few weeks (including his actions on the English Wikipedia, which resulted in an arbitration case involving him), beginning a vote of no confidence is an idea worthy of consideration.
There are also alternate options.
- Disabling the MediaViewer extension by default on the German Wikipedia,
as requested by the German Wikipedia community.
- Accepting Erik's authority over the technical infrastructure of
Wikimedia wikis and allowing him to rule as a technical autocrat.
I'm interested to read others' views about options and ways forward here.
MZMcBride
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, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe