Wikipedia:Requests for comment/Responder role

This is a draft for a future request for comment. Please add your thoughts and feedback on the talk page.

WP:RESPONDER-RFC

Proposed: A 3-month trial of a new role to allow users who are reporting a high-speed vandal at AIV to also block them for an hour.

Background

TODO Update section with 2022 numbers

In about a third of AIV reports (data analysis here), the reported user continues vandalizing while the report waits for an admin. In the fall of 2021, there were 8,020 such edits. On average, there are 12 reports every week where the vandal can make 10+ edits before being blocked. Some examples: 85 edits (2-hour response time), 79 edits (31m), 71 (1h), 69 (3h), 63 (2h), 55 (51m), 51 (2h).

Note that even when the average response time of online admins is at its lowest (i.e. fastest) point during the day, this problem persists. Looking at the graphs, in fact, that hour of day has the third worst number of edits.

Proposal

Users with this role can, when reporting a user to AIV for vandalism, also block that user for an hour (via bot, see § Implementation). Blocks cannot be made for any other reason, and this role does not permit any other sort of admin action.

These blocks do not replace blocks made by admins patrolling AIV. Each AIV report will be reviewed by an admin as usual, possibly resulting in a block.

Restrictions:

Only IP addresses, or registered accounts less than a day old, can be blocked.
The blocked user must have vandalized less than an hour ago.
A given IP address or account can only receive one responder block per month.
The vandalism must be blatant; there must be no way it could be good-faith editing. In particular, there must be no credible argument that it could be mere tendentious editing or edit warring.
The vandalism should be rapid (at least one edit per minute).

Generally, there should never be disputes over whether a block was proper; if there's any doubt at all, a block should not be placed.

Furthermore, this role must not be used when protection or another admin action would be a more effective response, such as when a single page is being disrupted by many different users.

The blocks can be lifted by other responders or by admins.

Granting

Editors may apply at WP:AN. Being nominated by another editor is recommended. The discussion will be open for a minimum of 48 hours. Any editor may comment, but threaded discussion is encouraged instead of bolded !votes. The discussion will be closed by an administrator.

Prior to applying, the editor must maintain a log of which blocks they would have made using the role, for 2 weeks or 10 blocks (whichever comes first). Log entries should be made at the time when the block would've been made (that is, not some time afterwards), and should be in userspace. When they apply or are nominated, they should link to the log.

Guidelines:

The editor should be a registered Wikipedia user for at least 1 year.
The editor should have made at least 2,000 overall edits.
The editor should have no behavioral blocks or 3RR violations for a span of 6 months prior to applying.

The editor must have a history of good anti-vandalism work. The editor should make AIV reports that reliably get actioned. They should use rollback or similar tools, like Twinkle, correctly and effectively.

For the trial, and early in the role's lifetime, the goal will be to get editors in this role who will make absolutely zero mistakes. The role should be granted and revoked appropriately.

Revocation

Editors are expected to be accountable for their actions using the tool. Abuse of this tool, or usage outside of its approved scope, is a serious issue. Any administrator who suspects the tool has been misused may unilaterally revoke it and notify the administrators' noticeboard of the issue.

The role may also be removed by request or if a user has been inactive for 12 months.

Implementation

There will be a fully-protected page listing editors with access, like the AWB checkpage. Editors listed there have the ability to place a block as described above while making an AIV report. The adminbot will check that the quantitative criteria for blocking are met and use the API to place the block. Blocks will be nocreate and autoblock.

For further accountability, each week, the bot will post a random sample of blocks (or all, if there weren't many) made with this role to AN.

Although it could be argued that ADMINACCT and ADMINBOT would make the adminbots' operators personally accountable for the blocks, if this proposal passes, it is understood that accountability passes entirely to the users requesting blocks, except in instances of bugs and other technical problems with the bot.

Trial

The trial will last for three months starting when the first user is granted the role. After three months, the role and bot will be disabled and no further blocks will be made.

Any admin can pause the trial at any time and open a discussion on whether it should continue. Technical changes to how the role works are allowed unilaterally; substantive changes are allowed after discussion.

Data will be collected on the the trial. The trial can be evaluated based on whether any bad blocks were made, whether it reduced the amount of vandalism done while AIV reports are open, and whether it saved community time overall. Editors may suggest more metrics to use.

There may be another RfC after the trial for permanent implementation, depending on community mood.

Responses to some objections

Responders will block even when other admin actions would be better choices (law of the instrument).
- The single situation where blocks could be made is described very precisely. If they block outside of that situation anyway, this will be noticed and the role can be revoked.
Responders will block and not take other required admin actions, such as revdel.
- The responding admin at AIV will take appropriate actions, as they would for a normal AIV report.
Recent changes patrollers should not revert these edits so that the vandal won't re-revert and the page history looks cleaner. (See also Wikipedia:Don't edit-war with vandals or sockpuppets.)
- This strategy is not widely acceptable. It also won't work for blanking and other particularly noticeable vandalism, or for vandals who keep finding new pages to edit.
This role will become a de facto RfA prerequisite.
- This role is unrelated to most admin work, so most RfA candidates will not be expected to have it. So far in 2022, only five out of 14 RfA candidates mentioned AIV in their Question 1 answers.
They should just start an RfA.
- This role requires much less of a candidate than adminship and would be easier to get. Admittedly, some of the skills overlap (good judgment, policy understanding) but a lower level is needed. Similarly, a lower amount of overall tenure/experience is needed. All passing RfA candidates starting in 2017 have had more than 10k edits, and we're looking for less than that.
We over-block at AIV already.
- Anyone blocked using this role should be far from a borderline case.
The vandal will just come back after an hour.
- An admin should've indeffed/31hr'd them already. If not, action will eventually be taken at AIV.
The vandal will just make another account.
- These blocks will include "Prevent account creation" (nocreate) which will make that impossible.
The vandal will just switch IPs.
- Yes, if that happens, this role will be ineffective. It is unknown how many vandals will do this, which is why this is a trial.
Users should just ask for help from admins (e.g. !admin on IRC).
- Admins will usually tell users that it's not that important and that they should just report the vandal to AIV.
This proposal creates mini-admins.
- This proposal is only a utility for frequent AIV reporters. Responders have minimal authority, as admins have to review each of their actions.

Other stuff, details, ideas

The precise implementation of how a user requests a block by the bot can be decided later; perhaps AIV reports could include a special template, which the bot would look for.
There should be an IRC/Discord channel reporting each responder block in real time. We could have a bot posting when users could (heuristically) be eligible to be blocked, as well.
User scripts and other tools can be made later to assist any part of this process, but are not in scope initially and aren't required for the trial.

Previous discussions

This idea has come up a lot; here's a small sample.

See also T128328 to split the "block" permission, perhaps into blockip and blockuser.