Wikipedia talk:Autoconfirmed Proposal/Poll

Change auto confirm

See also parent thread: Wikipedia:Village_pump_(proposals)#Page_move_speed_restriction

An alternative is to change autoconfirm - the point at which a new editor is allowed to move pages, create new articles, etc. - to require more effort. At the moment, autoconfirm happens in four days, regardless of the number of edits. Other language versions of Wikipedia have different criteria - for example, requiring at least 20 edits, plus a waiting period of a number of days. (Yes, that won't stop move vandalism, because it's easy to get 20 edits by just playing around with one's user page, but like requiring a captcha when adding an external link, if not logged on, it would make it more difficult for determined trolls to create sockpuppets. I would also deter casual vandals who couldn't figure out the system or didn't want to do the extra edits.) -- John Broughton (♫♫) 21:13, 29 April 2008 (UTC)

Agree, "only for confirmed" seems less painful. Incidentally, I think it is time we raised the autoconfirm limit to a week. Apropos autoconfirm, was there a reason why the en.wiki employs an N days instead of an N edits barrier? As for getting 20 edits to a talk page,... well, that could be resolved by only counting talk pages in article space or not counting talk pages at all. :) -- Fullstop (talk) 02:31, 30 April 2008 (UTC)

The problem with autoconfirmed is that it doesn't stop sleeper accounts. How about only allowing users with the rollback privilege to move "established" pages? An "established" page could be one that has 100 edits or one that has been around for more than six months or something along those lines. That would prevent a vandal from moving a high-visibility page, but would still allow a new user who accidentally creates a page with a typo to fix it. --B (talk) 02:54, 30 April 2008 (UTC)

I would worry that this could have the opposite of the intended effect. Instead of moving pages that are watched by dozens of people, they'd be moving really obscure things. Given an average of 16.98 edits per page, there would be no shortage of pages to move either. Mr.Z-man 03:29, 30 April 2008 (UTC)

That's true ... but my thought was that if there is nobody to see their ... umm ... handiwork, they might find other outlets for their aggression. I wouldn't be opposed to simply restricting all move to rollbackers/admins, but probably someone would complain about that. ;) Still, though, move is a much more dangerous function than rollback. If there is complicated page move vandalism (ie, A->B->C, followed by D->B->A) and the admin fixing it isn't careful in fixing it, they could wind up accidentally merging histories. The inconvenience of having to request a move or ask for help isn't that big of a deal. Maybe it could be restricted to one move per day except for rollbackers/admins. --B (talk) 03:40, 30 April 2008 (UTC)

Yes, there is a reason. At the time autoconfirmed was created, the user table kept track of when accounts were created but not how many edits they had made. Hence age was the only technically simple approach at the time. Now, we can ask for limits based on age, edits, or both. Dragons flight (talk) 03:36, 30 April 2008 (UTC)

This must be one of those moments when one feels oneself inundated with feelings of appreciation for the ongoing improvement of the software. :-) If its current level of sophistication does allow it, I am fully supportive of introducing a low edit threshold, in order to put a stop to the phenomenon of the so-called sleeper accounts. Twenty edits sounds just fine to me, and the required time (four days) needs not be increased; it would also spare us the complexities and potential inconveniences of restricted moving. Waltham, The Duke of 13:24, 30 April 2008 (UTC)

(undent)The problem with autoconfirmed is that it doesn't stop sleeper accounts. Let's be clear - we aren't ever going to find a perfect solution - the goal should simply be to make things better. Any change is going to have tradeoffs. Here's what becoming autoconfirmed means, as stated at Wikipedia:User access levels (I've reworded slightly for compactness):

Autoconfirmed users may move pages, edit semi-protected pages, and upload files or upload a new version of an existing file. They are no longer required to answer a CAPTCHA when adding external link, and may mark pages as patrolled in Special:NewPages.

Looking at that list, it strikes me that just about every item is something where we actually want editors to have a bit of experience with regular editing first, with the possible exception of uploading files. Even there, if the file is free content, it should be uploaded to Commons (which permits uploading immediately after creating an account). And for fair use files - well, these have been a real source of problems here, so I think there are benefits as well as disadvantages in requiring just a bit of editing experience before allowing that. Changing autoconfirm to require edits would also discourage those who see Wikipedia as a file-sharing service, or those who see it as a social networking site and want to upload a picture for their user page.

In short, it seems to me that there are clear benefits to changing autoconfirmed criteria (to give another example, discouraging the creation of new sock accounts in order to edit semi-protected articles), and relatively little cost. -- John Broughton (♫♫) 13:45, 30 April 2008 (UTC)

Well said, Mr Broughton. Actually, I don't think there is any cost for a twenty-edit threshold; new editors with good intentions will make these edits within four days anyway, or leave their accounts to be used at a later time. And one would think that by the time an editor is auto-confirmed, they will also receive their welcoming messages, with all the useful help and documentation links. It is a win-win situation. Waltham, The Duke of 15:04, 30 April 2008 (UTC)

• ":Autoconfirmed users may move pages, edit semi-protected pages, and upload files or upload a new version of an existing file. They are no longer required to answer a CAPTCHA when adding external link, and may mark pages as patrolled in Special:NewPages."

I think the question I would ask is: When do we feel that a new user could be considered competent enough to handle these tasks? Taking them in order:

1. As someone who is fairly active in XfD, I can tell you that Wikipedia:Naming conventions should be required reading before someone even thinks about moving a page. Not for the conventions, necessarily (though that might be a bonus) but merely the idea that there is a sense of consistancy to naming (or an attempt thereof).

2. Ditto for WP:DR, or more to the point, WP:3RR. after 20 edits, being able to edit a semi-protected page, may not be a good idea.

3. WP:NFCC. Rather large debate, atm. Let's lighten the load on the tagging bots.

4. WP:SPAM. Lots and lots of spam...

5. And allowing someone with 20 edits after 4 days to mark pages patrolled? No we can't stop determined socks, but the threshhold would seem to require a bit higher standard?

I think the requirement to vote in the board election (Three months and 400 edits) may be a bit too high:

• ("To be eligible to vote, a user must have been a contributor to at least one Wikimedia project for three months prior to June 1, 2007 (that is, by March 1, 2007), as indicated by the date of the user's first edit, and must have completed at least 400 edits with the same account by June 1, 2007.")

But I think it may be in the right ball park. One month and 100 edits, perhaps. - jc37 20:39, 30 April 2008 (UTC)

I don't think I've actually seen anyone abusing the patrol feature. I don't think we should be too concerned with that. Making people wait a while before allowing them to upload images would be great, though I'd be more focused on avoiding WP:BITE-ing newbies with copyright warnings than lightening the tagging load. I think the main concerns are pagemove vandalism (non-vandalism, but still incorrect pagemoves aren't really a problem), sleeper accounts editing semi-protected pages, and spam. However, I think 1 month/100 edits may be too high. Remember that not all new users get immediately addicted. It may take them a long time to get 100 edits and the captha will trigger for adding spam links and links for references. If you don't count the one edit I made in Dec 2005, it took me close to a full year to get 100 edits (January 11, 2006 - January 7, 2007). I think cutting that in half might be better, something like 2 weeks/50 edits. We want to deter the vandals and spammers, but we would like to do so at minimal expense to productive users. Mr.Z-man 21:02, 30 April 2008 (UTC)

I agree with your thoughts. As for the quantities (which, if this discussion goes towards implementation, will likely shift back and forth), I've seen people make 20 edits in their first day or two just organising their userpage/userboxes.

How about a month/60 edits. That's an average of 2 edits a day. And I don't think that waiting a month would be too much of an inconvenience. Who knows, maybe it will help foster the idea of talk page usage : ) - jc37 21:16, 30 April 2008 (UTC)

On looking at the above arguments, I agree that changing autoconfirm could also be a good solution. 2/4 weeks + x edits or so. GDonato (talk) 22:09, 30 April 2008 (UTC)

I'd prefer a slightly higher count than 4-weeks + avg. 2-per-day. So, how about 4 weeks + avg. 3 per day (i.e. 4 weeks + 90 edits).

As for Z-man's note of the capcha headache:

• We don't want links. We want referenced edits.
• Answering an average of 3 capcha's per day is not really more effort than an average of 2 capchas per day.
• Its good conditioning for "Wikipedia is not a linkfarm."

I also appeal to force the use of the edit-preview button during this period. -- Fullstop (talk) 00:27, 1 May 2008 (UTC)

To reply to the points: 1) And references quite often include an external link. 2) If they have 3 a day for a month, that's about 90 captchas just on this site. For a few days it would be fine, but multiple times per day, for a month? That would get really annoying very fast, possibly to the point of not adding references to avoid the captchas. 3) People need conditioning to not be spammers now? You get the same captcha whether you add 1 reference to a newspaper website or a dozen spam links all at once. Mr.Z-man 01:46, 1 May 2008 (UTC)

