[Wikimedia-l] Request for comment on global bans
ENWP Pine
deyntestiss at hotmail.com
Sat Jul 7 09:32:39 UTC 2012
Hi Steven,
OK. I have a few more inquiries.
1. Let me make sure that I understand a few things correctly.
* A "global lock" is a technical action that is currently effective only against SUL-linked accounts.
* A "global block" is a technical action that is currently effective only against IPs. Development is in progress to make this effective against registered accounts on all projects.
* A "global ban" is a wikijudicial action taken against an account that is enforced by a global block or a global lock.
Are those right?
2. May I ask what the rationale is for proposing that global bans be decided via global community consensus on Meta, instead what appears to be the status quo of stewards making decisions about global bans based on requests at SRG?
3. I would appreciate hearing your response to the concerns that I raised in my previous email and appear to be shared in part by AFBorchert, about Meta’s suitability to serve as a battleground.
4. I would like to ask if you are aware of the RFC at https://meta.wikimedia.org/wiki/Requests_for_comment/Global_requests_committee, which appears to be a third possible way of handling global bans and other types of decisions which Stewards feel would be best reviewed by more than one individual Steward. I would appreciate hearing your comments about the merits of that RFC. The proposal appears to have become inactive, but it may be worth reviving if there is a consensus that there is need to change the status quo of stewards making decisions about global bans.
5. My understanding is that in the recent past, WMF globally locked an account and feels that it should not publicly discuss the reasons for that global lock. Quoting Philippe: “ And that's precisely why we would like a global ban policy implemented. We would prefer an established, community-monitored process that we can turn to when at all possible (and make no mistake, in this case it was needed; I wish we could give all the specifics, but for privacy reasons, we just can't). Because we didn't have that, we had to break new ground with the Office actions policy. I hope we never have to use that again.” If a situation arises in the future where another account is accused of the same undisclosed type of conduct, is there any way in which the community could handle that situation instead of having WMF handle that situation? It seems to me that handling confidential information is an inherent part of the work of stewards when they perform oversight and checkuser functions, so I would like to think that stewards could also be trusted to make global locks based on whatever information the office had that led to its decision to impose a global lock on the account in question. I hope that whatever process emerges for global bans will have the capability and trustworthiness to handle this type of event in the future. It seems unlikely to me that a global and public community discussion on Meta would be a good way for WMF to ask for a global ban if the evidence and accusation are confidential, but individual stewards or the proposed Global Requests Committee should be able to handle a case where the evidence and accusation are confidential. I would appreciate hearing comments from you or Philippe on this issue.
Thank you,
Pine
> On Jul 6, 2012 2:48 AM, "Deryck Chan" <deryckchan at wikimedia.hk> wrote:
> >
> > Short answer as I understand it:
> > Global blocks are the technical feature and refer to the accounts, the IPs
> > and the software capability; global bans are the policy and refer to the
> > people who are unwelcome.
>
> Deryck has got it right here. The situation is made more complex by the
> fact there currently is no technical mechanism for a global block. In lieu
> of that, Stewards etc. have been resorting to locking people out of their
> accounts using SUL, which is known as a global lock. A global lock is the
> usual way of enforcing a ban, according to the current state of the policy.
>
> Steven
>
> >
> > On 6 July 2012 10:44, ENWP Pine <deyntestiss at hotmail.com> wrote:
> >
> > > Hi Steven,
> > >
> > > Could you explain the distinctions between https://meta.wikimedia.org/**
> > > wiki/Global_locks <https://meta.wikimedia.org/wiki/Global_locks>,
> > > https://meta.wikimedia.org/**wiki/Global_blocks<
> > > https://meta.wikimedia.org/wiki/Global_blocks>,
> > > and https://meta.wikimedia.org/**wiki/Global_bans<
> > > https://meta.wikimedia.org/wiki/Global_bans>?
> > > These look to me like they have some redundancy and some areas where
> > > they
> > > diverge. A chart which compares these three side-by-side would be
> > > helpful.
> > >
> > > Also, if Global Bans are decided by an RFC on Meta, that gives me
> > > pause. I
> > > can envision sockpuppets and meatpuppets attempting to sabotage the
> > > process
> > > and giving Meta checkusers more work to do, potentially much more work,
> > > especially if WP:DUCK behaviors need to be evaluated on multiple
> > > projects
> > > in multiple languages and/or coordination is needed with checkusers from
> > > projects in other languages. I'm a bit more supportive of the process at
> > > https://meta.wikimedia.org/**wiki/Global_locks<
> > > https://meta.wikimedia.org/wiki/Global_locks>which seems to involve
> > > Stewards making the decision to take a global action
> > > based on multiple local projects taking local actions, rather than
> > > because
> > > there was a global community RFC at Meta. I agree with AFBorchert's
> > > comment
> > > at the RFC, "Meta is working great for non-controversial project
> > > coordination, requests to stewards etc. But Meta is in no way prepared
> > > to
> > > serve as a battleground for a large-scale global ban discussion which
> > > would
> > > tend to revive previous debates at other projects."
> > >
> > > Maybe I'm missing something here, but I'm thinking that global locks and
> > > global blocks would be the best two of the three options to deal with a
> > > user who is problematic enough to be unwelcome on all wikis.
> > >
> > > Thanks,
> > >
> > > Pine
More information about the Wikimedia-l
mailing list