The general trend in the past few months has been for WMF to be more respectful and supportive of the community, and I hope that this trend continues (for example, by empowering the grantmaking committees with more discretion and leadership responsibilities, and by placing more emphasis on supporting small affiliates that show growth potential).
The WMF Board could legislate that no one on the WMF staff may invoke superprotect directly, and all superprotect-related actions must be reviewed and applied by a steward. (I am assuming that stewards will agree to implement superprotect actions that WMF is required to undertake for legal reasons). I do think that such a policy would improve WMF's relationship with the community. Pine On Aug 13, 2015 2:19 AM, "Robert Rohde" <raro...@gmail.com> wrote: > No, the WMF can't be physically prevent from using superprotect or > something like it. Removing the tool from the software would be more a > symbolic measure than anything. > > In principle though, it may be possible to convince the WMF not to use it > (or only use it under conditions agreed upon in consultation with the > editor communities). Building such an agreement could have benefits for > WMF-Community relations, whereas misuse of the tool would be detrimental to > community relations. Though intangible, those relationships are important, > and the WMF appreciates that there is value there that should be > considered. > > So, no, we can't force the WMF to respect our wishes, but we can hope that > they will work with us because a good relationship between the WMF and the > editor community is important for both groups. > > -Robert Rohde > > On Thu, Aug 13, 2015 at 10:55 AM, Peter Southwood < > peter.southw...@telkomsa.net> wrote: > > > Is there actually any way that WMF could be prevented from access to the > > tool if and when they decide they need it? If not, this discussion seems > a > > bit pointless. Do they not have physical access to the hardware and > > complete access to the software? If they decide they need to use it they > > will do so. They may do so for good or bad reasons, depending on who is > > doing the reasoning, and we all have the option of explaining after the > > fact why it should have been done differently. The 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 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: > > > > *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. Superprotection would > > proactively limit possible damage. Admins doing routine maintenance work, > > or taking actions with community consent, could simply make a request > for a > > temporary lift of superprotect by a steward or ask a steward to make an > > edit themselves. > > > > *Upon community request, superprotection of pages by a steward where > those > > pages are the subject of wheel-warring among local admins. > > > > *Superprotection of a page by a steward for legal reasons at the request > > of WMF Legal, for example if a page is the subject of a legal dispute and > > normal full protection is inadequate for some compelling reason. > > > > None of this is an endorsement of WMF's first use of superprotect. I > would > > prefer that if superprotect continues to exist as a tool, that it be in > the > > hands of the stewards and not WMF directly. > > > > Pine > > _______________________________________________ > > 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-requ...@lists.wikimedia.org?subject=unsubscribe> > > > > ----- > > No virus found in this message. > > Checked by AVG - www.avg.com > > Version: 2015.0.6086 / Virus Database: 4392/10427 - Release Date: > 08/13/15 > > > > > > _______________________________________________ > > 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-requ...@lists.wikimedia.org?subject=unsubscribe> > > > _______________________________________________ > 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-requ...@lists.wikimedia.org?subject=unsubscribe> _______________________________________________ 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-requ...@lists.wikimedia.org?subject=unsubscribe>
