I agree with the first statement that the level should be removed. It
has a trail of bad usage it is connected with. As to whether to renew it
under some policy, I would trust such tool only in hands of stewards,
not WMF. WMF which consists of considerable part of staffers who ain't
even wikimedia project editors is very likely to do something like
enforcing its new unwanted by community development by such means again.
As to the problem of possible hijacking of sysop or even steward accs -
well WMF guys' accs might be hijacked just as well so that's hardly an
I completely disagree with idea about precautionary protection of legal
related policies. The mechanism proposed about fixing translations via
request to WMF is probably the worst idea I have heard in a while. It
both creates great complication to work (I'd rather not fix something
than waste several days on that) and useless: e.g. I know only one
person in WMF who knows my native Ukrainian so that she can review
whether the fix is really needed (Maryana from Mobile fronted team).
Well perhaps there were some changes in staff and now there are several
more. But Ukrainian is quite a big language. We have wikis in 280+
languages. There definitely are languages which no one of the staff
knows. The best thing WMF could you in this case by the mechanism
proposed is to waste donors' money on hiring some translator to that
rare language so that he takes a look. The translator would be
non-wikimedian and have no idea what the text is about. We had a good
bad example of what professional translations are like during this
year's board elections. Besides fixing (or creating) translations there
is a vast variety of other things editors might edit on these pages.
Mark-up, design, categories, some explanations on how to apply the rule
e.g. which templates are to be used for indicating violations and so on.
On enwiki indeed such pages are usually quite developed to the point
where all procedures about the rules are there for years. It is not so
in smaller wikis so limiting editing of the pages there would be
limiting development of the wikis.
There were examples of dealing with legal issues without superprotected.
Like Wikivoyage without much pain changed its logo. If there were a
superprotect back then and it would had been applied I see it resulting
in nothing but lots of hatred.
Indeed sysops might start a wheelwar. There has been a mechanism of
stopping it for ages. A simple desysop.
If there is an issue where a whole community opposed WMF then perhaps
the problem is not in the community. Even if it actually is I believe
stews could find a way to settle it even without such harsh means.
On 12.08.2015 2:06, Nathan wrote: > On Tue, Aug 11, 2015 at 5:48 PM, Pine W <firstname.lastname@example.org> wrote:
>> What I would hope for is guidance from the WMF Board that specifically
>> outlines when WMF invocation of superprotect is and isn't appropriate ,
>> and which I believe is already being discussed internally by the Board.
>> With that done, my hope is that WMF will take a supportive approach to the
>> community, instead of a combative approach.
>> With those changes made, I think that the likelihood of another conflict
>> between the community and WMF over a superprotect-like issue would be low.
>> Appropriate uses for Superprotect upon community or WMF request could
>> include (1) legally sensitive documents like the TOS, (2) technically
>> sensitive pages that would otherwise be exposed to administrators who can
>> edit through full protection and should only be edited with consensus, or
>> because of urgent security or stability considerations, (3) pages which are
>> currently the subject of wheel-warring among local administrators, and (4)
>> pages which are currently the subject of a legal dispute that requires a
>> level of protection greater than standard full protection.
>>  WMF's first use of Superprotect having been a serious misjudgement for
>> which I would like to hear them more fully recant and apologize, and which
>> I would like to see categorized as an inappropriate use of superprotect in
>> the upcoming guidance from the Board.
> Personally, I hope the Board has better things with which to occupy its
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:email@example.com?subject=unsubscribe>
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines