However, we've clarified in a number of venues that use of the MediaWiki: namespace to disable site features is unacceptable. If such a conflict arises, we're prepared to revoke permissions if required. This protection level provides an additional path to manage these situations by preventing edits to the relevant pages (we're happy to help apply any urgent edits) until a particular situation has calmed down.

Hi folks, Admins are currently given broad leeway to customize the user experience for all users, including addition of site-wide JS, CSS, etc. These are important capabilities of the wiki that have been used for many clearly beneficial purposes. In the long run, we will want to apply a code review process to these changes as with any other deployed code, but for now the system works as it is and we have no intent to remove this capability. However, we've clarified in a number of venues that use of the MediaWiki: namespace to disable site features is unacceptable. If such a conflict arises, we're prepared to revoke permissions if required. This protection level provides an additional path to manage these situations by preventing edits to the relevant pages (we're happy to help apply any urgent edits) until a particular situation has calmed down. Thanks, Erik

Il 10/08/2014 15:27, Erik Moeller ha scritto: https://meta.wikimedia.org/w/index.php?title=Special:Log&dir=prev&o… WMF vs. community? https://meta.wikimedia.org/wiki/Requests_for_comment/Superprotection

Now, having observed that not only user Eloquence (aka Erik Moeller) himself engaged in the enforcement of <superprotect> right on de.wp [1] but soon after a workaround was published a change was deployed [2, 3] as counter measurement to block any possible interference can no longer be interpret as acting in good faith but rather strikes me as a form of oppression (or worst as censorship).

Hi, I'm putting a hat on from pure observer point of view as neither a member of de.wp nor wmf.

I'm not complaining, I'm observing the events that happened around the introduction of <superprotected> and the swift action which did not involve any consultation or discussion (or rather a single statement from Erik Moeller where he cites security and code review as the inherent cause for the introduction). > It was a bug in mediawiki, and thus it should be fixed. MediaWiki is

{{cc}} (which bug, when was created and by whom)

> by many different groups and in general we [mw devs] do not judge people > for how they use the software. If some non wmf entity reported the bug,

Interesting view, that means bugs that are to solve a political dispute are preferred over bugs that existed for years? Cheers

On 8/12/14, Brian Wolff &lt;bawolff(a)gmail.com&gt; wrote: >> >> Now, having observed that not only user Eloquence (aka Erik Moeller) >> himself engaged in the enforcement of <superprotect> right on de.wp >> [1] but soon after a workaround was published a change was deployed >> [2, 3] as counter measurement to block any possible interference can >> no longer be interpret as acting in good faith but rather strikes me >> as a form of oppression (or worst as censorship). >> > > [Putting the purely mw dev hat on] > > It was a bug in mediawiki, and thus it should be fixed. MediaWiki is

> by many different groups and in general we [mw devs] do not judge people > for how they use the software. If some non wmf entity reported the bug,

> would still be fixed. > > So dont complain that mw fixes a bug in how page protection. If you are > unhappy with current events you should direct your anger at how the wmf > decided to use hard security to enforce its dictates, not at the

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Putting the purely mw dev hat on] It was a bug in mediawiki, and thus it should be fixed. MediaWiki is used by many different groups and in general we [mw devs] do not judge people for how they use the software. If some non wmf entity reported the bug, it would still be fixed. So dont complain that mw fixes a bug in how page protection. If you are unhappy with current events you should direct your anger at how the wmf decided to use hard security to enforce its dictates, not at the software for "working". --bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Before this, there was no expectation that a page could be protected such that sysops could not alter the content of the superprotected page.

Now, the devs/ops have attempted to introduce that capability, and the new functionality is very likely riddled with holes, some of which MZMcBride has suggested in the thread 'Options for the German Wikipedia'.

Was this functionality was ever supported by MediaWiki core?

Sorry, I strongly disagree that the current system works. Every so often we discover that a wiki has been loading external resources in site-wide JS for months. Local sysops might have no idea on what they're doing, and just copy and paste what someone told them to do. Edits like [1] make that terribly obvious. I filed bug 69445[2] as a tracking bug to implement a sane code review process for these pages. I don't imagine it will happen anytime soon, but now seems like a good time to start discussion about it.

I hope it's not an other step from WMF to prevent the application of community decisions when they not agree with it. I fear that they will use this to bypass community decisions. For example like forcing again VE on everyone on enwki: last year, sysop were able to apply community decision against Erik wishes only because they had access to site wide js or CSS.

It could mean that, but of course it is actually introduced to prevent the German community from deactivating the Media Viewer.

It could mean that, but of course it is actually introduced to prevent the German community from deactivating the Media Viewer.

Wiadomość napisana przez Nicolas Vervelle &lt;nvervelle(a)gmail.com&gt; w dniu 10 sie 2014, o godz. 15:45: I'd like to believe that code-reviewing would mean improving code quality, security and performance (applies to javascript).

Hoi, Code review should be a strictly technical process surely. However the community CANNOT decide on everything. The WMF has one codebase for MediaWiki and it explicitly defines with long lead times the things it is working on. It does invite the community to be involved in the process.

Hoi, This is simply not true. At Wikimania there were several sessions where the topic was what will the technical underpinnings be of our software. It was also discussed to some extend what kind of effect things may have on a community. When you are in those conversations you realise that many complications are considered; it is not easy nor obvious. Thanks, GerardM NB there is not one community, there are many with often completely diverging opinions. Technically it is not possible to always keep backward compatibility / functionality. We are not backward we need to stay contemporary. On 11 August 2014 10:36, svetlana &lt;svetlana(a)fastmail.com.au&gt; wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

The same is going to happen for Flow (which I strongly believe is needed, but is being deployed untimely)

I think this is where part of the problem lies. Will discussion on whether or not to deploy it to a local wiki still be possible when the WMF decides it is ready for wider deployment, with a possible no for an answer?

{{cn}}

"C. Scott Ananian" &lt;cananian(a)wikimedia.org&gt; wrote: > Almost every WMF developer attended Wikimania this year, and there was > quite a lot of fruitful discussion and feedback given. Somewhat > surprisingly (to me, it was my first Wikimania) the tone in person was > quite different than what you might expect from email list traffic.

> that was self-selection, as the attendees at Wikimedia were the members

{{cn}} Tim _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Almost every WMF developer attended Wikimania this year, and there was quite a lot of fruitful discussion and feedback given. Somewhat surprisingly (to me, it was my first Wikimania) the tone in person was quite different than what you might expect from email list traffic. Perhaps that was self-selection, as the attendees at Wikimedia were the members of the community interested in constructively working on solutions. But it's also worth noting that just about every Wikimania attendee is either traveling or on vacation today. The conversation on this thread might be a little lopsided as a result. --scott _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 11 August 2014 10:56, Ricordisamoa &lt;ricordisamoa(a)openmailbox.org&gt; wrote: We are. ​SUL finalisation (which is broadly a blocker to much of this work) is currently underway and should help make a lot of cross-cluster desired tools a great deal easier to build. This isn't the only piece of work, but it's been enough to discourage work on these areas for many years. At Wikimania, a number of staff and volunteer developers re-started work on a global repository for gadgets. I was part of initial discussions around a global repository for source references with structured data stored on Wikibase somehow, and similar considerations for Wikiquote and Wikisource. I'm sure lots of helpful follow-up e-mails, suggestions, RfCs and the like will be written in the next few weeks as people get back from the conference and have the time to communicate their work. ​So… "we" are.​ But why aren't you, too? Development is and has always been a group effort. Patches welcome! ​J.​

Where can I see any of that?

On Mon, 11 Aug 2014, at 19:56, Ricordisamoa wrote: THANK YOU! you are, alone, worth a whole engineering team _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hi Gerard, Some answers (in a random order). 2014-08-11 12:20 GMT+03:00 Gerard Meijssen &lt;gerard.meijssen(a)gmail.com&gt;om>: not instance, made I gave up watching Jimbo's keynotes a few years ago, as I would invariably get pissed off. So, should we understand that the vast ammounts of money and resources spent on editor retention are a waste of our money? I sincerely hope this is a heat-of-the-moment argument, just like the one about closing de.wp. Agreed. How about letting the WMF decide for anonymous users and the community decide for logged-in users? Presumably, the logged-in users have access to a large panel of options and can make up their own mind if they disagree with the consensus. Of course, discussions should not disappear because of such a separation, but even become more active and hopefully less aggressive. backward As a software engineer in a publicly traded company, I understand the reasoning behind more than 90% of the decisions made by the Engineering staff - and this worries me terribly, because they *don't* work for a company. Their objectives and approaches should be different. There are three main wiki-use-cases that should receive similar levels of attention: * reading * basic editing * advanced editing The first two receive a lot of love, but the third one not so much, it's even hindered by initiatives designed for the first two. I'm not saying that we should keep backwards compatibility forever, but since the WMF wants to deploy stuff early in order to get feedback, it should begin by offering it as a beta (they do that now), then, when reaching a decent level of stability, deploy it for anonymous users and opt-in users and only when it reaches feature-parity with the feature being replaced should it be pushed for everybody (keeping an opt-out feature for some time - months or a couple of years). Take for instance the media viewer: the current version is useless for editors, as it has basically no controls visible by default (without scrolling). The future version, presented at Wikimania, has a lot more stuff visible on the first screen, making it much easier to use for editing. I believe that the media viewer should have been kept as opt-in for logged in users until this future version arrives. Strainu _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

This change solves a problem that does not exist. We either trust sysops, or we don't.

On 10-08-2014 15:35, svetlana wrote: I concur. There are enough admins available to revert bad code additions. Also, this measure is completely without effect. *Suppose* I were a rogue admin wanting to add some bad code to common.js that disables some WMF feature; I will be reverted by staff and common.js is superprotected. Oh well, I'll just create a hidden default gadget... Happy hunting!

Op 10 aug. 2014 om 20:12 heeft Ricordisamoa &lt;ricordisamoa(a)openmailbox.org&gt; het volgende geschreven: <hopeless>I'd really like to hear Jimbo's opinion on the matter</hopeless>

<hopeless>I'd really like to hear Jimbo's opinion on the matter</hopeless>

Is wikitech-l really the best place for this discussion? -- Lewis Cawte (Lcawte)

On 10-08-2014 15:35, svetlana wrote: I concur. There are enough admins available to revert bad code additions. Also, this measure is completely without effect. *Suppose* I were a rogue admin wanting to add some bad code to common.js that disables some WMF feature; I will be reverted by staff and common.js is superprotected. Oh well, I'll just create a hidden default gadget... Happy hunting! Regards, -- Erwin Dokter _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

There are many legitimate cases (e.g., office actions and copyright-related issues) where I could see the superprotect level coming in handy. There are some cases where the WMF simply cannot afford (usually b/c of legal reasons) to trust the community, even if they're 99.9% sure nothing will happen. Sometimes all it takes is one rogue admin to trigger a lawsuit. With that said, it's obviously a political matter as to what the proper uses of this new protection level are, but I do think the existence of the level itself is appropriate.