Wikipedia talk:Pending changes blocks/Archive 1

Marketing and clarity
As a user right, this WP:SOFTBLOCKER proposal is a great idea in the early stages of fleshing out mechanics and presentation. I suggest organizing the page by imitating the format of various existing "flags". For example, I have WP:ROLLBACK rights which is just one of several "extra" user rights listed at User_access_levels. The proposal itself needs a separate paragraph intended to sell the idea to the community. What exactly is the problem? (Example 1, 2, and 3). How would this idea help alleviate the problem? Maybe that text is part of the document, maybe not. Good idea! I'll be interested in watching this unfold. NewsAndEventsGuy (talk) 17:07, 30 October 2014 (UTC)
 * Thanks, I'll try to incorporate your suggestions in the next few days. Cenarium (talk) 01:29, 31 October 2014 (UTC)
 * Good job reformatting, and now.... Ah ha! The proposal is only anti-vandalism!  I missed that in the earlier version.  Suddenly, I'm a lot less interested.  How often do you see the same IP/new user on a vandalism stampede of such length that this would serve an important role?  Usually its a 1-5 driveby type thing and you never see 'em again, at least on pages I watch. NewsAndEventsGuy (talk) 11:31, 31 October 2014 (UTC)
 * Well, I'll expand upon my rationale. But it's not just vandalism, it would also cover BLP violations, spam and such, anything listed at Reviewing. Did you imagine this being used for anything else ? I wouldn't see it working for things like pov pushing or edit warring, for the same reasons that pending changes protection wouldn't work for those.
 * Take a look at recently blocked users at AIV. For example, Special:Contributions/Kaonalpha, who made several obvious vandalism edits, with one of them staying for half an hour, but those are only the tip of the iceberg. The edit filter prevented a lot of edits too. This is a very typical pattern. If it had the ability to soft block the user, the user's subsequent edits would not have gone live. It would also have helped against this spammer. In addition, if users were PC-blocked at the time of last warning, the edits after it would also not go live. I've looked at the number of edits between last warning and block for several vandals, and it's adding up to a significant number. Even if one looks at the number of edits between AVI report and block, on a more conservative approach, it's still significant. If you would also let anti-vandalism bots PC-block, it would prevent a lot of bad edits from going live. It's also not rare to see some of their inappropriate edits being missed, having them in the unreviewed queue would take care of them.
 * I probably shouldn't use the 'soft block' expression since it's already used in contrast to hard blocks. Cenarium (talk) 12:02, 31 October 2014 (UTC)
 * I hadn't given any precise thought to how it should be used, but instictively was thinking along the same lines, when you said above ...expand upon my rationale....[to encompass]]....anything listed at Reviewing....  Mechanically, how will it work?  Will the proposed edit appear on the article talk page, or just in version history under some "review me" flag?  If trash appears on article talk pages as a result, I'd like to see some belt and suspenders mention of PCB under removing harmful material at the TPG. NewsAndEventsGuy (talk) 12:13, 31 October 2014 (UTC)
 * Typo alert.... last edit summary should have said "TPG", of course NewsAndEventsGuy (talk) 12:14, 31 October 2014 (UTC)
 * No they're in article histories but aren't live, same as for pending changes protection, see User:Cenarium/PCB. Cenarium (talk) 12:18, 31 October 2014 (UTC)
 * Right, I'll visit again when I have time to take it in. NewsAndEventsGuy (talk) 12:41, 31 October 2014 (UTC)


 * WP is overcomplicated, and this is a proposal to make it more complicated. People use the existing tools excessively, and this is a proposal to give them another. My response to PC has been to never  make any changes on a article that is under PC, to avoid complicating this further or of not approving something I might not be aware I'm approving. The  same will be the case here: I would not work with any edit from these accounts, or any article they had edited--I might be inadvertently be accepting  edits from someone for whom I ought to be suspicious who would by current standards have been blocked. Yes, I can imagine appropriate uses for this, and possible ways of dealing with this, but they're all too complicated to be worth the trouble when there is so much else to do. Of course, I may simply more stupid than the average admin, in the sense of being less willing to learn new things than the average admin. But at least I'm not so stupid as to deliberately complicate my life by doing what I am unsure about. It's hard enough knowing whether or not to block someone. Its much harder when there are more choices. I would probably apply this to people who ought to be stopped entirely, thus putting off the time until we deal with them. And every time I used it, I would be adding more work for someone who would have to decide whether to apply that person's edits.  DGG ( talk ) 01:13, 1 November 2014 (UTC)
 * The software makes unintentional approvals very unlikely since you have to click on a "Accept this revision" button. This would be much less noticed than pending changes protection since vandals and similar come and go still pretty fast. As for when you would use this, this new feature is not really aimed for administrators, the point of it is to provide a mild block to more users, and automated processes like anti-vandalism bots or the edit filter, which is needed in my opinion due to the shortage in admins and excessive time it takes to handle those troublemakers. Admins may still have uses for it, but those would be straightforward, since we would use the last warning standard. If you would have previously given a last warning, then you give a last warning and PC block, if you would have given a block previously, then you give a block. This won't require any more thinking than before. Yeah it can be hard to decide when to block, as with other discretionary admin actions, I've moved away from them myself, because I'm too deliberate and wasted too much time pondering. So I've tried to make sure not to add to the burden. Cenarium (talk) 09:48, 1 November 2014 (UTC)
 * I've added a paragraph on the impact on other editors at User:Cenarium/PCB. Please tell me if there's anything you disagree with. Cenarium (talk) 10:45, 1 November 2014 (UTC)

