Wikipedia talk:Pending changes blocks

Another piece of supporting evidence

@Cenarium: You might want to look at User talk:Winedmoves, which is the talk page of a vandal who continuously vandalized the article Egg 174 times for more than half an hour before being blocked. It may be a piece of evidence that supports your proposal.

Thanks, Tony Tan⁹⁸ · talk 01:19, 20 November 2014 (UTC)

Thank you, it does support it. I've added the example. Cenarium (talk) 03:28, 20 November 2014 (UTC)

I disagree

This would essentially force a type of Pending Changes on every single article, as a Pending Blocked editor's edits would have to be approved. I have to admit going a bit cross-eyed after looking at the chart, turning our editing into a Rube Goldberg machine. I'm not a fan of Pending Changes, although see a rare few times it makes sense. I'm not a fan of the whole concept of Pending Blocks as presented, but to be fair, as an admin who actually has to file the paperwork, I find the whole idea lacking. Who gets this tool, what is the criteria for when it is appropriate to give that bit? As an admin, I would never use it. I've 1700 blocks behind me, I've never wanted a "just in case" button. Anyone that I would trust to do this, I will just nominate for admin. As for the masses that would clammer to have that power, it isn't likely I would trust them with it, nor trust any single admin to decide, myself included. It is an answer to a question that hasn't been defined. I know you've put a lot of hard work into it, but from an administrative perspective, I don't see the value. I do see me having to unblock, drag people to ANI, block the blocker because some admin gave the bit to the wrong person, and lots of problems. What is lacking is a list of solutions this provides. As for your example and the benefit it would provide, that assumes someone with the "pending block" bit would have found them before an admin did. Once notified, it would take an admin about 10-15 seconds of investigation to block him, and another 5 to mash the buttons and reload the page. I won't bludgeon the page, don't worry, but I just wanted to be clear that while I appreciate the hard work that went into this, my personal experience, based on years of editing and admin work, is that it would be more work than not doing this, a net loss, and it would results in more editors getting disciplined for poor judgement in blocking other editors. RFA vets for this. A single admin does not. Dennis - 2¢ 22:54, 21 November 2014 (UTC)

Please don't bring experience into this, I'm an admin since 2008, you since just 2012. I wonder how you could read the proposal in such a very short time, in fact it's obvious that you didn't. PC blocks aren't for admins, you would get it but obviously it's better if you use your classical block button since that's where there's the greatest need. There is your answer about "who would get the bit" in #policy issues, it would be more than admin discretion. The kind of controversy you mention is so far fetched that it would have zero day to day influence, true there has been controversial cases of removal of below-admin usergroups, but they are rare and one more usergroup won't make a difference overall, it sure as hell won't be as controversial as removing adminship (and will be easier). Your assertion that admins block people after 10-15 seconds of being 'notified' is ridiculous, it can take hours for blocks to be made at AIV, which is one of the main reasons for this. You could at least have read the rationale section. And the usergroup is just a part of the proposal, there's also the edit filter which would defer edits and PC block. The assertion that this would force a "type of PC" on every article is totally baseless, read #impact analysis first I won't repeat myself here if you didn't even take a sec to read anything. Cenarium (talk) 23:34, 21 November 2014 (UTC)

I followed the previous incarnation, so it wasn't so hard to follow here, just read. Different, but problematic for many of the same reasons. And yes, I read it, in spite of your claims otherwise. I'm saying it is not a tool that I would even want as a user, so the context is wrong. As for a pissing contest over experience, I will pass. And if it takes more you than 10 or 15 seconds of looking at someone who has made 74 consecutive vandalism edits to one article...well, it wouldn't. All those summaries were oversighted, you wouldn't have to even look at the edits, you would have hit the big button in less than 15 seconds. THAT is the example they gave above. And yes, it does force a type of PC on every article, or at least every article that person edits. That is a technical issue, not a philosophical one. Again, you keep saying I haven't read anything as if you are saying this with some degree of authority, you are mistaken. I didn't just stumble upon the concept a minute ago. Dennis - 2¢ 23:45, 21 November 2014 (UTC)

