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(a)mzmcbride.com>om>:
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(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>