If WMF decides to completely remove Superprotect and the Board's
forthcoming policy prohibits the reintroduction of Superprotect without
Board authorization, I won't object to that outcome.
Pine
___
Wikimedia-l mailing list, guidelines at:
https://meta.
Thanks for the (single) use case: Trouble is it just pushes the
question further down the road.
"inadequate for some compelling reason "
On 13/08/2015 09:25, Pine W wrote:
A*few* legitimate use cases could be:
*Superprotection by stewards of legally or technically sensitive pages, to
preven
No community would want to change documents issued by the WMF, if it
did, the stewards would be crazy to do so.
This is reaching.
Why?
On 11/08/2015 22:34, Risker wrote:
However, stewards under their current
process could very well find themselves in a situation where a "community"
wants to d
Not a good example. This could be a special page.
On 11/08/2015 21:56, Risker wrote:
There are situations where not even the administrators of a particular
community should be allowed to edit a page. A good example would be the
pages that describe the copyright and licensing of Wikimedia produ
Using it for legal disputes is poor form. We had legal disputes before,
and managed them with "office actions". If you don't trust the admins
not to purposefully post libel or copyvios, then super-protecting a
page or two won't help.
Moreover it implies that the Foundation can or will take
(snip)
>
> A use of superprotect could be to protect certain pages or settings
against
> actions stemming from the hypothetical but possible scenario that an admin
> account is compromised.
>
If the setting is so dangerous that it will cause SERIOUS problem if
misconfigured, why is it editable by
Hi,
No, that's not what I'm suggesting. I needed to re-read my comments before
I realized that they could be read the way that you seemed to have done,
and I apologize if I was unclear. If an admin account becomes compromised,
the current procedures for locking that account would apply.
A use of
Pine W wrote:
>*Superprotection by stewards of legally or technically sensitive pages, to
>prevent damage caused by a hijacked admin account. The theory here is that
>admin accounts are more numerous than steward accounts, so the liklihood
>of a successful admin account hijack may be higher. Superp
e person or group who
> > authorises the action takes the responsibility.
> > Cheers,
> > Peter
> >
> > -Original Message-
> > From: wikimedia-l-boun...@lists.wikimedia.org [mailto:
> > wikimedia-l-boun...@lists.wikimedia.org] On Behalf Of Pine
ction takes the responsibility.
> Cheers,
> Peter
>
> -Original Message-
> From: wikimedia-l-boun...@lists.wikimedia.org [mailto:
> wikimedia-l-boun...@lists.wikimedia.org] On Behalf Of Pine W
> Sent: Thursday, 13 August 2015 10:26 AM
> To: Wikimedia Mailing List
>
-
From: wikimedia-l-boun...@lists.wikimedia.org
[mailto:wikimedia-l-boun...@lists.wikimedia.org] On Behalf Of Pine W
Sent: Thursday, 13 August 2015 10:26 AM
To: Wikimedia Mailing List
Subject: Re: [Wikimedia-l] Superprotect's first birthday
A few legitimate use cases could be:
*Superprote
A few legitimate use cases could be:
*Superprotection by stewards of legally or technically sensitive pages, to
prevent damage caused by a hijacked admin account. The theory here is that
admin accounts are more numerous than steward accounts, so the liklihood of
a successful admin account hijack m
Laurentius wrote:
>Il giorno mer, 12/08/2015 alle 01.11 +0900, Hong, Yongmin ha scritto:
>> It has been a year (and a day) since the gerrit 153302 [1] has been
>> merged and deployed to the dewiki.
>
>And it's high time it got removed.
I agree. It's a bedrock principle of MediaWiki and Wikimedia t
On 13 August 2015 at 06:51, Lucas Teles <> wrote:
> How would superprotect be used in a legal situation and how would that be
> different from any other way that community and WMF have found to deal with
> that without the tool in the past? Can somebody provide a hyphotethical
> example please?
>
On 12 August 2015 at 19:46, Gerard Meijssen <> wrote:
> Hoi,
> In case of a legal situation. Taking a position like "superprotecting"
> means that you take on a liability. When you do this as part of a job, it
> is different from doing it as a volunteer.
--
The only difference I can understand
On 12 August 2015 at 10:11, Bohdan Melnychuk <> wrote:
> I would trust such tool only in hands of stewards, not WMF
--
I can not remember when I last saw a steward action on the En WP.
___
Wikimedia-l mailing list, guidelines at:
https://meta.wikime
>
> > Date: Wed, 12 Aug 2015 21:16:37 +1000
> > From: cfrank...@halonetwork.net
> > To: wikimedia-l@lists.wikimedia.org
> > Subject: Re: [Wikimedia-l] Superprotect's first birthday
> >
> > On 12 August 2015 at 14:41, Bohdan Melnychuk wrote:
> >
>
,
Steinsplitter
No comment about Gerard Meijssen's comment. It is explaining itself
perfectly.
> Date: Wed, 12 Aug 2015 21:16:37 +1000
> From: cfrank...@halonetwork.net
> To: wikimedia-l@lists.wikimedia.org
> Subject: Re: [Wikimedia-l] Superprotect's first birthday
>
>
Hoi,
In case of a legal situation. Taking a position like "superprotecting"
means that you take on a liability. When you do this as part of a job, it
is different from doing it as a volunteer. Insisting on having this done by
stewards means insisting on their vulnerability..
Thanks,
GerardM
On 12 August 2015 at 14:41, Bohdan Melnychuk wrote:
> ... It has a trail of bad usage it is connected with. ...
I'm not sure I agree with that. There are two known uses. The first one,
where a software tool was locked in over the consensus of the community was
a "bad usage" I'll agree; if any
That sounds reasonable.
> Date: Tue, 11 Aug 2015 13:14:58 -0700
> From: wiki.p...@gmail.com
> To: wikimedia-l@lists.wikimedia.org
> Subject: Re: [Wikimedia-l] Superprotect's first birthday
>
> My preference would be to have stewards applying Superprotect rather than
>
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 wikime
On Tue, Aug 11, 2015 at 5:48 PM, Pine W 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 [1],
> and which I believe is already being discussed internally by the Board.
> With that done, my hope
On 11 August 2015 at 18:05, Robert Rohde wrote:
> On Wed, Aug 12, 2015 at 12:00 AM, Risker wrote:
>
> > Who said the problem was on enwiki?
>
>
> If you think this issue is only a problem in some specific place or class
> of wikis, then say so. Otherwise, I would have to assume you consider it
On Wed, Aug 12, 2015 at 12:00 AM, Risker wrote:
> Who said the problem was on enwiki?
If you think this issue is only a problem in some specific place or class
of wikis, then say so. Otherwise, I would have to assume you consider it a
problem that exists everywhere, including the large wikis l
Who said the problem was on enwiki?
On 11 August 2015 at 17:58, Robert Rohde wrote:
> On Tue, Aug 11, 2015 at 10:56 PM, Risker wrote:
>
>
> > There are situations where not even the administrators of a particular
> > community should be allowed to edit a page. A good example would be the
> > p
On Tue, Aug 11, 2015 at 10:56 PM, Risker wrote:
> There are situations where not even the administrators of a particular
> community should be allowed to edit a page. A good example would be the
> pages that describe the copyright and licensing of Wikimedia products.
Since being full protecte
What I would hope for is guidance from the WMF Board that specifically
outlines when WMF invocation of superprotect is and isn't appropriate [1],
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
commun
I hate to say it, but a hijacked Steward account is considerably more
dangerous than a hijacked admin account. It's extremely unlikely to happen
- our stewards are probably more aware of maintaining account security than
just about any other group of users. However, stewards under their current
pro
Most of the time, admins behave as we would hope. Occasionally they don't,
and on English Wikipedia when that happens often enough or seriously enough
in the opinion of Arbcom, the offending admins are desysopped. I think that
for legally sensitive pages, we'd be concerned about the possibility of
I trust administrators not to edit pages they shouldn't.
Il 11/08/2015 22:56, Risker ha scritto:
There are situations where not even the administrators of a particular
community should be allowed to edit a page. A good example would be the
pages that describe the copyright and licensing of Wikim
There are situations where not even the administrators of a particular
community should be allowed to edit a page. A good example would be the
pages that describe the copyright and licensing of Wikimedia products.
Individual communities cannot change that (it applies globally), and
individual admin
So far I know it has only be used once after the occasion, see:
https://meta.wikimedia.org/wiki/Talk:Superprotect
If anyone knows another occasion, I would like to ask to report this usage
at this talk page to keep an overview in future.
Greetings,
Romaine
2015-08-11 20:28 GMT+02:00 Magnus Mansk
Can you clarify what you mean? If there are legal reasons for
superprotecting a page, I think that the stewards could handle that.
Pine
On Tue, Aug 11, 2015 at 1:16 PM, Gerard Meijssen
wrote:
> Hoi,
> did you consider the legal ramnifications ?
> Thanks,
> GerardM
>
> On 11 August 2015
Hoi,
did you consider the legal ramnifications ?
Thanks,
GerardM
On 11 August 2015 at 22:14, Pine W wrote:
> My preference would be to have stewards applying Superprotect rather than
> WMF. There are cases where Superprotect makes sense, but given WMF's
> history with it, I would prefer t
My preference would be to have stewards applying Superprotect rather than
WMF. There are cases where Superprotect makes sense, but given WMF's
history with it, I would prefer that it become a community tool.
Pine
On Tue, Aug 11, 2015 at 12:46 PM, Magnus Manske wrote:
> So maybe it could stay,
So maybe it could stay, as a "technical office action" mechanism, if future
usage is clearly defined and accepted by "the community" (TM)?
Not advocating either way here...
On Tue, Aug 11, 2015 at 8:13 PM Dariusz Jemielniak
wrote:
> On Tue, Aug 11, 2015 at 8:36 PM, John Lewis
> wrote:
>
> >
>
On Tue, Aug 11, 2015 at 8:36 PM, John Lewis wrote:
>
> Yes. It was used a few months ago to prevent editing the Germany item on
> Wikidata due to a very serious breaking issue. Also on several pages
> following legal disputes.
>
> Superprotect in my opinion if used correctly is an essential tool
On Tuesday, August 11, 2015, Magnus Manske
wrote:
> Out of curiosity, was it ever used again after that initial action?
>
>
Yes. It was used a few months ago to prevent editing the Germany item on
Wikidata due to a very serious breaking issue. Also on several pages
following legal disputes.
Supe
Out of curiosity, was it ever used again after that initial action?
On Tue, Aug 11, 2015 at 6:13 PM Laurentius
wrote:
> Il giorno mer, 12/08/2015 alle 01.11 +0900, Hong, Yongmin ha scritto:
> > It has been a year (and a day) since the gerrit 153302 [1] has been
> > merged
> > and deployed to the
Il giorno mer, 12/08/2015 alle 01.11 +0900, Hong, Yongmin ha scritto:
> It has been a year (and a day) since the gerrit 153302 [1] has been
> merged
> and deployed to the dewiki.
And it's high time it got removed.
Laurentius
___
Wikimedia-l mailing l
Yeah, I was just thinking it's time to revert it for good.
Il 11/08/2015 18:11, Hong, Yongmin ha scritto:
It has been a year (and a day) since the gerrit 153302 [1] has been merged
and deployed to the dewiki.
Just a friendly reminder that you don't forget WMF's inappropriate action.
[1]: https
It has been a year (and a day) since the gerrit 153302 [1] has been merged
and deployed to the dewiki.
Just a friendly reminder that you don't forget WMF's inappropriate action.
[1]: https://gerrit.wikimedia.org/r/#/c/153302
--
Revi
https://revi.me
-- Sent from Android --
43 matches
Mail list logo