DGG raises a good point about complexity, or at least appearance of complexity. For this to fly simple elegance should leap off the page. To that end, I started looking at WP:Pending changes. Potentially that comparison makes or breaks the sales pitch, and so I suggest distilling the essential questions (Who what why how etc) into a table for comparison. I had barely gotten started (on back of an envelope) when I was confronted with a basic question. If it takes an admin to impose pending-changes protection to specific articles, how likely is it that the community will be willing to entrust select non-admins with the power to do the same for any contrib from a specific editor? If these processes are intended to reduce the same type of problem while allowing good faith edits, it seems like they should march in synch as much as possible. (Ideally, WP:Pending changes would be modified to encompass both forms, page-specific and editor-specific) Next, what's to be gained? For starters, I think this might increase admin workload. On its face, the benefit is reduced visibility of potentially harmful junk until admins can take action but the same sort of admin action will still required. PLUS, there will be additional overhead demands on admins.... processing requests for PCB user rights and fielding complaints about abuse of the userright. With respect to complaints of abuse, I speculate this will be more or an issue with editor-specific pending changes blocks, since that is inherently more personal. Am I basing this on misunderstand? If not, any ideas for overcoming those possible hurdles? NewsAndEventsGuy (talk) 12:16, 1 November 2014 (UTC)
 * No, I don't think that one would need to restrict this to admins. As I mention here, pending changes protection is very visible and potentially interfering to editors because it is present continuously and for long periods of time on articles. On the other hand, pending changes blocks are very intermittent, with little actual interference on articles, and targeted to users who have a recent history of unacceptable edits. This makes it much less sensible of a userright and giving it to more users and automated processes seems appropriate.
 * As for admin workload, I do think that being pending changes blocked would discourage a significant proportion of users from continuing their disruption. We already know that edit filter warnings do so to some extent, and being warned that their edits are now subject to review before being published would have a certain dissuasive effect.
 * It is true that admins would have to promote users, but this would be a very small charge compared to other duties. Even more so for abuse complaints, which would probably be quite rare, since the use of this userright is pretty unambiguous, directed at obvious vandals, spammers or similar. Most of the complaints of abuse of blocking by admins comes from blocking established users. It would be technically impossible to pending changes block autoconfirmed (or confirmed) users, negating this potential. Cenarium (talk) 12:51, 1 November 2014 (UTC)


 * I'm with DGG on this, things are already too complicated as it is. I keep hearing about a shortage of admin, but I don't see proof.  I know that I avoid dealing with cases that I used to deal with because I'm tired of the drama that is allowed to happen, but that isn't due to a shortage, but a lack of willingness to jump into the fire.  More importantly, I might see some backlogs with closing RFCs, but I don't see a backlog of blocks, so I'm lost as to what question this proposal is answering.  Comparing to article PC only makes me more convinced this is a bad idea, as from my experience, that is a failed policy. Dennis - 2&cent; 15:06, 1 November 2014 (UTC)
 * And how is it a problem that it is complicated if it doesn't bother anyone ? The edit filter is extremely complicated, but does it bother you ? What is overly complicated and ought to be simplified is wikitext, this is critical so that more users can contribute, but the complexity of things running in the background like the edit filter, or pending changes blocks, are of little concern to anyone. As for not seeing a backlog of block, I would take exception with that, WP:AIV is chronically backlogged. The same goes for other administrative areas, which indicates the shortage in admins. Look at my rationale here, too. Cenarium (talk) 15:28, 1 November 2014 (UTC)
 * The edit filter is indeed complicated but its use does not require individual judgment of either people or articles. In fact, it does the exact opposite: it's just a set of regex expressions -- some simple -- some quite complicated. Devising them requires a knowledge or regex, and the people working on it are selected people who know it well enough, and have enough patience to test the expressions and decide which are worth using as filters. It's a technical device to soft out those decisions that don;t require judgment, not a way that requires judgement at every edit. Furthermore, it is addressed to a real problem--and to a considerable extent solves it--it reduces the amount of easily classifiable vandalism  to a considerably smaller percentage of edits than before its use. It does not by itself block or delete either articles or people, though it does prevent certain edits. It runs in the background, not the foreground.
 * As said, what we require is not simply admins or quasi-admins, but experienced admins willing to fairly make difficult decisions. Those are much harder to come by.  DGG ( talk ) 04:53, 2 November 2014 (UTC)
 * Yeah I've edited quite a bit of filters in the past. What I meant to say is that pending changes blocks would run pretty much in the background too. It would behave in a totally different way than pending changes protection, which I agree runs in the foreground and can potentially be interfering. Those blocks would be applied only on easily classifiable users, either as recognized by automated processes like the edit filter or anti-vandalism bots, or by non-admins users. Since it would have a certain dissuasive effect and would make the processing of those users faster, the disruption caused by pending changes blocked users to other editors would be minimal. In addition, this would offload some of the work of admins, furthermore a type of work that doesn't require much judgment. So admins should be able to refocus on those more difficult tasks that require judgment. In fact, I think that in the future it would make more and more sense to have a group of quasi-admins affected to user moderation, of which this new usergroup with pending changes block is an embryo (the development of WP:Flow will likely create uses for it too), and another affected to content moderation (with a role in regulating new articles, and maybe a soft deletion right, the wmf works on that as well). This would further reduce admin workload. Cenarium (talk) 12:58, 2 November 2014 (UTC)
 * Addendum : in this scenario, the existing group of template editors would form the third group of quasi admins, in the area of template / interface / technical. Cenarium (talk) 14:20, 2 November 2014 (UTC)
 * I've given more examples of users who would have been taken care of by pending changes blocks in the rationale and impact section (or see the refs) and showing the limits of the edit filter. For instance, the user clearly shows that even after an AIV report, an obvious vandal can continue its rampage, with some vandalism edits remaining for up to one hour on an article, and with a block happening when the user had been inactive for an hour. Cenarium (talk) 21:04, 2 November 2014 (UTC)