I think that extra work to create an external link within a citation really is the most problematical (and I missed that; my bad) . I think we should set the goal here to be to improve the situation, not to reach perfection. We want to place obstacles in the way of spammers (who hopefully will be shut down long before they have 20 edits, if they spam on each edit), and similarly reduce the extent of move vandalism (which won't be totally stopped; still, vandals will find the game much less fun if they have to do a lot more work for each account). If we go with 4 days and 20 edits (or something similarly modest), that might stop (say) 70 percent of the problem of registered editors who spam and do move vandalism. If we require (say) 50 edits and a month,that might stop 80 percent of the problem (another 10 percent, in this hypothetical example), but would really, really irritate new editors who know how to do citations (for example, they read the book about editing Wikipedia and have to do a CAPTCHA every single time.

In short, I suggest we not go overboard and create a monster. If we add a relatively modest edit requirement, and that doesn't seem to improve things much, then that would be the right time to discuss ratcheting up the requirements. But if we implement (or even propose) something requirements that are significantly greater than what exists now, we risk discouraging a lot of good editors (or having the proposal fail altogether), and we'll never know if something lesser would have reduced the move vandalism and spam problem almost as well. -- John Broughton (♫♫) 02:58, 1 May 2008 (UTC)

Thing is, I don't think that 4 days and 20 edits will deal with 70%m or even 35%.

One thing I will concede, though, is that here we are suggesting to all editors that edits be referenced, but then requiring capchas to add those links, for a month; that might not be a great idea.

However, due to the Mon-Fri student mentality (or for that matter, the Mon-Fri work week), I would like to see this longer than a week at the very, very least, and preferrably longer than two. "They didn't let me spam/upload/whatever this week, let me try next week." - So I suppose, 2 weeks should be enough. (I was thinking 3 weeks to equate to the 3 months of the board vote, but would settle for 2.)

Two weeks and 40 edits (well, rounding: 42 = 14 days multiplied by 3 edits a day) which is also 10% of the board vote edits requirement). I think that has a better chance of being that 70%. - jc37 14:17, 1 May 2008 (UTC)

How about 40 edits or 3 weeks then? (i.e. whichever comes first)? -- Fullstop (talk) 00:29, 2 May 2008 (UTC)

Because it defeats the purpose. On one hand, it's easy enough for someone to make 40 edits in a single day. And on the other hand, easy enough to make 40 sleeper accounts in a single day, forget about them for a month, and then activate them as needed. So by having both, they each act as a "check" on the other, proactively helping to prevent abuse. - jc37 04:41, 2 May 2008 (UTC)

I think that we should proceed in small steps. Going from four days and zero edits to fourteen days and forty edits is a long way. Adding the twenty edits to the requirements for autoconfimation, and perhaps increasing the days to five, will still greatly improve the existing situation, and not be as controversial. After that, we can see the results and act on them. Waltham, The Duke of 23:03, 3 May 2008 (UTC)

But (as I note above) I feel that anything less than 7 days is a waste of time. That said, 7 days and 20 edits would be exactly half of the 14/40. I'd be willing to discuss that as well, and obviously your further thoughts would be welcome : ) - jc37 17:50, 5 May 2008 (UTC)

← I personally like the 14 day/40 edit requirement. For a potential no-goodnik, the 40 edits will seem a long time to wait, and they'll be tempted to perform blatantly unhelpful edits in order to achieve it, which will make them easier to spot beforehand. Whereas 20 productive edits isn't really much of an investment and may seem "worth it", for someone who's just trying to reach the autoconfirm minimum and cause trouble. Equazcion •✗/C • 23:09, 3 May 2008 (UTC)

Not to say that this is necessarily a bad idea, but I really like that the autoconfirmed requirement is only 4 days and 0 edits. This allows me to hop over to other Wikipedias (with my unified account) and fix page titles, even though I have no clue what the article is actually saying about the subject. For example: [1] [2] [3] —Remember the dot ^(talk) 23:26, 3 May 2008 (UTC)

Note that any discussion here would only change the autoconfirm requirements for this wiki. A global change would have to be discussed on meta. Mr.Z-man 23:29, 3 May 2008 (UTC)

Well, perhaps autoconfirmation could carry over to all Wikimedia sites once achieved on one, once unified login is ready. Granted, it may be awfully convenient the way it is, but that's kind of a testament to how useless the current autoconfirm really is. Equazcion •✗/C • 23:31, 3 May 2008 (UTC)

I would oppose expanding the requirements for autoconfirmation; the current level is working acceptably. Page move vandalism is annoying, but trivial and not especially damaging to the project. On the other hand, the continued growth and development of the project depends on being as welcoming as possible to new editors. Christopher Parham (talk) 01:12, 4 May 2008 (UTC)

