Talk:Global locks/Archives/2011

Mjbmrbot broken

Hi, I'm not sure where to put this, so I'll just put it here:

As I mention here and here, Mjbmrbot is broken, but not stopped by it's owner. Please block globally! Thanks. Buzz-tardis 14:04, 26 January 2011 (UTC)

I guess a block is not needed anymore. Thanks anyway. Buzz-tardis 14:28, 26 January 2011 (UTC)

If a (global) bot is broken and block of a day on one wiki it is working on will stop it. So a global block is overkill. Maybe a good idea to put this example in general help of global bot and global block. Carsrac 07:46, 3 December 2011 (UTC)

Office requests

The question of how to process requests from the Foundation office sometimes comes up here (for global requests).

If there is an urgent cross-wiki block or lock request from the office, how should it be processed? What if no steward can be found on IRC or via email?

• We may want to have a more explicit way to reach stewards in an emergency.
• I believe all certain staff have access to steward tools -- is it worth having a brief version of the Handbook for them (addressing just the emergency situations they may face)?

–SJ · talk | translate 10:58, 23 February 2011 (UTC)

The staff need their own handbook, IMO, preferably including the phrase, "Do what you need to do, and explain for transparency". The original point of the staff global group was to allow staffers with access to it to perform office actions of various sorts without needing to request assistance from the community and to make the steward flag only for those who actually were elected to the position; If another set of rights mirroring that of stewards (&tc.) were used on the staff side, I can't imagine stewards would complain too much. Kylu 13:20, 23 February 2011 (UTC)

For emergencies, there could be a quick place [the Stewards' noticeboard?)to leave a note about what happened, which the next available steward could review. Very few actions are not reversible. For legal and other tasks that the office might truly need to do without requesting assistance, an explanation could at least be left there. Philippe: thanks for the clarification; it's good to know that those rare cases are currently only hypothetical. –SJ · talk | translate 01:48, 24 February 2011 (UTC)

Hi there. A couple of things... first, all staff do not have access to steward tools - it's a subset of the staff, and that is limited to a group that have demonstrated need for the staff rights bit. However, Jon, Guillaume and I have been working toward a set of packages that will further restrict the access to the rights. There are very few staff members (if any) that have a legitimate need for all the rights in the staff package, so Guillaume's very good idea was to split them into a couple of "sets" of rights that cover the most frequent usages. Once we've completed that, our hope is to bring it to the community for discussion.

Staff use the steward tools very infrequently. We have rigid definitions for when/where it's appropriate to use them. When I arrange for the rights assignment through the stewards, I always brief the staff member about the appropriate uses of checkuser, oversight, etc. I have not always included global lock in that group because - quite frankly - I don't think I've ever used that tool, and I forgot it was there. I'm going to include it in the briefing.

I've always asked that in an emergency that requires something outside our normal use of the rights, staff go to stewards first. In the rare case that we can't find one, I think most would typically be to come to me or to their manager. I routinely answer questions about use of the rights. In the extremely rare case that there's a legitimate need to use the rights and a steward can't be found... and this is purely hypothetical... I'd tend toward getting a second opinion or a C-level sign-off, and then doing it, with a note somewhere to explain it. Philippe (WMF) 22:09, 23 February 2011 (UTC)

Hi Philippe, I have a question, then why split the rights in two at all? wouldn't it be easier to just restrict access to only people familiar with steward tools on staff? checkuser and some staff functions require a fair deal of familiarity with the tools, is there something specific from the steward package that the rest of the staff would benefit from? Theo10011 22:24, 23 February 2011 (UTC)

Staff rights as they exist now are sort of an amalgamation of "stuff someone might need", rather than being geared a little more specifically toward "things that community staff need" and "things that tech staff need". The staff rights include a number of features that are not specific to steward tools (for instance, interface editor - which i've started dealing with by requesting that users be assigned to that specific global rights group) and a few others. So the concept is that we would narrow out the rights needed by tech staff, usually, and give those to them (which people like Christine and I don't need) and give us the rights that we need (while not giving them to staff members who don't have need for them). The concept is the Principle of Least Access. So if we were to remove access to staff rights (as they exist now) for people who don't have a familiarity with the steward tools, we'd need to replace them with another set of rights so that those people aren't impeded from doing their jobs by a lack of access to the feature set that they need. Philippe (WMF) 00:48, 24 February 2011 (UTC)

Cool, thanks. I hope you'll post a link to the new staff handbook when it's out! –SJ talk | translate   17:49, 4 July 2011 (UTC)

Global blocks and bans

Two recent requests for global [b]locks involved long-time contributors noted for their good contributions at some point: Abigor and Poetlister. Their cases are very different, but both emphasize the need for a better process to deal with such requests.

How do we decide on global blocks and bans?

How do we determine when they are appropriate, and how can we better visualize contributions and problems across multiple Projects?

1) [Technical] Implement cross-project messaging, status flags, and contribution-history review.

This requires real technical support, both in the libraries available for multi-project MediaWiki installations, and in extensions/visualizations that make it possible to browse and follow contribs across many projects

2) [Technical] Implement tools for blocking, and for granting flags, across multiple projects.