Feedback from MusikAnimal
Following FAC convention with this section heading, hopefully that's okay...

Coming from someone who regularly patrols recent changes, sees the ongoing patterns and trends, something like a pending changes block at a glance seems like a good idea. Things might already be complicated, but the degree of vandalism that the wiki endures only a daily basis is astounding. We are lucky we are able to keep it in the shape we do. Presumably with time this will only grow into a bigger and bigger problem, and that suggests a need for some better anti-vandal automation. PC blocks automatically applied by edit filters could satisfy this need. There's a lot more intricacies involved, though. A few ideas that immediately come to mind:
 * PC blocks would more or less always be applied by edit filters. While admins could apply them too, I don't see that happening much. To me, the idea is that edit filters, unlike humans, can identify an edit as unconstructive with confidence but not certainty. The PC block would then be a way for the automated software to force the edits to be reviewed by the more confident human.
 * To expand on this thought, if the edit filter was flaky, we're still only adding the edits to pending changes backlog, rather than disallowing them altogether. Bad, but not terrible.
 * Admins should not have to lift the block, but should have the capability to do so. After so many accepted edits or so much time has passed without editing activity, the PC block should automatically be lifted. This could be equivalent to when autoconfirmed would normally kick in.
 * After so many rejected edits, the user is automatically reported to AIV. Otherwise the pending changes backlog is just going to grow out of control. Some (as in LOTS) of vandals do not give up. Ever. We could even make a new section heading at AIV, "PC block reported" or the like. If this is were to be implemented, I'd disregard my next bullet point:
 * IPs should be exempt from this type of block. I say this for one reason only... most vandalism is from IPs. We should let them go to AIV as they normally do and be blocked accordingly. Schools IPs, for instance, may near match 100% unconstructive edits. There's no reason to let them continue to edit while PC blocked, each edit reverted or rejected by a reviewer, when that reviewer doesn't understand how issuing warnings and reporting to AIV works, etc.