I don't think extending the autoconfirm is in opposition to being welcoming. I really don't think any new user whose intentions are productive will even feel confident enough to make a page move within their first couple of weeks of editing (I sure didn't -- took me a couple months). Same goes for editing semi-protected pages, which are always temporary anyway. I don't think anyone will feel unwelcome if they can't do those things. The move vandalism is more than an annoyance; it's a disruption, due to the steps involved in reverting it. If moves were as easily reverted as edits, there might not be a need, but that's just not the case. After 4 days of doing nothing, people can and have moved pages around, including policy and template pages. Autoconfirm might as well not even be there. Equazcion •✗/C • 01:27, 4 May 2008 (UTC)

They might not want to move pages, but they will very likely want to edit a semi-protected page. Many high-profile pages are already in a more-or-less permanent state of semi-protection, and the number of such pages is increasing. It is unwise in my view to confine new editors to lower profile articles. If it's felt that page-move vandalism is particularly tedious to clean up, the appropriate strategy is to develop a better technology for doing so. Christopher Parham (talk) 05:18, 4 May 2008 (UTC)

That was my original suggestion, see above this subsection. But short of such an improvement, which people seem to feel isn't feasible, an extension of autoconfirm seems to be the best alternative. Besides, autoconfirm was originally conceived of for a purpose, which it just doesn't seem to be adequately fulfilling. If it's to mean anything, it needs to be changed so that it isn't just 4 days of doing nothing. What is that confirmation of? People's ability to fill out a form and wait? That's not very reassuring. What would really be good is if there were another level of confirmation added -- a higher standard for page moves, while perhaps keeping the present autoconfirm for editing semi-protected pages. Personally I think allowing someone to move pages should be treated as a bigger responsibility than rollback, since rollbacks are reverted just as easily as any other type of edit, whereas page moves aren't. Equazcion •✗/C • 05:41, 4 May 2008 (UTC)

It should be possible to make it easier to revert page moves; there ought to be no reason why something that can be done with one press of a button shouldn't be possible to undo with one press of a button. The discussion you started above doesn't seem to have gotten to the point of discussing the actual technical obstacles. The point of autoconfirmation is to put limits on people who are acting impulsively. I would be much less opposed to raising the page-move limit if it could be separated from the semi-protection limit, but I still think the best solutions lie in improving our management technology rather than putting up additional limits on editing. Christopher Parham (talk) 06:04, 4 May 2008 (UTC)

I believe the technical problem with having an undo function for moves is that either the history needs to be merged back to the original page, or the original page needs to be deleted and the destination page then moved back. Both presently require admin tools and multiple steps. There are times when moving a page "over redirect" is possible, but in the case of the recent move vandalism that wasn't possible; I'm not sure exactly why. Perhaps the vandals made edits to the redirects after the moves occurred, but I'm not really sure about the specifics of when moves can and can't occur "over redirects". Equazcion •✗/C • 06:08, 4 May 2008 (UTC)

Even if admin tools are required, it could at least be made into a one-click process; but adjustments to the rule that limits one page being moved over another could perhaps allow normal users to make the reversions easily.. Like you I lack technical knowledge of the specifics but it seems to be that this ought to be considered first. Christopher Parham (talk) 03:29, 6 May 2008 (UTC)

Just a wild idea... How about allowing unconfirmed accounts edit semi-protected pages and then move the auto-confirmation to the two-week, forty-edit limit? If sleeper accounts are so effective, and simple vandalism is not that big a deal, perhaps that would work: trade the harder-to-revert article moves and media uploadings for some easily reversible vandalism usually caught in the recent changes.

This is exactly what the moderate idea of four days and twenty edits would avoid, but if some insist that it will be ineffective... What else can I say? The radical idea above would also avoid the probably unpleasant complication of a double auto-confirming process for different editing privileges (essentially a separation). Waltham, The Duke of 03:46, 6 May 2008 (UTC)

That would pretty much render semi-protection completely useless, so I doubt it'll happen. Separating the move privilege from the editing of semi-protected pages into two different rights groups with two different confirmation standards would be the best answer, I think. I'll say this again: Page moves have much more potential to disrupt than edits to semi-protected articles or even rollbacks. They should be more restricted than both of those, not less. Equazcion •✗/C • 03:58, 6 May 2008 (UTC)

• 4 days is basically worthless and only prevents a minimal amount of trivial vandalism. Mr.Z-man 03:46, 6 May 2008 (UTC)
• Increase autoconfirm and make a page move undo feature, if possible. Both are needed. Autoconfirm does next to nothing in its current state. It seems a large minimum edit count is unpopular, so if it becomes something like 10 or 20 edits, it stands to reason that while page move vandalism will decrease, it will still happen, so we still really need a way for ordinary editors to undo them. Equazcion •✗/C • 04:02, 6 May 2008 (UTC)

• I'd also like to say I'm not too crazy about the new format of this discussion, and I don't think this straw poll will actually get anywhere. I don't have my mind set on a specific autoconfirm requirement, so I hesitate to place my comment in any section. I believe autoconfirm should be increased and an edit count imposed, but by how how much is something that should be openly discussed further. Equazcion •✗/C • 03:26, 7 May 2008 (UTC)

I too find this new format lame, but I assume someone set it up because its easier than wading through the text. So, a "vote" (ick!) "per remarks" should do the trick. A change of opinion can always be reflected in a strikeout. -- Fullstop (talk) 03:38, 7 May 2008 (UTC)

• How about creating a new page for this: e.g. Wikipedia:Increase autoconfirm? GDonato (talk) 19:17, 7 May 2008 (UTC)

  Done (as you can see : ) - jc37 20:12, 7 May 2008 (UTC)

The issue here

The issue here seems to be the ability of autoconfirmed users to move pages, namely the Grawp sleepers. As a solution, moving autoconfirm up, which has other effects other than the ability to move pages around seems extremely excessive. My biggest issue with this is that it puts undue harm on new users. 4 days is long enough to put impulsive and impatient vandals to rest before they start editing semiprotected pages, but anything more than that is going to start having effects on the ability of new users to contribute. I would support something that required edits and/or a longer amount of time before users can perform page moves. That makes sense, and wouldn't effect anyone's ability to really contribute; how often do pages legitimately get moved outside of XfDs or long discussions? None. But since this proposal inhibits users from contributing via regular edits, this doesn't seem to make much sense to me, and seems like we're punishing people ("Sorry, you don't have enough edits to fix that typo", "Sorry, it'll be 20 days before you can insert that reference"). It's like removing someone's arm to remove a clot. Celarnor ^{Talk to me} 21:29, 7 May 2008 (UTC)

Perhaps I'm missing something, but how does this proposal prevent editors from general editing? - jc37 21:56, 7 May 2008 (UTC)

Because a large number of the pages new editors are most likely to be attracted to are semi-protected, and this number can be expected to continue to rise over time. Christopher Parham (talk) 22:21, 7 May 2008 (UTC)

I'm not sure that that's what Celarnor was referring to (and would still be interested in a clarification).

But in response, How is this any different than IP editors? If a page is semi-protected, there's presumably a reason. And I presume that's the point of autoconfirmation for requirement to edit protected pages, rather than just having an account. - jc37 22:42, 7 May 2008 (UTC)

Currently, if an IP wants to add a piece of information to Brazil, they have to sign up and then wait 4 days. Under the current proposal, they don't simply have to wait, they have to go make 20 other edits before they can even touch the page they are interested in. This is actually a much, much larger burden (it took you about 6-7 weeks, we can see, and this is probably not an atypical timeframe) and it further inhibits potential new editors from even bothering. We shouldn't risk damaging our ability to attract simply because we are concerned about some page move vandalism which has no material bearing on the success of the project. Christopher Parham (talk) 23:05, 7 May 2008 (UTC)

Christopher is correct; people are going to most attracted to editing things that are most popular, which are often the articles that end up being semi-protected. The way I've always seen it, autoconfirmation is to prevent someone from getting mad at something they saw someone say on TV or something, going to the article, registering an account and vandalizing it. Autoconfirmation makes them have to wait to be able to do this, and most people aren't patient enough to wait around four days to vandalize Wikipedia. That's what it does. It isn't some kind of punishment like "You're not a good enough editor with enough edits", it's just a mechanism to prevent vandalism. The issue here seems to be that autoconfirmed users can automatically move pages. That is what should be changed, not the amount of time at which autoconfirmation occurs. Celarnor ^{Talk to me} 23:01, 7 May 2008 (UTC)

Also, what's to prevent them from waiting four days, making 10 quick vandalism edits, then using the account to do whatever moves he was going to? That would also be a trivial matter, although not as stealthy as my previous capitalization bot example. There just seem to be enough ways around it that are so obvious and easy to do that the cost vastly outweights the benefits. Celarnor ^{Talk to me} 23:13, 7 May 2008 (UTC)

Celarnor, Mr Parham, I disagree with you entirely. Here are the three basic categories of newly registered editors, none of which I believe will be adversely affected by a seven-day, twenty-edit autoconfirmation threshold:

• I believe that a newcomer can bear to wait one week in order to unlock the few restricted non-admin tools; getting to know the exciting world of Wikipedia, reading the help pages, settling in their userpages, exploring the place, all that takes some days. Now, an editor who takes a long time to make twenty edits is an editor not especially keen to contribute at the time, so not being able to move pages or edit semi-protected pages does not seem to be of importance here, does it? (With the exception of a someone who registers an account with the express purpose of editing a specific page and nothing else; unless they have a Master's degree on the subject, I'd say they wouldn't be of much use there, especially if they don't know how to edit anyway). - Waltham, The Duke of 03:08, 8 May 2008 (UTC)

• If editing over 1,000 articles wasn't one of those tools, then sure, I'd agree with you. If this was just moving, yeah, new editors have no business doing that without knowing the naming conventions. If semi-protection wasn't used as systemically as it is, then sure. There would plenty of mainstream things they could edit to. Unfortunately, this isn't the case, and semiprotections get slapped on articles left and right, and making it harder for users to edit those simply to change their ability to move pages seems draconian. Celarnor ^{Talk to me} 05:24, 8 May 2008 (UTC)

• First of all, not all important or popular articles are semi-protected, and many of those semi-protected are so on a temporary basis, so saying that newcomers don't have material to edit is plainly wrong. That said, it might be a good thing that editors cannot edit the articles they care about the most straight away: it's not just using the tools that takes some time—what about NPOV? What about verifiability and No original research? Isn't it better if these editors learn our core values before editing popular and much-viewed articles? Read the talk pages first, discuss a few things perhaps, see how the community operates? Actually, not only is the proposal not biting the newbies, but it protects them from the biting they might receive from the more impatient users frequenting popular pages, who might misinterpret or be annoyed by rash actions done by newcomers? Auto-confirmation is not just good for the project: it is also good for the newbies (and, through them, again for the project). Waltham, The Duke of 20:58, 8 May 2008 (UTC)

• On the other hand, editors who do want to start contributing right away will easily find a way to make those twenty edits, and not necessarily in a disruptive way. Even playing in the sandbox could help them with their confirmation (and that is why I don't want the twenty edits to be limited in the mainspace). Remember, they are just now learning how to edit; they need to practise (preferably off the main namespace). - Waltham, The Duke of 03:08, 8 May 2008 (UTC)

• I wouldn't have as much of a problem with it if it was 10 edits that could be in the userspace and it was clearly stated somewhere that they had to make 10 little edits before they could start making "real" contributions, and there was examples of the kinds of edits that they could make. But there doesn't seem to be a lot of support for that, as it would be essentially useless; the person could just transclude 20 userboxes and be good to go. Celarnor ^{Talk to me} 05:24, 8 May 2008 (UTC)

• Even so, the editor would practice in editing. And all the other advantages of the proposal already mentioned (rendering sleeper accounts useless, deterring vandals, etc.) still apply. As I said, this is not to relieve us of determined vandals (we cannot do that), but of those who do not consider vandalising Wikipedia important enough to use their resources in order to create an auto-confirmed account. Waltham, The Duke of 20:58, 8 May 2008 (UTC)

• A third case is that of a user editing from an IP for some time before registering an account; such an editor would have gotten used to not having the privileges of autoconfirmed editors, so editing for one more week like before would probably not be an issue; for emergencies, there is always the ability to ask someone else to make an edit to an inaccessible page (that option is also available to the other two categories of editors, but they wouldn't know anything about it). - Waltham, The Duke of 03:08, 8 May 2008 (UTC)

• That kind of user, for whatever reason, has made the choice to edit as an IP. They aren't a new user of Wikipedia. I'm primarily concerned with the damage this does to new users, not the damage it does to users who have been around but haven't made accounts. It still exists, but they had the opportunity to avoid it, so it isn't as bad. Celarnor ^{Talk to me} 05:24, 8 May 2008 (UTC)

• Then we can get these out of the way. But if editors who spend a long time on Wikipedia feel comfortable without editing access to semi-protected articles, then that is not necessarily as bad as you make it sound for newcomers, is it? Or at least not to all of them. Waltham, The Duke of 20:58, 8 May 2008 (UTC)

Have I left anything out? I am a little sleep-deprived right now, but I can plug whatever holes there are in my reasoning on demand. :-) Waltham, The Duke of 03:08, 8 May 2008 (UTC)

And or Or

Making the autoconfirmed requirement "X days or Y edits" will have little effect on our most favorite trolls and vandals who sometimes use sleeper accounts that are months old. If it's not "X days and Y edits then any change will only inconvenience good editors while having little to no impact on vandalism. Thatcher 11:29, 8 May 2008 (UTC)

Clarification added. GDonato (talk) 15:27, 8 May 2008 (UTC)

And, for what it's worth, I don't believe the software (as currently written) can handle an "or" approach; if there is a time and an edit requirement, both have to be satisfied. (I'm sure the software could be rewritten, but I don't think anyone is actually proposing an "or" approach, so that's irrelevant".

Alternative

Rather than jumbling the ability to edit semi-protected pages and the other benefits of autoconfirmation together, why don't we just deal with the issue at hand, i.e, pagemove vandals? I see no reason why it can't be another rights level that is attained with 4 days / 10 edits (a higher number would make a lot more sense, considering that it is much harder to revert page moves) or whatever, but leave autoconfirmation the way it is so we aren't biting the newbies where it isn't absolutely necessary. That seems like a much better solution than increasing already harsh, although easy to deal with at their current level, restrictions on new editors to me. It also doesn't reek quite as much of assuming bad faith on the part of everyone who comes in with a new account. Celarnor ^{Talk to me} 15:45, 8 May 2008 (UTC)

Don't we have enough user groups already? Waltham, The Duke of 17:58, 8 May 2008 (UTC)

I actually think there should be more; I think that adminship should be a slowly gained thing as you gain more and more trust from the community; the "Take all or leave it" approach at RfA doesn't appeal to me. But that's a separate issue. I think that having another user group with an edit requirement before you can move things is trivial compared to the cost of the alternative proposal. I don't really see what the problem is with having another usergroup, especially when the only alternative the community can come up with is grossly biting the newbies. While the presence of another usergroup doesn't harm anybody, increasing autoconfirm to include an edit count that can take weeks to achieve for new users who can't edit popular (read: semi-protected) articles does. Celarnor ^{Talk to me} 18:14, 8 May 2008 (UTC)

There is no cost. There is no biting. The new-user status (read "not auto-confirmed") is an intermediate state between unregistered and fully registered editors, and neither the former nor the latter are affected by any change to the auto-confirmation process (as I said in the main page). The only group of users to whom what you say applies consists of those who register as soon as they come to Wikipedia, and I believe they can understand that, for their own good as much as that of the project, they will have to wait for a week and make a few edits before they receive the full privileges of editing. If they are interested in editing, then they can start playing in the sandbox, creating their user pages, and, most importantly, editing in any of over two million unprotected articles, many of which will be of interest to any given user. Moving pages should not be done by completely inexperienced editors, and many newly registered users are vandals who want to be auto-confirmed in order to vandalise the popular semi-protected articles which you mention. A well-meaning newcomer will have the patience and the understanding to wait a little before editing them, but a sockpuppeteer or vandal might easily be deterred (the persistent ones are hard to get rid of anyway).

Now, all that we are left with are those editors whom you mention, who will not make twenty edits for a long time. Tell me, why should we want to help editors register an account in order to edit a single article? These editors are rarely well-meaning, or are, at worst, contributing to the account clutter we are suffering from—if one indeed registers solely in order to edit a popular article, that article will probably not need their services anyway. (Have you any idea how many thousands of inactive accounts there are right now? Accounts with zero edits. And they are all auto-confirmed. Why? Their owners either are sockpuppeteers or they know next to nothing about editing.) Waltham, The Duke of 20:32, 8 May 2008 (UTC)

I agree with User:Celarnor. The page move vandals are the real problem , there are 2 ways to deal with this. Make pagemove more difficult or make correcting invalid pagemoves easier. I would support either a separate category for pagemoves or a change to the software to make undoing pagemove vandlism easier. I cannot support the current proposals as it also hits many anon IPs who simply wish to edit the growing sample of semiprotected articles. GameKeeper (talk) 21:52, 16 May 2008 (UTC)

Endgame

What's the consensus threshold here? It looks like 7 days and 20 edits has a solid majority, and the opinion that any edit requirement is better than the current system has even more support. The reasons are also clear: it has everything to do with thwarting vandals and sockpuppets, and nothing to do with biting the newcomers. I hope that, if the percentages stay as they are now, we won't have the typical gridlock that forestalls all policy changes on the rationale of "no unanimity means no consensus." That's my admittedly biased opinion. Shalom (Hello • Peace) 06:27, 9 May 2008 (UTC)

I say we should be looking to close this about 7 days after it started (say 00:00utc on 14 May) and that the current position does reflect consensus for 7d/20e. Any objections? GDonato (talk) 13:50, 9 May 2008 (UTC)

It's not just that the majority supports the seven-day, twenty-edit solution; several other editors have noted it as their second option. And there are the arguments to consider as well.

Seven days (for the poll) sounds good to me. Opinions keep arriving at a steady pace, so it would be imprudent to close this now. Waltham, The Duke of 03:42, 10 May 2008 (UTC)

I've posted a note suggesting that this be mentioned in the Signpost (that would be the issue dated the 16th or so). Because this is so important, I really think we want to keep this poll open until there has been more publicity - another week really isn't going to make that much difference, anyway. I suggest that if an item does appear in the Signpost, that the poll stay open for five additional days after that issue gets posted to user talk pages, and then close the poll. (Five days before not everyone is online every day.)

I also note that a note was posted at wikien-l on May 8th, and that this has been mentioned on every Village pump page (I think). And I put an announcement on the Community portal page yesterday. -- John Broughton (♫♫) 16:16, 10 May 2008 (UTC)

I didn't post to VP/misc. This seemed to "fit" for policy, proposals, and tech. (And to WP:AN) - jc37 01:29, 15 May 2008 (UTC)

Well, it's May 14. It looks to me like there's a fair consensus that the autoconfirm should be increased; and of the choices, 7/20 has a rather clear consensus.

That said, we're still having editors slowly come and add their opinion. I'd like to know what you all think about closing this and doing a bug request. (Or whatever the next steps are.) - jc37 01:33, 15 May 2008 (UTC)

Lets wait a little while longer, this poll is about to be included in the signpost - User:Ral315/News and notes - which should get more editors to comment. Davewild (talk) 06:53, 15 May 2008 (UTC)

I likeJohn Broughton's suggestion, so how about 20 May? GDonato (talk) 11:58, 15 May 2008 (UTC)

So long as we are not still getting a lot of contributions on 20 May that seems a reasonable date for the poll to be closed. Davewild (talk) 07:28, 16 May 2008 (UTC)

The bug needs to be reopened when this poll is closed. MER-C 07:23, 16 May 2008 (UTC)

Types of edits

As other have communicated, it's not feasible to mark mainspace edits or unreverted edits specifically, since there's no simple number to look up, like user_editcount from the database's user table. user_editcount, however, includes deleted edits. So someone can appear to have no edits while still being autoconfirmed under the new system (from Autopromote.php: case APCOND_EDITCOUNT: return $user->getEditCount() >= $cond[1];). Is this disagreeable? In terms of preventing damage from inexperience, having deleted edits may indicate unfamiliarity with policies of article inclusion, and possibly unfamiliarity with naming conventions. In terms of preventing damage from vandalism, I'm not sure if this will have an effect. Is this necessarily a bad thing? Gracenotes^T § 17:37, 9 May 2008 (UTC)

I don't think counting deleted edits has much bearing on this case. Auto-confirmation is about deterring vandals (or at least it's supposed to be, hence the proposal for its extension), not for newbie screening. There is a learning curve as far as policies are concerned, and many newbies are expected to err when creating their first articles; a simple explanation on the part of the speedy-deletion nominator or executor will probably suffice to show the newbie where they should be careful. Besides, the newcomer might as well be autoconfirmed before the edits are lost. What would happen then? De-auto-confirmation? Waltham, The Duke of 03:54, 10 May 2008 (UTC)

I agree - the point of increasing autoconfirm is to reduce vandalism, not to set a qualification standard for new editors. So yes, that any edit, even if subsequently not visible to regular editors because the page (or even the edit) was deleted, does count, isn't really a problem. (It is, admittedly, potentially confusing, but my guess is that editors will generally trust the software to do its thing, and won't bother to check if an editor really had X edits - whatever X turns out to be as a threshold - before doing whatever only autoconfirmed editors can do.) -- John Broughton (♫♫) 16:22, 10 May 2008 (UTC)

14 days, 10 unreverted edits to articles, and less than 1 reverted edit per 50 unreverted edits

1. Requires encyclopedia building, ensures that people don't have too many reverted edits, and ensures that people can't create an account and set a bot to edit articles for a short length of time in order to vandalise through the account. — Thomas H. Larsen 04:42, 12 May 2008 (UTC)

   I doubt that this is viable — although it might be codable, it would probably cause an unduly large amount of processing. Determining whether an edit has been reverted or not is non-trivial, and as worded this criterion would allow users to cease to be autoconfirmed under certain circumstances. Stifle (talk) 11:36, 12 May 2008 (UTC)

   I'm 99% sure this can't be done technically (without killing perfromance) GDonato (talk) 15:17, 12 May 2008 (UTC)

   This would be terrible for performance, yes. Rather than just (UPDATE editcount WHERE user=user), you'd have to (SELECT edit WHERE user=user), then run through each one, check if it was reverted or not, then check the two numbers against each other. This would have to happen after each edit. Depending on what other queries Wikipedia does at submission (I'm not a developer here, so I'm not sure), this could double the amount of queries done, and it is a lot of extra processing to do per edit for unconfirmed users. Celarnor ^{Talk to me} 17:59, 12 May 2008 (UTC)

   Perhaps it could just be done every n^th edit then, for unconfirmed users. Equazcion •✗/C • 18:04, 12 May 2008 (UTC)

   Since this requires more programming development than the main proposal on this page, and, as such, is outside the realm of this poll, I moved this thread to the talk page. Please obviously feel free to continue to discuss. Please also see the original parent thread. - jc37 02:14, 13 May 2008 (UTC)

See Also

Last fall we had a ton of discussion about this topic at Wikipedia talk:Autoconfirmed Proposal. It would probably be beneficial to read. I'm actually quite glad that someone resurrected this proposal. -Royalguard11(T·R!) 16:15, 15 May 2008 (UTC)

New idea - anyone interested?

What if admins could either (or both):

• de-autoconfirm a user who abused their status
• force a user to re-autoconfirm (ie stem their naughtiness for 4 days, or whatever the poll decides)?

I've not seen this idea; should it be added to the poll? —TreasuryTag—t—c 20:43, 15 May 2008 (UTC)

People who "abuse" autoconfirm are vandals and they're blocked. The point of this poll is to determine how to curb the amount of vandalism we have to deal with manually in the first place. Equazcion •✗/C • 20:50, 15 May 2008 (UTC)

They're not. There's a user who keeps adding crap to "Doctor Who" articles. The crap is mostly, however, added by IPs, so the articles are only semi-d; then he adds the rubbish, and no admin will block him, saying it's not that serious. This problem could be solved by de-autoconfirming him. —TreasuryTag—t—c 20:52, 15 May 2008 (UTC)

That's a very different issue from what we're discussing here then. This proposal is to prevent vandalism before it starts. I'm not saying your suggestion has no merit, just saying it's not another option for this poll. Equazcion •✗/C • 21:01, 15 May 2008 (UTC)

Autoconfirm exists pretty much for the sole purpose of deterring vandalism. I really can't think of any situation where someone would do something that would require autoconfirm rights, that was deemed unhelpful, that they do it repeatedly, but it would not result in a block. In the situation above, either semiprotection is being used inappropriately to forbid new users from making good faith but unhelpul edits or to force new users out of an edit war with established editors, or the edits are vandalism and the user should be blocked. Mr.Z-man 22:55, 15 May 2008 (UTC)

I was thinking of the same thing, if a user abuses editing simi-p pages, the move tool, adding external links or uploading files, why block them completely when de-autoconfirming them will do? Do we block admins that are abusing there admin powers, no we de-syssop them. Zginder 2008-05-16T12:43Z (UTC)

Auto-confirmation is a transitory stage between not having an account and having a properly validated account. It's a one-time thing; if a person is not worthy of having an account, then the account is shut down. The fact that vandals find moving pages and editing semi-protected articles attractive does not mean that they will refuse to vandalise in any other way—it is a matter of mentality. De-autoconfirmation will not reform vandals. An outright block, on the other hand, might. Waltham, The Duke of 13:11, 16 May 2008 (UTC)

This changes us

I just want spell out exactly what this 7/20 thing means and how big a change it is. Autoconfirm was never meant to infer trust, yet that's what we're changing it to. Semi-protect was never meant to be a class of articles that only trusted individuals could edit. Everything was basically supposed to be freely editable. Autoconfirm was just supposed to slow down potential vandals, not be a class of trusted users. This is truly getting away from the whole free-editability thing and more towards the "we don't trust you before a certain point" more common in other mediums. We're supposed be unique in that we trust everyone by default -- everyone is trusted until proven otherwise -- how strange yet noble of us; yet we're now about to lose a bit of that strangeness. Plus I think we may even see more vandalism, or at least, trivial edits that don't necessarily constitute vandalism but nevertheless will end up needing to be reverted while people try to make their 20 count. And all of this came out because we wanted to stop malicious page moves, which just seems like an offhand benefit at this point.

I just wanted to point all of that out. Equazcion •✗/C • 09:59, 16 May 2008 (UTC)

Agree per the Iron Law of Oligarchy. Zginder 2008-05-16T12:47Z (UTC)

I suppose it was inevitable, then, as further increases will be in the future. Equazcion •✗/C • 13:01, 16 May 2008 (UTC)

This should not be interpreted as part of a trend; it is a one-time event which does not need to be repeated. All that we are doing here is to correct one wrong: to turn an almost purely nominal auto-confirmation process into a meaningful and useful one.

And I believe you are still missing the point: Wikipedia is supposed to be as welcoming to anonymous editing as to editing from accounts, and to simply encourage editors to register. Tell me, is there anything an anonymous user can do that a registered-but-not-yet-confirmed one cannot? People just don't get it: the period up to auto-confirmation is a transitional one. Nobody with an intent to edit on Wikipedia regularly, or even occasionally, is supposed to stay there long. If it takes a person six months to compile these twenty edits, then why would they need the account and not just edit anonymously? I absolutely reject the self-contradictory view that on one hand we ought to be open and friendly to anons and yet from the moment a person registers they are supposed to be treated so differently from them. Waltham, The Duke of 15:15, 16 May 2008 (UTC)

If you think Wikipedia is supposed to be just as welcoming to anons as registered accounts, why would you want there to be an additional difference between registered users and anonymous users? Your rationale doesn't jive with what you're advocating at all. And to say this isn't part of a trend is just naive. Autoconfirm was already preventing some vandalism, but now we expect it to prevent more. There's no reason to think that later on, when we still have vandalism on protected articles, that we won't say "well why not increase autoconnfirm some more? That will assuredly prevent more vandalism." Equazcion •✗/C • 16:26, 16 May 2008 (UTC)

That doesn't really make sense. You can't maintain wiki-esque principles and widen the rift between new editors and experienced. As the above said, this also sets the dangerous precedent and encourages a mindset of "We can change autoconfirm whenever and cite vandalism as a reason". Today it's 7 days and 20 edits ... what if it ever becomes more than that? That kind of extreme, bad-faith assumption that new editors aren't capable of contributing to the project can only get worse. There will always be vandalism, and as I've said, it is a relatively trivial matter to farm edits with an automated process. As a tool for fighting vandalism and preventing sock accounts from getting autoconfirmed too quickly, this is useless and easy to overcome. As a tool for limiting the ability of new editors to participate in the project, it does its job superbly. Celarnor ^{Talk to me} 16:50, 16 May 2008 (UTC)

You seem to misunderstand the intent here. 20 edits is not too easy to overcome. This will only help the people who patrol for vandalism. Forcing more edits will force vandals to establish some sort of pattern to overcome 20 edits. And what if they don't? They may start actually editing articles constructively to get around it. That's never bad, and heck they may even like it. -Royalguard11(T·R!) 17:05, 16 May 2008 (UTC)

No one's misunderstanding the intent here. They (we) are simply disagreeing with you. We understand perfectly. Your intentions are honorable, but I say they are misguided. When autoconfirm was first conceived of, I'm sure a similar discussion took place -- they just wanted to curb vandalism, same as now. We still experience vandalism with it, so now we want to tighten things up more to prevent more vandalism. I don't think anyone is assuming this will eliminate vandalism -- they just think it will reduce it. Later, when we want to reduce it more, another increase may be seen as an option. No one's accusing anyone of intending to make the encyclopedia less free -- that's just an incidental effect.

Just to clarify, I'm not suggesting that this is necessarily a terrible change. It's just a really big change, bigger than I think most people realize. It's not just a technical throttle. This is a change in our basic philosophy. Again, not necessarily a bad thing -- but if you think this doesn't tamper with the core principle of free-editability, you're fooling yourself. Perhaps it is time to de-prioritize that principle. Many seem to think we're stupid for trusting people right off the bat, and that we're just asking for it when we get people taking advantage of that trust. We used to tell such critics that yes, that's right, we accept the risks and we deal with the problems, but we won't change because that's what makes this place so special. If we've come to a point where the majority of the regulars here feel it's time to value accuracy and ease of administration over our silly hippy roots, then I can't do anything about that. I just want to make sure it's spelled out, and that everyone here knows exactly what they're doing. This is a big change, and one that will likely begin a trend.

As someone linked above, this is an example of the Iron Law of Oligarchy playing itself out. You can say "No, even though there are similarities, this is totally different", but of course, that's what they all say. This will happen again, perhaps years down the line, but it will happen. If you want to stick to radical principles, you need to remain vigilante in not even straying towards the boundary. That's not what we're doing. We're already into the gray area. It's inevitable now. Equazcion •✗/C • 17:27, 16 May 2008 (UTC)

←First of all, I should like to make it clear that I do not believe anonymous users and registered editors should be treated in exactly the same way. I am not proposing any major changes, but I am in favour of some differences (and therefore support the measures of semi-protection, inability to move pages and upload media, and the usage of captchas for the control of the addition of external links). What I said in my statement above was that it makes no sense to discard all these protections for a user at the moment they register, even if with a small lag, considering that nothing has changed with respect to that user except for the simple fact of their registration (which many thousands of people seem to take quite lightly, registering and then simply leaving). I therefore consider it inconsistent for one to support that on one hand the anonymous editors should have as many editing privileges as possible and on the other hand to argue that it is really so important if they cannot leap from one state to the other in a heartbeat.

In any case, increasing the auto-confirmation threshold will only create a small delay in passing from being an anonymous editor to being a registered one. It does not create any difference between the two conditions because it does not change the privileges of either. And it makes absolutely no sense not to have a functional auto-confirmation process because then there would be no meaning whatever in restricting some features to registered editors: one would simply register and bypass the entire first line of defence against vandals. It is indeed useful to have this low picket fence of a four-day delay between the two zones, but all it does is to deter the most unwilling of vandals, and those who know very little or nothing about Wikipedia. Mind you, those who would know that unregistered editors cannot move pages or edit semi-protected articles are probably not amongst them. Therefore, almost anyone who sees the fence will jump over it with the greatest ease. What is proposed here is to replace the picket fence with a one-metre brick wall (with a vine growing on it). People will still be able to climb over it, but they must want to do that; if a person does not care much about getting to the other side they will not be so eager to climb the wall just for the sake of it.

I must say, Equazcion, that the debate has an interesting philosophical side, in that the dilemma which you pose, namely free-editability versus protection against vandals, has very real extensions in the outside world. (Is it not, after all, the great question of our times, "Civil liberties versus safety from terrorism"?) In my opinion, we should strike a good balance between the two, because going too far either way can destroy the project. However, one must accept that, compared to a few years ago, the balance has shifting towards the necessity for protection, because vandalism is growing, and the numbers of vandal-fighters are not catching up. Wikipedia is only now coming out of a phase of rapid expansion and growth, in terms of both content quantity and community size; it is growing into a more mature project, one which has different needs. To try a little harder than in the past to be on the safe side does not equal changing our core values, does it? As I said, it is a matter of balance; I honestly believe that solutions greater than the seven-day, twenty-edit threshold will be unacceptably harsh to newcomers, and I intend to vehemently oppose to any subsequent increase of the threshold. However, I do not find it so likely. We may be raising it this once; however, it is practically non-existent where it stands. The current limit seems to be a compromise between those in favour of its placement and those opposing it entirely. Now that there seems to be no serious movement against auto-confirmation per se, however, it is time to change it into something less symbolic than the modern Temple Bar.

Perhaps you are right that it is a big deal to armour the encyclopaedia against unregistered editors, trading some free-editability for protection. However, I think you are wrong as far as the timing is concerned. The change has already taken place—it did so as soon as semi-protection was instituted. If what concerns you is the fact that this proposal solidifies the change, then I can understand that. But the true next step will be when the auto-confirmation process will be felt by well-meaning editors who intend to offer their resources to the project for more than one or two times. If there is an attempt to take further action on this front, then I'll concede there is a trend.

And I shall hasten to support you in the opposition thereto. Waltham, The Duke of 21:06, 16 May 2008 (UTC)

I would also like to say that I would oppose any further increase. 7/20 is a good compromise between not scarring off potential editors and trying to hinder long-term vandals. Anything above 7/20 won't help anymore and would just hinder new users. -Royalguard11(T·R!) 21:19, 16 May 2008 (UTC)

• I consider it inconsistent for one to support that on one hand the anonymous editors should have as many editing privileges as possible and on the other hand to argue that it is really so important if they cannot leap from one state to the other in a heartbeat. -- Perhaps you misunderstood. I'm for everyone being able to edit any article easily, assuming trust immediately instead off demanding that people must earn it. The proposed change is contrary to that.
  • It is not necessarily conscious to the newcomers that by not making a mess in twenty edits they will prove to the community that they are not vandals, less so insulting. The years of innocence have passed for Wikipedia, and it just cannot rely as heavily as it used to on drawing new editors by ensnaring them with the original "we trust you from the first moment" policy (which, by the way, is not invalidated here; AGF is there for a reason). Besides, I don't know if you have noticed... But Wikipedia is famous now. Most people have already made up their minds about it, and it is not nearly as important a factor as it used to be to make a good first impression but not stopping them from editing the 0.2% of our most controversial (or simply vandal-targeted) articles.

• In any case, increasing the auto-confirmation threshold will only create a small delay in passing from being an anonymous editor to being a registered one. It does not create any difference between the two conditions because it does not change the privileges of either. This is a semantic argument. It doesn't change the privileges of anons or confirmed accounts -- but that's far from the point. It changes the privileges of newly-registered users -- the point being, again, that it demands the earning of trust, instead of assuming inherent trust.
  • The effect is minimal, and this is more about vandals dropping out in the process than asking our new arrivals to prove themselves in some way. All we do is to simply restrict them from playing, in their first twenty edits, with some toys which could prove dangerous for them and harmful to the project. You might oppose on principle, but there are serious practical concerns to consider.

• all it [present autoconfirm] does is to deter the most unwilling of vandals -- That's all it was ever intended to do. The proposed change is basically intended to make it stop vandalism-only accounts, at the price of forcing everyone to first prove that they aren't a vandalism-only account.
  • I shall rephrase: all it does is to deter the most, most, most unwilling of vandals. Apart from that, it's useless; with the current rates of vandalism, this simply will not do. Since we have semi-protection, we might as well make it meaningful, or remove it altogether.

• What is proposed here is to replace the picket fence with a one-metre brick wall -- That's a pretty good description of the problem. I was never a big fan of walls, especially in a supposedly "free society". I always found white picket fences to be more inviting than one-meter brick walls.
  • I was thinking of a handsome red wall half-covered by vines and other plants with beautiful white flowers... Think of it in spring, fully blossomed. Isn't it a sight to behold? :-)

• vandalism is growing, and the numbers of vandal-fighters are not catching up -- We're doing fine. I see no indication that we're "losing" any "battle". People always vandalized articles and we always had to revert them. Again this discussion started because of page move vandalism, which I agreed is a new and worse threat, but that's the only thing that needs to be dealt with. This semi-protected edit thing hasn't been discussed much if at all, and no one's presented any evidence that it warrants any action.
  • We are not losing yet; that is not reassurance for the future. Plus, a great percentage of the resources going into vandal-fighting could be better-used elsewhere. And I have given you several reasons why semi-protected pages should not be editable by newcomers, on their own right and not tied up to the chariot of move-vandalism protection. Increased biting danger is a basic one. And there is another thing: All this time we have been discussing accounts created for easily reversible vandalism; however, the power of sock-puppets and sneaky, under-the-radar vandalism has been little-discussed, and, in my opinion, is gravely under-estimated. These things eat away credibility in articles not much watched, until someone discovers the inaccuracies and the story finds its way to the press, making Wikipedia a laughing-stock.

• well-meaning editors who intend to offer their resources to the project for more than one or two times -- "Well-meaning" and temporary were always mutually exclusive. I see no reason to limit the abilities of those who only intend to make one or two edits (aside from page move restrictions). What's more I think the avergae new user joins without intending to make some kind of long-term commitment. I sure didn't intend that when I registered. I just wanted to try the place out and fix a couple articles. We get new people by sucking them in, they try it out and get addicted. We've all heard that story more than a few times. The lack of any requirement and the openness of the system is what makes people so intrigued and what makes them try it in the first place. As a long-time user, it's easy to expect new users to be ready to make a commitment in they want to be here at all, but that's just not how it works, not how this place was ever supposed to work. You can edit this page right now. That's the end of it. No requirements, no walls to climb, no probationary period, no earning of trust. We hand you the bazooka right away without a word and simply ask that you not fire it at us. That's what's so great and so weird about this place, and now we're killing it. Equazcion •✗/C • 21:35, 16 May 2008 (UTC)
  • The requirements are still more or less the same; I believe that you are making the ability to edit semi-protected pages sound much more important than it really is, especially considering that many of these are not that popular at all, and thousands of other, equally or more important articles, are not protected in any way. Couple that with the fact that new editors barely know about moving pages, and the effects of the auto-confirmation process are often barely noticeable. You have mentioned hindsight as a factor affecting my judgement on this issue... But how is it affecting yours? All these ideals that you mention are noble and admirable, but to what extent do new users think about them, and in this context? The impact of auto-confirmation is so small compared to the breadth and depth of the Wikipedia experience that it is rather unlikely to turn away editors who are, after all, just now orientating. Wikipedia is seven years old, and it has consistently allowed thousands of people to get inside and start working. Many of them have benefited the project, but think of how many more have fired the weapon at us? Should we keep exposing ourselves to them in the maximum degree? This is one of the most viewed websites in the world, it is the greatest encyclopaedia in history, and it is famous around the world. Things have changed from the humble beginnings in every level. You have every right to be nostalgic, but we need to face reality: vandalism is slow death. We have created this massive achievement, but it is a much greater task to keep it alive and well against constant, and often insidious, attacks. Even if it will require an ideological sacrifice. As a matter of fact, the decision has been taken for us already; free will is bound by circumstances. Unless you would choose the latter option when responding to the phrase "adapt or die". Waltham, The Duke of 00:58, 17 May 2008 (UTC)
    • Hindsight is not affecting my judgment, because I'm advocating something that benefits new users while making my life more difficult. You are advocating a change that will limit new users' abilities, and since you're not a new user and it would have no effect on you, other than to make your life easier, it's an easy thing for you to get behind. Equazcion •✗/C • 14:56, 17 May 2008 (UTC)
      • Virtually no one participating here is a new editor; if the criteria were that we could only vote on things that directly affected us, this poll wouldn't exist. But autoconfirmed requirements do affect those who fight vandalism - and if they had less of that to do, they would have more time to edit articles. I personally have worked on a number of things to make editing easier for newcomers to Wikipedia, and there is still much to do - but as in everything, the goal should be to balance advantages and disadvantages, not to advocate completely for one group of people (future editors) to the disadvantage of others (readers who see vandalism, including page move vandalism; editors whose watchlists end up with extra pages because of move vandalism; editors and admins who spend time reverting and repairing vandalism, and editors who need more time to figure out, from page histories, what is happening, because of vandalism and reverts). In short, less vandalism helps the project, just as more new editors helps the project, and less frustrated new editors helps the project. I think it's time to trust the community to have understood the pros and cons of each of the presented options, and to be willing to make changes in the future if this proposal turns out to have some unexpected consequences. (And I say that as someone whose preferred option isn't "winning" either.) -- John Broughton (♫♫) 20:08, 17 May 2008 (UTC)
        • Of course the best thing would be a balance. There's simply some disagreement on what constitutes the best balance. And of course, no one has suggested that only people who would be affected by a decision may vote on it... that's frankly a bit of a strawman argument. My point was simply that there is reason to suggest that people voting here might (sometimes inadvertently) be putting their own interests as experienced editors ahead of those of new users. Of course less vandalism helps the project, that's obvious. But more barriers also hurt it. Equazcion •✗/C • 20:22, 17 May 2008 (UTC)

Non-edit checking

Can there be a bot or something to flag a sleeper account that makes 20 quick non-edits (repeat or insignificant) in a row to quickly acquire the permissions? Especially if the 20 edits happen on day 8. - RoyBoy 17:06, 17 May 2008 (UTC)

I believe that there should be no such screening of new users, a process by nature prone to errors (and probably demanding in terms of resources). The automatic auto-confirmation process will deter many vandals and prospective sock-puppeteers, but those persistent enough will get through anyway, making a system of this kind more of a burden than an asset. Waltham, The Duke of 23:59, 17 May 2008 (UTC)

I'll have to agree with Waltham on this one. Any vandal who gets passed autoconfirmation will get dealt with in the same way we deal with them now: warned and then blocked. There's too many variables for a bot to possibly watch for them all. -Royalguard11(T·R!) 20:17, 18 May 2008 (UTC)

That isn't correct, and that isn't the point. Bots are getting more sophisticated these days, being a former programmer, it really isn't all that difficult to at least flag those obviously gaming the system. Then we could have a report on percentage of new users doing x and y, and for example time between last restricted edit and first reverted edit. If it's a short time, put the restrictions right back on. If the percentage is deemed substantial, do something about it.

What harm is there in being pro-active??? This could be largely academic when we implement Sighted versions, but even then it would reduce the amount of time spent doing background cleanup and blocking users who have rights they have no right to have. 20 edits in a row to your talk page shouldn't allow you to edit semi-protected pages. - RoyBoy 23:41, 23 May 2008 (UTC)

Perhaps not, but it still constitutes a significant improvement over the current system. And, in any case, de-autoconfirmation is not very helpful, and certainly not worth expending too great a part of our resources, because vandals will, in all probability, either remain vandals or simply leave the project—the former is most undesirable, and blocks ensure the latter. It would be another thing altogether to search-and-block such users—as all editors abusing their privileges should be, after ignoring a certain number of warnings—but this is, to put it plainly, not worth it. Too much fuss to end up just reverting to a state where users retain the ability to cause problems. As a matter of fact, the privileges restricted to auto-confirmed editors are not exactly crucial to their being useful (or harmful) to the community; I can wager that half of our newcomers are blissfully ignorant of the entire process until much later, when it is no longer of any direct consequence to them.

Now, as far as Wteaw is concerned... I have analysed the case in my last message in Bugzilla (the link may be found at the top of the following thread). The user in question made ten meaningless edits in their talk page, vandalised Evolution and its respective talk page once each, was reverted, and received a warning. The end. Two reverts and one warning and we might have ridden ourselves of a vandal. I do not find this a bad thing at all; how do you? Waltham, The Duke of 17:31, 24 May 2008 (UTC)

Closed

The poll has been closed by User:GDonato. It looks like there is enough consensus this time to implement this. See bugzilla:14191 for details. -Royalguard11(T·R!) 15:49, 21 May 2008 (UTC)

So it's going to be set to 7day/20edit then? —TreasuryTag—t—c 16:14, 21 May 2008 (UTC)

The person who filed the bug report (I believe it was User:Werdna) had a different view of consensus. His interpretation was that there was an 83% consensus to raise it to 10 edits, and I believe that's what's in place at the moment. It should have been 7/20 though. We're arguing over it right now. -Royalguard11(T·R!) 17:48, 22 May 2008 (UTC)

Whatever the results may be, I suggest you leave a brief note at the top of the poll page highlighting the results and including an update on the change request. - Mtmelendez ^(Talk) 20:04, 22 May 2008 (UTC)

I've added a notice saying the poll is closed, a link to the bugzilla entry, and a line for the current state of the autoconfirmed level. If it does change please change the notice (and the date) to reflect the that. -Royalguard11(T·R!) 03:34, 23 May 2008 (UTC)

I must admit I am a bit puzzled why more than 2/3 of the weighted opinions was not regarded as consensus... There should have been a discussion before bugging the devs to implement that change (or did I miss it?)... -- lucasbfr ^talk 07:05, 23 May 2008 (UTC)

That was what the poll was for. Someone just went above our heads anyways. -Royalguard11(T·R!) 16:27, 23 May 2008 (UTC)

There was clear consensus for 7/20. Conditional votes don't count unless the condition is met. So those that voted for 7/20, but would accept 4/10, or something else as a fallback vote if 7/20 failed, still voted for 7/20. To say otherwise is reading something not there. The results were a clear super majority for 7/20. 92 votes for 7/20 are more than all the others combined. — Becksguy (talk) 01:28, 24 May 2008 (UTC)

"Supermajority" and "consensus" are not the same thing. There are very good reasons not to raise the autoconfirm level to such ridiculous heights as 7/20, and ignoring them is not the route to consensus-building. Powers ^T 14:00, 24 May 2008 (UTC)

Consensus is not just in the numbers; please look at the arguments. There are equally, if not more, valid reasons to raise auto-confirmation to seven days and twenty edits, and to ignore them is not the road to consensus either, especially if a majority seem to embrace them. To whom is the proposed limit ridiculous? To drive-by editors? To vandals? To POV-pushers? Well, it should. Waltham, The Duke of 17:07, 24 May 2008 (UTC)

Yes, there are valid reasons on both sides; the problem is that increasing the threshold contravenes one of the five pillars: articles can be changed by anyone. While some limits are already in place, increasing those limits further is a further erosion of the third pillar. Powers ^T 18:58, 24 May 2008 (UTC)

Good point, Powers, as it's true they aren't the same thing. However, in this particular case the results were both a supermajority and a consensus for 7/20, based on the weighted votes and arguments. Strongly agree with Waltham. Maybe Flagged Revisions and Sighted Versions will do something about vandalism, and then autoconfirm levels won't be an issue anymore, as I think raising autoconfirm levels is essentially a Bandaid on the cancer of vandalism while waiting for a better fix. — Becksguy (talk) 17:36, 24 May 2008 (UTC)

I don't see the consensus. There's more than just a token group of die-hards arguing against a higher threshold; there's serious disagreement that hasn't been addressed. 7/20 represents a significant barrier to entry for new editors, and there's little-to-no evidence that it will deter vandals who aren't already deterred by the current threshold, or by 4/10 as it is now. Powers ^T 18:55, 24 May 2008 (UTC)

It is not a small group, but it is a group, in that the same few arguments are shared by them. And all of them have been addressed. If you believe something has been left open, bring it on; I'm up to the challenge. :-D

PS: The 4/10 is the current threshold. And having an edit limit is certainly better than no edit limit, because sleeper accounts will all but vanish now. People who just registered names they liked and after a few days reaped the crop will now find themselves before a nasty surprise. Still, ten edits is not enough, and, most importantly, four days is not enough; high-schoolers can register on Monday and vandalise on Friday. We don't want that. Waltham, The Duke of 22:25, 24 May 2008 (UTC)

So now they can register on Monday and vandalize on the next Monday. What's the difference? (Of course, they can vandalize all they want, registered or not, autoconfirmed or not, on non-semi-protected pages.) You're looking at this from the vandal's point of view, but the determined vandal isn't going to be swayed by an extra three days or ten edits, and the spur-of-the-moment vandals were already deterred as much as they're going to be by the four-day wait. The only people this seriously affects are the newcomers who want to write a new article or make an innocent change to a semi-protected article. That's not all of the newcomers, but we have no way of measuring how many potential new editors are discouraged by the autoconfirm process. Powers ^T 23:10, 24 May 2008 (UTC)

This change is not so much aimed at determined vandals, but one should also remember that there are different levels of determination. In any case, there is another, different category of users where this will be much more effective: sock-puppeteers. Some of them are doing it at an almost professional level, creating scores of accounts for vandalism or in order to back themselves up whenever they find it necessary (or both). Up to now, they simply registered a few accounts a day and let them ripen a little. Now they have to make ten days in each, which is a great delay, but it can still be done. Ten edits per account are not that much. But twenty edits per account and seven days' delay... For a sock-puppeteer, that could put them out of work, so to speak. You might be thinking of individual vandals, having to cross the limit just once. But think of it in terms of multiplication...

About the other thing, I really disagree with the view that not-auto-confirmed users are severely hampered in editing. All that is done is not to let them into some (very few and with potential for damage) privileges which are not given to unregistered editors anyway—and many of them keep editing without registering. It's not that serious. (And my line is not that hard, either; I suggest checking out the bugzilla thread.) Article-creation is not even one of those privileges; it is not restricted to auto-confirmed, but simply to registered editors. Now, concerning edits to semi-protected pages, an editor could as easily make a few innocent edits elsewhere first, learning our editing techniques and core policies before making edits to some of our most controversial and much-seen and -watched pages. The results of editors just driving by and making edits the wrong way could easily lead to biting and drama, especially in cases of big blunders, affecting negatively all the participants and potentially leaving the newcomers with a very bad first taste of Wikipedia, which could as well be their last one. This brief period of cooling down between registering and editing pages which have been semi-protected and for a reason has more benefits than simply deterring vandalism. It's for the newbies' good as much as for our own. Waltham, The Duke of 03:09, 25 May 2008 (UTC)

Just a suggestion, but perhaps User:LtPowers would be better served reading over the talk page to see the why of this proposal, than apparently "blindly" attempting to "re-argue". Expressing and/or discussing disagreement is of course a welcome part of the consensual process, but arguing apparently for the sake of arguing (especially after the poll has been "closed") wouldn't seem to appear to be as helpful. - jc37 06:11, 25 May 2008 (UTC)

I object to your characterization. I apologize for getting sucked into re-arguing the proposal, but it's clear this isn't resolved. My main point is just that: that rather than bowl over the very legitimate objections raised by those who don't think the autoconfirmed level should be raised by claiming overwhelming numbers, an attempt should be made to reach actual consensus. Powers ^T 13:24, 25 May 2008 (UTC)

You have yet to give specific objections which have not been addressed. If you will look at the poll and this page, I have addressed all of the objections raised, and examined the issue from all possible angles. I assure you that I should not be supporting this proposal if I believed that it would harm a category of users, especially Wikipedia's new blood. Waltham, The Duke of 20:20, 25 May 2008 (UTC)

I understand that you believe the barrier to entry that 7/20 represents is small enough to not affect newcomers. However, simply stating your opinion on that matter, while certainly a form of addressing the concern, doesn't do much to alleviate it. I admit I hadn't realized that page creation was not limited to auto-confirmed users, but I think an equal concern is the inability of new users to upload images. I still worry for the new user who, upon attempting to upload an image to help the encyclopedia, registers in order to do so, only to find out she has to wait a week and find some place to make 20 edits before she can upload this one image she wanted to upload. Also, what of the new user who encounters a semi-protected article slated for deletion and wishes to add references to rescue it? Or one with a particular interest in a semi-protected page?

In addition to the new-user concerns, there seems to be very little evidence that an increased threshold actually deters vandalism. It is my contention that extraordinary evidence of benefit is necessary to justify further erosion of our "anyone can edit" principle -- which is part of the third pillar I mentioned above.

So from my perspective, I see questionable, unproven benefit, and potential (albeit equally unproven) harm; in such a case, is it not better to err on the side of caution? The counterarguments I've seen seem to be summed up as "It's okay, this will stop a bunch of bad guys and won't hurt anyone who really wants to contribute" but I don't know how we're supposed to know that's necessarily true.

-- Powers ^T 03:31, 26 May 2008 (UTC)

(deindent) The "anyone can edit" principle is already limited. We semiprotect pages (which doesn't allow annon user to edit or non autoconfirmed users) all the time, and full protection is also used to stop edit wars. Full protection is also used sometimes to stop massive sock vandalism which we couldn't do anything about before because all you had to do was register N accounts, wait 4 days, and attack. Now they have to make edits, which doesn't seem like much unless you extrapolate it over N accounts. Just 3 accounts would means right now they'd need to make 30 edits to unleash a sock attack, and at 20 edits that number doubles to 60. I will say right now that this will make a difference. Semiprotection is preferable to full protection, and now semiprotection actually has some teeth. -Royalguard11(T·R!) 16:15, 26 May 2008 (UTC)

It's not working

[4][5] Raymond Arritt (talk) 00:56, 24 May 2008 (UTC)

According to what's currently implemented, it appears to be working. The account was over 4 days old and had over 10 edits (see above discussion). -Royalguard11(T·R!) 01:21, 24 May 2008 (UTC)

It's working in a technical sense, at least. But see Special:Contributions/Lewiscrouch (not entirely unexpected)... Gracenotes^T § 17:38, 24 May 2008 (UTC)

Yes, that's what I meant -- "working" in the sense of achieving certain practical goals, not the technical implementation. Thanks. Raymond Arritt (talk) 22:37, 24 May 2008 (UTC)

I think you've misunderstood what this is going to do. Adding in an edit requirement will slow down vandals and it will also force them to try to make good-faith edits before vandalism (which could have a side effect of making them think twice about wrecking the encyclopedia). It will also prevent sleeper accounts attacking a semiprotected page. It will not eliminate vandalism. We're just taking a speed bump and making it bigger. -Royalguard11(T·R!) 00:22, 25 May 2008 (UTC)

Well, at least he reverted some vandalism first. Does anyone really think 7/20 is going to significantly reduce the number of such incidents? Without discouraging newbies? Powers ^T 23:13, 24 May 2008 (UTC)

Yes, and so did roughly 100 people who commented in the poll. (Though I will note that I am surprised that non-autoconfirmed editors can use gadgets...) - jc37 06:11, 25 May 2008 (UTC)

So were the 10 edit requirement removed? See Special:Contributions/Malik_el_Sami_yn_Nasser? Carlosguitar ^{(Yes Executor?)} 01:25, 31 May 2008 (UTC)

That shouldn't be happening. The page was on move autoconfirm, the account was created after the change. I've filed a bug for this because users should not be able to do this. See bugzilla:14355. -Royalguard11(T·R!) 03:21, 31 May 2008 (UTC)

Never mind, I missed something. The user made 11 edits to their userpage, which were deleted (showing up at Special:DeletedContributions/Malik_el_Sami_yn_Nasser for those with admin bit). So it did work, you just couldn't see it and I missed it. -Royalguard11(T·R!) 05:34, 31 May 2008 (UTC)

Computer v. Wikipedian: 1–0. :-) Waltham, The Duke of 23:34, 31 May 2008 (UTC)

Re-run needed?

If this could be more helpful, I've set this up. —TreasuryTag—t | c 17:59, 25 May 2008 (UTC)

Transparency issues - I think most people would prefer a confused (but transparent) on-wiki discussion to plugging their choices into a third-party database. Happy‑melon 18:48, 25 May 2008 (UTC)

Any poll we do has to be on-wiki. I don't think we need a re-run, we just need the devs to implement what was reached by consensus. -Royalguard11(T·R!) 18:58, 25 May 2008 (UTC)

Yes, but they ain't going to :-( —TreasuryTag—t | c 19:22, 25 May 2008 (UTC)

Correct, the devs have decided that they aren't going to implement what we decided on. Here is a new poll (on-wiki) with only two options, so that User:Werdna won't be tempted to creatively interpret the results.

Undemocratic Implementation

Closing it and implementing 4/10 when 7/20 had wider support(62% vs 4/10's 17%) is undemocratic and sly. The structure of this poll and odd interpretation for 4/10 is ridiculous. It should have been 7/20 by the polls structure. (yes, it might have been better to vote for the day in one poll, and then the edits in another, for I preferred 4d/20e). But the implementer decided for the group, a concentration of power instead of power diffused throughout the wikipedian community. What if there was a (ridiculous) consensus for 30 days / 90 edits instead of 7/20. Would we allow the implementer to choose 4/10 or 7/20 or 14/40 with some illusory excuse interpretation of the poll, but not where most votes were? It suggests that the implementer put his/her bias in and choose. Thankfully it was under the bar as an open wikipedia is crucial to our success, but allowing this to happen can go both ways, which is why democracy works. This implementation is very upsetting and makes me doubt the process of community consensus and voting in polls. (perhaps the implementer thought we were a mob trying to rule wikpedia with a new blood majority) Kain Nihil (talk) 07:14, 29 May 2008 (UTC)

New poll

The devs have decided to ignore the will of the community and have reclosed bug 14191 despite protests. They have requested that we start the whole process over again in order to establish "unequivocal consensus". To that end, here is the new poll. Please express your opinion "unequivocally" there. Thanks. Kaldari (talk) 16:10, 16 June 2008 (UTC)