If you don't want a pissing context, then don't throw your mop around. The time it takes for an admin to make a determination on whether or not a user should be blocked is irrelevant (it would take about the same time for a PC blocker). (And of course, I would have blocked this user within seconds of checking their contribs, but that's besides the point.) It's about the time between report at AIV and block, which can take hours. And actually it's really about the time between last warning and block on one hand, and between an edit flagged by a filter and it being reverted on the other hand. The example above, showing more than a hundred edits done by the user after having been reported at AIV, is just an example among plenty. Of course we would be more reactive and efficient if we would give this out to non admins, the edit filter, and Cluebot NG. All in all blocking is but a small part of admin duties and we're overworked pretty much everywhere. The idea that any user worthy of this right should rather be granted adminship may be theoretically appealing, but is inapplicable in reality. Plenty of users would be trusted with this but would or could just not pass RFA. Same for rollback or template editor, it's the reason we have those (and as a note, TE is clearly much more sensitive, and rollback can be abused much more easily than PC block, and with greater consequences). Thanks for acknowledging that articles would not be on any form of PC, it would indeed take a PC blocked user to edit it for it to be enabled until the user gets reverted, and for the reasons stated at #impact assessment, the revert would happen quite fast. My assertion that you didn't read the proposal comes from reading your posts, not from authority. I still don't get the meaning of your '"just in case" button' comment, why you're only mentioning the example above, or why you somehow imply that an admin takes responsibility for a PC blocker. When you mention dragging people to ANI, you mean for using PC block on another established editor in a dispute ? Cenarium (talk) 01:36, 22 November 2014 (UTC)

If we are going to use this case as a worst case example, the time difference between the first and last edit was 37 minutes, not hours. I went and checked the history of WP:AIV, and didn't see any entry, so it is invalid for measuring the response time of AIV. All we know for certain is that it is likely that it would have been less than 37 minutes, and likely much less. As for "Plenty of users would be trusted with this but would or could just not pass RFA", I agree, but I would argue that most of them that I would trust should be admins and the problem is RFA, not the editor. This raises the other issue, that any admin can grant this privilege. I disagree that admin have been vetted for this responsibility, and I am strongly opposed to allowing admin to do a function that more or less has been given to the community as a whole. I think giving admin yet more power, more ways to build little gangs by having control over what would probably be a desirable bit for future admin wannabees, is dangerous. It is my opinion that the ability to block editors should be decided by the community, not any single admin, because that is too easy to abuse, too difficult to vet alone, and too likely to cause problems, even by the most well meaning editors. That is where ANI comes in. You give "Bob" the bit, he makes a few bad blocks because he really didn't need it, it gets taken to ANI, people scream, the blocked editor "Alice" feels abused, rinse, repeat. I spent two years dealing with fights at ANI, I actually patrolled it (and SPI), and I'm probably the most common editor over the last few years. Doesn't mean much, except that I've seen problems with bits before, it isn't theory for me. Any new power means mistakes will be made, naturally, but bad Jr. Blocks will cause more drama than revert wars, and there is going to be a block log, which editors are quite particular about, so bloodying a clean one is not trivial to them, even if it was a rookie with a smaller block button. Dennis - 2¢ 01:59, 22 November 2014 (UTC)

You made my point about you not reading the proposal. I mentioned in the lead that it could only be used against new or unregistered users (and for specific reasons), and twice in the body that it would be technically impossible to PC block autoconfirmed users. There is this sentence, in particular, that might be of relevance : "Further, the vast majority of contested admin blocks are of established editors, but it would be technically impossible to pending changes block autoconfirmed users.". That admins can grant this privilege isn't a problem, I already told you that it would require more than admin discretion, and in case you're not aware, admins can already grant the abusefiltermanager usergroup, which is vastly more powerful. As for that example editor, here's the AVI edit, and there's the last user edit, 32 minutes in between (pretty close to 37). But it is far from the worst case scenario (in time). Look at those examples in note 4 for hours of latency, and it's only from checking the latest dozens of AIV reports a couple of days ago. Please read the proposal, or I'll cease replying. Cenarium (talk) 02:40, 22 November 2014 (UTC)

• I missed the one point about autoconfirm, but that doesn't take away the fact that few editors care about the TE bit and abusefiltermanager bit (or have the ability to utilize it), and many would want the PB bit, which is simple to use and has the impression of being a Jr. Admin. Having admin granting it IS a problem because of that perceived power. And I can't help but find humor in the threat, sorry, but it is obvious we will never agree. I'm against the proposal, I'm against the concept. I think you've put a lot of thought into it, and I don't question your intelligence or motives, but I think it is unworkable because of things you just haven't considered. Most importantly, I do not trust admin to have this power. We already have way too much power as it is. That alone makes it a deal killer. Dennis - 2¢ 03:33, 22 November 2014 (UTC)

• Well, that's pretty easy to restrict the granting (and removal) of this to bureaucrats, if that's what you're most worried about. But please do indulge me on those things I haven't considered. It's why I'm not launching the RFC straight away after all. Cenarium (talk) 04:32, 22 November 2014 (UTC)
• I've taken your feedback into consideration, and I think I'll change 'block' with 'restrict' since that's much closer to the idea. I'll also likely rename this proposal to "Deferred changes". Thanks, Cenarium (talk) 11:55, 22 November 2014 (UTC)

• I appreciate your consideration. By habit, I tend to be bold to a fault when I anticipate making only one statement, as was the case here. The idea of distributing more power to more people is a good thing, and that concept I like. I've supported "moderators", ie: quazi admin without block buttons, as some quality editors want those tools, for example. But as an admin with almost half my experience pre-bit, and a skepticism that still lingers and perhaps has been reinforced over the last 3 years, I don't want to tempt good admin and make it easy to become bad admin. I'm bothered by the complexity of the proposal, but if it were to pass, I would still feel better if each candidate went to WP:AN to request, and a consensus chose. WP:AN would be acceptable because this is an admin function, and non-admin are allowed to participate and given equal say. The first weeks would be messy, but longer term, I think the community as a whole should decide who gets to block them. I don't think Crats would want the authority, but I would have no problem giving them the authority to decide, either alone or in parallel with community vetting. Another alternative is requesting at WP:BN, Crats decide, but the community is allowed to comment (but not vote). The Crat decides if there is likely consensus on a larger scale to permit the bit, based on their experience. Their job isn't to vet the candidate, only to read consensus, which falls within their jurisdiction. As a fail safe, any admin can still remove it for cause, or lack of activity for a year. So while admin will have the technical ability to give the bit, policy will forbid it except under extraordinary circumstances, such as reverting an admin who took it away improperly, and when the community at WP:AN/ANI agrees the bit shouldn't have been taken away. This is a revert, not a granting, and done with community consent. Even if removed abusively, there is no emergency for that bit, so wheel warring isn't permitted at any level. These are just ideas, I haven't thought this out to the degree you have, and you are free to ignore. There are probably other good ideas, or better ideas, out there. The primary point is that we don't need to tempt admin by giving them more power. The community already thinks we have more than we need. Dennis - 2¢ 14:04, 22 November 2014 (UTC)

• Well, I was thinking of a small community discussion on a dedicated request page that would be closed by an admin assessing the consensus. However I wouldn't like it to become too big of a deal or it would defeat the purpose. Also, note that this right would be, in my opinion, much less abusable than rollback or undo. Indeed, if a user gets restricted, they can still edit and if they've been wrongly restricted, their edits will show up at Special:PendingChanges anyway and people would see it. Furthermore, a bot reports all restricted users still making edits at AIV, so that's not exactly something that could be kept under wraps. Unwarranted undos or rollbacks however can easily get unnoticed, and represent a greater overall threat to user participation. Also don't forget that this may be used only for vandalism, spam or BLP violations by new or unregistered users.

I've rewritten the proposal at Wikipedia:Deferred changes. Also note that this usergroup is but one of the five main proposals, others are for automated deferrals or restrictions. The points have been made clear in the draft RFC at Wikipedia:Deferred changes/Request for comment, or at least I hope so. I don't think that this is that complicated, personally, but sometimes I can write in a convoluted manner so it may need some clarifications. The table isn't as complicated as this one, for example. Cenarium (talk) 15:39, 22 November 2014 (UTC)

While I've moderated somewhat here, I still have reservations about it becoming the #1 target for hat collecting editors. Without question, it will be, as it is the "coolest" bit short of admin in a young person's (or immature adult's) mind. That doesn't undercut it's utility, but this isn't hyperbole, it is just one of the unintended side effects, and the better we anticipate those effects, the more we filter for them, and for your case, the more likely something will pass to begin with. You and I take the admin bit for granted, for the most part, it really is just some extra buttons. Really, the greatest things we do use words, not buttons, but to a typical 15 year old who has no hope to pass admin any time soon, this would be drool worthy. That is why I don't trust admin to give it, although just one to take it is fine. And wise. Not that they will build an army of 15 year old minions (although that is possible to an extent), but one person isn't enough to filter and vet. Many, many times, I have seen admin give rollbacker to someone with 100 edits and honestly, the editors were idiots (sorry, no other word suffices). But I digress....

I expect to on break very soon, and for a long time, so it is doubtful I will be around for the main event. I'm grateful you've taken my concerns on board. I don't have the right answers, but I do think I have some of the right questions. I've briefly looked over, but I'm incredibly short on time. One thing that isn't obvious to me is this scenario: "Alice" makes a questionable edit, "Bob" tags Alice for deferred changes, "Dennis" comes in and sees Bob acted in good faith, but was mistaken, so untags Alice. Do all those changes instantly get accepted, or must they manually be accepted? Does this go on the block log? We really don't want yet another log if possible. These are technical issues, not commentary on the merits, but others will ask and the answers aren't obvious. Is it a type of block, or a type of PC on a user? Again, the mechanics of it aren't clear, and perhaps that is because the technical aspects aren't worked out yet. Dennis - 2¢ 17:55, 23 November 2014 (UTC)

It is a type of PC applied on a user more than a block, all of their edits are deferred (made pending), and it may in addition limit the number of edits to 2 per minute, and other miscellaneous restrictions. Indeed, terminology matters, so for the moment I think I'll rather call this a "moderation", so a user gets "moderated" either by an automated process or a user. It seems closer to the idea. Bob may moderate Alice only when a "last warning" for vandalism/spam/BLP violations has been given to her, or at the same time as a last warning (or earlier for severe abuse). A single questionable edit wouldn't be grounds for it, if Dennis simply un-moderates Alice it won't review the changes, but a special page where changes by Alice can be batch reviewed could be created. Though I doubt that there would be a need for it since it should be caught quite fast, considering edits by moderated users are not only visible to reviewers, but also bot-reported at AVI (since further vandalism / etc would be grounds for a block). I think a separate "moderation" log should be created, so that these are transparent and easy to review, but it can be showed in the block interface after the block log (like the pending changes log when protecting). It is true that this would likely be a sought-after position, and we'll have to find ways to mitigate the potential for hat collection. Cenarium (talk) 10:45, 24 November 2014 (UTC)

A related proposal

Thanks for your work on this. I don't have time just at the moment to read it but I plan to this weekend. I thought I would draw your attention to a related (almost identical) proposal I made in the last Pending Changes RfC which was (rightly) hatted as out of scope, but you might find some enlightenment in the few comments that survived on the RfC talk page. Also pinging Jackmcbarn, who commented on the technical feasibility of this some time ago, and also who no doubt is watching the parent to this page anyway. Cheers. Ivanvector (talk) 23:18, 21 November 2014 (UTC)

It's doable, but it would take a lot of work by developers. After all the FlaggedRevs work for us ended up going unused, I'm not sure if anyone would be willing to do much more PC-related work. Jackmcbarn (talk) 23:21, 21 November 2014 (UTC)

@Ivanvector: Thanks for the link, it's interesting but different since I suggest to use PC blocks only against new or unregistered users and for vandalism and such.

@Jackmcbarn: Yeah, we're still the only wiki using this. It may be worth suggesting this to other wikis so that we have more weight, particularly the edit filter aspect ? Cenarium (talk) 03:11, 22 November 2014 (UTC)