Wikipedia:Requests for comment/Removing autoconfirmed

Source: Wikipedia, the free encyclopedia.

Discussing a proposal to make autoconfirmed an admin-removable group

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


  • Closing per WP:SNOW before we get bloody slush. Yeah, I know I !voted for it, but WP:IAR and all. Fences&Windows 16:29, 21 June 2010 (UTC)[reply]

---

Greetings, apologies if this is in the wrong place. Moving on from a tentative step at Wikipedia:Village pump (proposals)#Wikipedia:Autoconfirmed users and WP:SEMIPROTECTION I have been advised to open this RfC.

I wish to propose for discussion that:

the autoconfirmed group
be set as a removable group for all user accounts and IPs, removable by admins and above on a temporary or indefinite basis for the purpose of dealing with disruption.

I would view the benefits as:

  • Pages only need to be semi-protected, not fully-protected, to deal with disruptive edits by an auto-confirmed account if this removal is enacted.
  • Users with content dispute who are otherwise deemed as good contributors can be prevented from disruption without blocking or other sanctions.
  • Not only will it prevent targeted disruption, it will be such a slap on the wrist (as they are prevented from editing other semi'd articles) that it will act as a deterrent.
  • All admins now have another tool in the arsenal to deal with disruption, between warnings and blockings. This will (hopefully) assist in cooling down drama at such pages at
    WP:ANI
    because established users will not get controversial blockings on their record which are then debated to the hilt at the ANI board.
  • Users who have had this done to them can still defend themselves in an appropriate manner (so long as their defence does not violate other policies) without unblock requests, and can still edit areas outside of their 'problem area' freely.
  • Likewise, a blocking is more visible than a group-removal, so for the above situation the group removal will not cause unwanted 'stains' on otherwise good contributors.
  • Users placed on this restriction may be less inclined to sockpuppet in order to evade it, as they could still edit other articles and plead their case (so long as their defence does not violate other policies). Some issues of block evasion would be avoided.
  • It can easily be ramped up to a blocking if problems still occur, and it can be used after a blocking to slowly introduce difficult accounts back into editing - particularly for COI or AUTO or SPAM accounts that have had a change of heart.

There are other potential benefits to come to light in due course, and one or two problems, however interest at the VP has encouraged me to pursue further. It would probably require work by a developer or someone, and the upcoming trials may make it obsolete anyway, but I would like an opinion or two please. Apologies for the long opening. S.G.(GH) ping! 23:38, 13 June 2010 (UTC)[reply]

I notified
WP:VP. S.G.(GH) ping! 21:59, 16 June 2010 (UTC)[reply
]
  1. Support. It seems to me that this is a good idea, and you have outlined the issues very well here. It occurs to me that there would be a need to have something, perhaps in
    WP:BLOCK, to define when this option should or should not be used. --Tryptofish (talk) 14:07, 16 June 2010 (UTC)[reply
    ]
  2. Support. It's a really simple idea, I don't know why nobody thought of it sooner. Instead of being blocked they get placed back into 'probation'. How it could be used would become obvious in practice, but having the option shouldn't be too controversial. Fences&Windows 22:04, 16 June 2010 (UTC)[reply]
  3. Support Would be an excellent idea, but I would only support it's use as a temporary measure, not indefinitely. Immunize (talk) 18:28, 19 June 2010 (UTC)[reply]
    Just to clarify, you mean to support the temporary removal of autoconfirmed, rather than only a trial period of this idea? S.G.(GH) ping! 23:09, 19 June 2010 (UTC)[reply]
Correct. Immunize (talk) 15:07, 21 June 2010 (UTC)[reply]
  1. Support This would be useful for dealing with editors who generally contribute constructively, but are problematic in certain areas. It would also be useful for discouraging the creation of vandalism only accounts. RadManCF open frequency 14:23, 20 June 2010 (UTC)[reply]
  2. Conditional support I would ask that fairly specific guidelines be developed concerning the circumstances under which removal of autoconfirmed status should be done. While clearly useful, I wouldn't like to see this technique used on long-standing editors with a record of useful contributions, since removal of the status would prevent them from editing any semi-protected article, not simply ones in which they may have been involved in disputes. It's a technique that seems like it would be most useful for those "in-between" editors who are not blockable vandals, but nevertheless have subjects about which they can't seem to control themselves, in which case the collateral damage (i.e. inability to edit other semi'ed articles) would be justified. Since this amounts to something between a topic ban and a block -- a semi-block, in effect -- it should be used with care, and strong guidelines would help to insure that. Beyond My Ken (talk) 17:53, 20 June 2010 (UTC)[reply]
    "It's a technique that seems like it would be most useful for those "in-between" editors who are not blockable vandals, but nevertheless have subjects about which they can't seem to control themselves" - my thoughts exactly, but expressed better. S.G.(GH) ping! 17:59, 20 June 2010 (UTC)[reply]
    (ec)"Probation" someone above called it, and that seems an appropriate description -- and whether an editor is put on probation should be judged against their editing record, reputation, interactions, quality of contributions, etc. Like a block, it should be a judgment call, and not simply a "one size fits all" you-do-this-you-get-that standard. Beyond My Ken (talk) 18:00, 20 June 2010 (UTC)[reply]
  3. Strong oppose. Another solution in search of a problem. First, it is impossible to either assign or remove IPs from any usergroup. Only registered users can be assigned to a usergroup. Second, in how many cases will this new "tool" be necessary? The vast majority of disruptive accounts are voas or soas, who need to be blocked anyway. In addition, if a user can not edit just one article without disruption, it is likely that (s)he will be disruptive on other articles too, so the block is a better solution. Third, pages are protected in order to stop edit warring and provide time for cooling off. Protected page can not be edited by anyone including administrators without reaching consensus first. Instead of this, you are proposing to exclude certain editors from the process without stopping others from making edits. This contrary to the current protection policy. Fourth, I am not sure the removal will reduce drama—it is more likely to escalate it. Many users will regard the removal as more insulting that a block. Ruslik_Zero 18:30, 20 June 2010 (UTC)[reply]
    Comment: "Not only will it prevent targeted disruption, it will be such a slap on the wrist (as they are prevented from editing other semi'd articles) that it will act as a deterrent" What a complete load of crap.
     Giacomo  19:03, 20 June 2010 (UTC)[reply
    ]
    Play nice with the other kids Giano, or I'll take your ball away. Fences&Windows 19:09, 20 June 2010 (UTC)[reply]
    That would be a frustrating experience for you.
     Giacomo  20:20, 20 June 2010 (UTC)[reply
    ]
    Fences&Windows just quite gracefully illustrated why this is such a bad idea. Autoreviewer rights should never be considered a plum, a ball, a trinket, or a privilege. It's a tool. I know he probably meant "ball" as in "right to post on RfC's, but that makes little difference. Too many admins have this idea that they alone are the best judges of what behavior is best of editors, which then leads to horrible miscommunications and misinterpretations as they try to enforce vague notions of civility with negative reinforcement and punishment. It's insulting and it infantalizes admins and editors. It's a mindset this community needs to steer away from. --Moni3 (talk) 21:41, 20 June 2010 (UTC)[reply]
    Couldn't have said it better. This trend towards increased infantilisation of admimistrators and non-administrators alike needs to stop. But it's even worse than you say, because this isn't about the new autoreviewer bauble, it's about autoconfirmed.
    Fatuorum 23:39, 20 June 2010 (UTC)[reply
    ]
  4. Support This is definitely something worth considering in my eyes as this would decrease the number of blocks due to problematic editors.
    talk) 20:32, 20 June 2010 (UTC)[reply
    ]
  5. Oppose this most stupid of all ideas, as this new sanction can only be applied to named users. Is the intention to force every non-administrator to edit anonymously via an IP address?
    Fatuorum 20:37, 20 June 2010 (UTC)[reply
    ]
  6. Oppose Just in case, I was not explicit enough above, I oppose too.
     Giacomo  20:40, 20 June 2010 (UTC)[reply
    ]
  7. Oppose. Can I ask what is the main problem this proposal is trying to deal with, is it vandalism ,spam or NPOV? I don't see vandalism as a main problem for AC users, I don't see how this can prevent spam and I strongly oppose using this for NPOV issues. Sole Soul (talk) 20:42, 20 June 2010 (UTC)[reply]
  8. Oppose and absolutely not. Admins taking away autoconfirmed as a deterrent? That's a tremendously stupid idea. It fosters pettiness and admins reaching far beyond what their power should entail. Simply, just absolutely no. --Moni3 (talk) 21:36, 20 June 2010 (UTC)[reply]
  9. Seems like a solution looking for a problem to me. Stifle (talk) 21:37, 20 June 2010 (UTC)[reply]
  10. Oppose. This seems like a solution in search of a problem. The way to deal with targeted disruption of articles is to protect them; that works fine so developing the power to removed autoconfirmed rights is unnecessary.
    Nev1 (talk) 21:38, 20 June 2010 (UTC)[reply
    ]
  11. Oppose; the only reason this feature exists is to prevent some specific kinds of vandalism from showing up on articles— and the only reasons I could think of that would justify removing it are blockable offenses. It was not meant to be a trinket to remove as dissuasion, nor as a club to wield. — Coren (talk) 21:48, 20 June 2010 (UTC)[reply]
  12. Oppose; it's ridiculous to have sanctions for named users that can't be applied to anonymous users. As Malleus says, if this goes through we may as well all give up our user accounts and go back to editing anonymously. Richerman (talk) 22:06, 20 June 2010 (UTC)[reply]
  13. Oppose. Coren said it perfectly. -
    talk) 22:30, 20 June 2010 (UTC)[reply
    ]
  14. Oppose. Hardly encourages IPs to get accounts does it? --Joopercoopers (talk) 22:49, 20 June 2010 (UTC)[reply]
  15. Oppose Anythign that would lead to this button mashed ought to be dealt with by hitting the block button all together. No, no, and no. Anyone who has seen my comments at DRV would recognise I usually take a fairly wide view of acceptable use of admin discretion... but this is too much. Courcelles (talk) 23:16, 20 June 2010 (UTC)[reply]
  16. Oppose - requires quite a bit of effort, both from the developers and from us, for very little if any gain. Would also require that said troublesome articles be semi-protected. If you want to ban an editor from an article, institute a topic ban, but this propossal is going about things the wrong way. Nikkimaria (talk) 02:17, 21 June 2010 (UTC)[reply]
  17. Oppose - initially I was in favor of this, but as Coren correctly points out, there's blocks for any time that an AC user really would be eligible for this.  --
    (LiberalFascist) 02:48, 21 June 2010 (UTC)[reply
    ]
  18. Oppose (though willing to listen to disagreement on the reasoning) The issue I see is this line of concern:
    1. Autoconfirmed is mainly a semiprotection bypass/move permission. The proposal would ideally affect problematic users (SPA COI's, spam, warriors, etc) who have made enough edits to normally be allowed to edit freely, preventing them from editing specific target article/s along with IP editors and thus avoiding use of full protection or blocking.
    2. However, AUC users abusing page move or badly affecting widespread pages will normally be blocked instead, and semi-protection is likely to affect specific target pages not all pages. AUC removal would not help for repeat sock users (who would be handled in other ways such as IP blocking).
    3. Therefore AUC removal as an extra tool could only make sense in a few cases: where the non-socking AUC user has a narrow target (so the relevant pages are semi-protected to give it an effect), and where blocking IP editors as well as the AUC user is valid (if there's no general IP issue, we'd harm other editing and also wouldn't semi-protect).
    4. In summary, I'd think the cases where this might be used – where a non-socking AUC user targets one (or a narrow range of) articles, which also have an IP editing problem sufficient to allow semi-protection – will probably not be enough to justify the extra process, disputes and issues.
    That's without considering other points such as Coren's as well. As a last point, AUC covers all established users who are not admins, not just newly created accounts and SPAs; removal could easily be a Big Deal unless criteria (edit count?) exist. FT2 (Talk | email) 03:08, 21 June 2010 (UTC)[reply]
  19. Oppose, this comes directly from the
    bad idea machine. Blurpeace 04:23, 21 June 2010 (UTC)[reply
    ]
  20. Oppose no point to this.
    talk) 08:26, 21 June 2010 (UTC)[reply
    ]
  21. 'Oppose no good reason to institute. Joining the crowd.--Wehwalt (talk) 16:12, 21 June 2010 (UTC)[reply]
  22. Oppose, obviously. – 
    iridescent 16:22, 21 June 2010 (UTC)[reply
    ]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.