In the end, we not only need community consensus on this, but also to get the WMF to implement it. I think the latter would be the more difficult. &mdash;  MusikAnimal talk 04:36, 3 November 2014 (UTC)


 * Good points! --SCalhotrod (Talk) ☮ღ☺ 15:30, 3 November 2014 (UTC)


 * Thanks for your feedback MusikAnimal. I'll reply to your main points.
 * It would indeed be very helpful to have PC blocks applied by edit filters. However, they can be evaded and don't detect a sizable proportion of even obvious vandalism. Hence my suggestion to grant this userright to a group of trusted users, including admins but also non-admins. This is how I see it : every time a recent changes patroller with the permission (admin or not) issues a last warning before a traditional block, they pending changes block the user as well. That way, none of the edits by the vandal after the last warning would go live, and that can be a lot of edits, I've given examples including and . Those two continued their rampage for a while and were no longer active when finally blocked. From what I can see among users reported at AIV, this is a common problem.
 * I think it should be a temporary measure, probably no more than 31 hours for IPs and 72 hours for registered users. Being warned that their edits are now reviewed before going live would have a certain dissuasive effect, so many would likely stop altogether. But if they don't, they should be fully blocked if the PC block was imposed by a user since they would have had a last warning. If it was by an automated process, they would be warned and blocked as normally done, but we should be more severe since they also got warnings from the edit filter (or bots).
 * One of the main objective of this is to make the processing of those users faster, not slower. So any user subject to pending changes blocks would have not only their edits at Special:PendingChanges, but also have their edits tagged, and it would be no problem to have them bot-reported at WP:AIV if they make two or more edits while PC blocked. In light of this and my previous point, it shouldn't add much to the PC backlog.
 * I think you'll agree that IPs should not be exempt in light of my previous points.
 * Yes, it's always a hassle to get those requests implemented, I've tried to keep the implementation as simple as possible, using existing software mostly. We'll see. Cenarium (talk) 13:36, 3 November 2014 (UTC)

Table
I have now added a table for clarity at User:Cenarium/PCB, it is a modification of Template:Pending changes table including traditionally blocked and pending changes blocked users. Cenarium (talk) 02:26, 7 November 2014 (UTC)

Feedback from Yaris678
Here are my thoughts: Yaris678 (talk) 18:09, 7 November 2014 (UTC)
 * PC protection is currently used for pages with a low edit rate. During the PC trial, it was observed that pages with a high edit rate would end up having a lot of edits pending before a reviewer got to look at them.  This gave the reviewer more work and the process gummed up.  Remember that once a change is pending all new edits are pending until a reviewer accepts the latest edit.  How do we propose to prevent this gumming up being caused by PC block?
 * If the above issue were dealt with, I can see this being useful for IPs that give a lot of vandalism but also some useful edits.
 * I would be avoid sending messages along the lines of "we will review all your new edits". Most vandals do it for the attention so promising more attention isn't going to help.
 * Thanks for your feedback.
 * This gumming up would be prevented on the condition that PC blocks are of short duration and targeted to users who are actively engaged in vandalism or other obviously inappropriate edits, who would be dealt with faster than now because their edits would not only be present at Special:PendingChanges, but also tagged and whenever they would do two or more edits while PC-blocked, they would be bot-reported to WP:AIV (we could even report them for a single edit while PC blocked, if it turns out to be more efficient). If you look at old pending changes, almost none of them are obvious vandalism or similar, those are easily recognized and get dealt with quickly, it's the passable edits that clog up the backlog. And we know with a very high certainty that users having recently committed vandalism or similar are very likely to keep making the same kind of edits, so there's little risk of clogging up the backlog.
 * I had anticipated this suggestion, see note 12, but unfortunately doing so would mean no longer satisfying the 'short and targeted use' condition of my first point, and this would risk increasing the backlog. If it turns out in the future that the backlog is easily manageable, this could be considered.
 * I don't think so, articles get less vandalism when placed under PCP, and vandals abort quite often when warned by the edit filter. There may be a wording issue to consider though, it should indeed be made impersonal. Cenarium (talk) 18:54, 7 November 2014 (UTC)

Preparations for RFC
I've made preparations for the RFC at Pending changes blocks/Request for comment. Any comments ? And if anyone has other suggestions for the name of the usergroup, it would be appreciated, I've only 'moderator' at the moment. Cenarium (talk) 02:15, 11 November 2014 (UTC)