Right now this is largely done by hand, in a laborious fashion.

3) [Policy] Define a Dispute Resolution Committee to evaluate global ban requests and guide related Meta policy

Set criteria for conduct that requires a global ban. For example, criminal stalking, legal action against other Wikimedia contributors or entities, &c. Clarify how all involved projects can be notified of the discussion of such a ban, and what group makes the decision.

Steven and Millosh have both made good suggestions on the DRC proposal.

Scott wrote:

> What you need is a mechanism so that one local community, when banning a user who meets the criteria, can refer the case to a cross-project review group for a global decision.

How do we deal with good contributors who are chronic troublemakers?

These users don't immediately raise red flags. They are always repentant after a bout of mischief or anger or deception. There are obvious downsides to excluding them - one fewer good editor/scripter/vandal-fighter.

4) [Technical] Create permanent options other than banning.

For instance, there could be options to

- flag a user as not allowed to have multiple accounts at all, subject to auto or spot checks for socks (after socking)

- flag a user as not allowed to have permissions (after permissions abuse)

- flag a user as not allowed to !vote (after vote stacking)

These flags need not be casually visible to other editors, but implementing/acting on them needs to be easy or automatic.

5) [Technical] Create activity reports that can be shared across projects

Ex: Cross-wiki reports on vandalism, bad-faith contribution, and manipulation of community policies and processes. Tools for tracking and visualizing such problems.

Risker pointed out in the mail thread that this is one of the biggest barriers to global bans.

Currently, for historical reasons, each project has an independent system for dealing with this, and most are updated manually (or by bot). Make this a top priority for interface upgrades -- this aspect of site maintenance gets heavy use; and the quality of our toolchain here is directly related to how much editor overhead is required to keep the sites running. This applies to recentchange and new page patrol, just as to behavioral trouble with active users.

6) [Tech and Policy] Offer more nuanced ways to profile new users.

Right now if you are trying to log in from an IP in a range that has been blocked, you are simply blocked. You get an email you can contact to request a reversal, but it the whole process is shocking and distasteful to anyone who isn't a vandal or spammer.

Offer a mechanism for flagging an IP range or user (or usergroup) as worthy of closer attention, without blocking them. For instance: flag them as a permanent newbie (subject to the same restrictions as new accounts) until further notice.

6) [Tech and Policy] Define ways to share checks on problematic users, including private data, across projects.

Find ways to publicly indicate concerns that are founded in private data. Make a pointer to this information available to all projects.

If a user has caused trouble on multiple projects and is subject to regular spot checks for socking, have a policy for meta-checks for socking by that user as well. This should involve a way to inform all communities where that user starts editing, some of which will have their own checkusers.

7) [Policy] Define the negative impact of toxic contribution.

At present there is no clear sense of how problematic an angry, or malicious, or deceptive user is. A few hundred or a few thousand good contributions are sometimes considered "enough" to balance out a persistent negative or socially destructive personality.

Offer cross-project guidance on the long-term value of both content and social contributions. [some visualization of social contributions, similar to the crude but persistent use of 'edit count' for edits, might help.]

8) [Policy] Define when 'clean starts' are appropriate, and how they should be carried out.

What standards of transparency should all projects uphold when offering clean starts to former troublemakers? Whatever the standards are for deciding that a user is likely to throw away a second chance, they probably should be cumulative across all projects. [someone with a history of deception over many years is likely to continue that way, even on a new project]

— The preceding unsigned comment was added by SJ (talk)

just a small note: the most recent discussion on meta about this topic took place at Talk:Global bans, not sure if you knew about it. --Tinz 21:34, 4 July 2011 (UTC)