Last modified: 2012-11-17 14:04:24 UTC
A poll here shows 83% support for raising the autoconfirmed edit count to 10 edits or more. Support for raising it to 7 days/20 edits or more sits at 66% (as at filing this report). Please raise the autoconfirm edit-count to 10 edits.
Set to 10 edits for enwiki.
Per http://en.wikipedia.org/wiki/Wikipedia:Autoconfirmed_Proposal/Poll . Autoconfirm should be *7 days* and *20 edits* rather than whatever you just set it to, speaking to some people, they believe there is consensus for the 7/20.
The final results from [http://en.wikipedia.org/wiki/Wikipedia:Autoconfirmed_Proposal/Poll#No_change the poll] were: No change - 20 support (14%) One hour and ten minutes - 2 support, 1 oppose (1%) 2 days and 5 edits - 3 support (2%) 4 days and 10 edits - 25 support (17%) 7 days and 20 edits - 92 support (62%) 14 days and 40 edits - 6 support, 1 oppose (4%) 30 days and 90 edits - 2 support (1%) Counting support as +1 and oppose as -1, the total number of votes is 148. Percentages given in brackets. I think from these numbers it is pretty clear that this setting should be on 7 days and 20 edits. ~~~~
I believe that the consensus is strongly towards 20 edits *and* 7 days as shown by Tim. This bug should also supersede bug 10864 and that one should be closed.
(First comment in Bugzilla, for those who care; I never thought I'd actually register.) I should like to mention that consensus in favour of the seven-day, twenty-edit solution is stronger than the poll results on their own allow to be seen. The option in question has been explicitly or implicitly named as second preference by several editors who voted for other options. Namely: 4 days, 10 edits – Of the 25 votes in favour, 5 would accept it. 14 days, 40 edits – Of the 6 votes in favour, 3 would accept it. I guess that other editors might find it acceptable as well, without having said so. Actually, all editors supporting a higher solution would arguably have no problem with this one, as it constitutes an improvement over the current situation.
Is it possible to have edits to certain namespaces not "count" towards the edit requirement? I'm thinking in particular one's own userpage and the sandbox, so in general ignore either user/project or all non-main/maintalk. It hasn't been suggested so it's not something there's consensus for - just putting it out there as an idea at this point.
I don't think that the settings should be upped to 7/20 (days/edits) yet. Aside from that polls are evil, it's certainly arguable that a reasonable majority of users, including myself, support the 4/10 update but would vigorously oppose 7/20. Let's get *clear results* /before/ we make more changes, please.
Since when was 67%, what I can see as the maximum percentage that can be drawn up, consensus? Consensus is required to change and the status quo stays until there is consensus. At least 4 days and 10 edits has 81% support, I would call that consensus.
Random, apart from technically infeasible, I find your idea a rather bad one. The point is to let newcomers practise, and edits in the sandbox and their own pages do that thing exactly. Would you prefer that they should practise in the mainspace instead? Nihiltres, you say polls are evil, and I agree; one should take arguments into consideration. I have argued the case for 7 days and 20 edits more extensively than anyone else, covering all angles. I suggest having a look at those, both in the main and the discussion page. (The other principal parties in the discussions were Equazcion—who argued, however, for a completely different solution—and Celarnor, who later joined Equazcion in his proposal.) Zginder, there is 81–83% support for changing the auto-confirmation threshold, as it is deemed quite inadequate by the overwhelming majority of the participants. However, if you take that percentage alone, apart from the editors who do not want changes or even want to take the limit lower (and won't get their way anyway), namely the first three options, then the support for my preferred solution alone rises to 74%, and counting the ones above it, to almost 80%. I do not know what value these figures have (apart, perhaps, from showing how easily manipulated statistics can be), but, truth be told, the seven-day, twenty-edit option is by far the one with the greatest support amongst those who do not insist on preserving the status quo. That has to count for something.
I thought the point was to put obstacles in the way of malicious sleeper accounts.
(In reply to comment #10) > I thought the point was to put obstacles in the way of malicious sleeper > accounts. > Well, one of the points. The process is two-fold: On one hand, vandals must be deterred. Wherever they make their edits, they will try to make ten or twenty edits if they are motivated enough; is it not preferable to have them play in the sandbox instead of vandalising articles or sprinkling meaningless spaces around? Sleeper accounts will be stopped by the new limit anyway, so the question here is whether there are any benefits in restricting the inclusion criteria for edits. Mind you, it is a purely theoretical question, because it is not possible to implement such a measure, as has been mentioned in the poll (where a few people did state their desire to see only mainspace edits count towards auto-confirmation). On the other end of the equation, there are the legitimate editors to consider. A great percentage of them will probably not even notice the entire auto-confirmation process until long after the event. Now, said process (for them) is meant as a transitory period between being an anonymous user and having a fully activated account; for serious contributors that will be, by definition, a short period—for others it may take longer. In any case, apart from vandals, there are also the dangers of misuse of editing privileges by new editors, which justify why they should have to wait a while before moving pages (a process which could easily go wrong) or editing semi-protected pages (exposing themselves to premature criticism in case of a blunder). When first coming to the encyclopaedia, it is prudent for one to practise a little; this practice counts towards the increasing experience of the editor, and should therefore count towards auto-confirmation as well.
(In reply to comment #8) > Since when was 67%, what I can see as the maximum percentage that can be drawn > up, consensus? Consensus is required to change and the status quo stays until > there is consensus. At least 4 days and 10 edits has 81% support, I would call > that consensus. > 67% is 2/3 of votes. It's enough to override a Presidential veto in the US. There is overwhelming consensus to implement 7/20. Also, bugzilla is not the place to debate the merits of the proposal. The talk page on en-wp is for that. All we are asking here is for the devs to implement what has been reached by consensus on en-wp. That's it.
Well, there is consensus, wouldn't say it is "overwhelming" though.
There is overwhelming consensus for it to be increased. There is consensus for the increase to be up to 7 days & 20 edits. There is overwhelming consensus for it to be increased to the (new) current limits of 4 days & 10 edits if one count all preference for higher limit as accepting a lower limit as lower preference.
In my opinion, this is not overwhelming consensus but grudging consensus; more than 66% voted for limits above the four-day, ten-edit one, and they probably had good reasons to. The purpose of the whole story is to get done with auto-confirmation once and for all, not to risk another rise of the limit in the future. And seeing how many support a higher limit than the one recently implemented, I can see it coming. Don't take it for granted that all 66% will be happy with this; many are bound to see it as a half-measure.
And I repeat: it's not just the percentages one should look at. Examine the arguments, please. The whole essence of the proposed options is there.
"A poll here shows 83% support for raising the autoconfirmed edit count to 10 edits or more. Support for raising it to 7 days/20 edits or more sits at 66% (as at filing this report)." That is a terrible misrepresentation of the poll. The majority of people did not vote for "10 edits or more" they voted for 20 edits. You cannot assume that they also support a fewer or greater number. By a similar logic you could say that only 32% of the voters agreed to 10 edits or less. So we have now implemented the choice of only 32% of the voters, hardly a consensus or even a majority. The threshold should be set to 7 days and 20 edits as is clearly evident by the results of the poll.
By Andrew's flawed logic you could also say that 100% of voters support "at least 0 edits", so we should have just left it at 0. With logic like that he would make an excellent U.S. Supreme Court Justice.
The poll on enwiki is now closed and 150 people have voted in the poll. Here is the amount of votes and percentages No change (4/10) - 20 votes - 13.3% One hour ten minutes/0 edits - 2 votes - 1.3% 2 days/5 edits - 3 votes - 2.0% 4 days/10 edits - 25 votes - 16.7% 7 days/20 edits - 92 votes - 61.3% 14 days/40 edits - 6 votes - 4.0% 30 days/90 edits - 2 votes - 1.3% I personally have no opinion on which one is selected but the majority of voters by 67 votes chose 7 days/20 edits over 4 days/10 edits which has the second most support.
On a completely different note, I should like to apologise to those whom I have (repeatedly) removed from the CC list. Newbie gaff... I honestly thought I had forgotten to adjust a setting and sent e-mails to everyone with my every post for no reason. Stupid mistake... Although, to be frank, I'd never think I could really remove others from the list on my own. It actually makes me think that I've just given myself an argument in supporting a higher auto-confirmation level. I shouldn't be allowed to make such mistakes just after my registration. That should also apply to Wikipedia, don't you think? Anyway, I think I'll have to read some documentation around here over the weekend.
(In reply to comment #16) > And I repeat: it's not just the percentages one should look at. Examine the > arguments, please. The whole essence of the proposed options is there. You can dissect the arguments and make further proposals, while at the same time implementing the option with the largest percentage.
(In reply to comment #9) > Random, apart from technically infeasible, I find your idea a rather bad one. > The point is to let newcomers practise, and edits in the sandbox and their own > pages do that thing exactly. Would you prefer that they should practise in the > mainspace instead? I would prefer this not happen... repeatedly: http://en.wikipedia.org/wiki/Special:Contributions/Wteaw I have acquired an account at bugzilla because I am FED UP with this focus on allowing newcomers ludicrous free reign on Wikipedia! We are not talking about editing vs. no editing; this is about additional Privileges only Users should have. And by users, I mean someone who has edited the article space and has been forced to interact with articles and users working on those articles. 4, 10 or even 20 edits in minutes on your user space/sandbox does not a User make, regardless if its a vandal account or its someone truly practicing. I'm sorry, but practicing on your userpage for a day shouldn't grant a newcomer Privileges they aren't even aware of. But if you are a vandal... well then you are quite aware. Just because we have bots quickly reverting obvious vandals doesn't make this status quo acceptable.
Interesting example, I must say. But quite irrelevant from the point you seem to be trying to make. This is a so-called "persistent vandal", a person who will not be daunted by any auto-confirmation measures we put up. It's the kind of user this proposal is not targeting; it never pretended to. Now, note that Wteaw made ten useless edits in their own talk page, and on the first edit in the mainspace a warning appeared in that same talk page. Counting Talk:Evolution, only two reverts were necessary to undo the harm this user did to the project before receiving the first warning. If, on the other hand, Wteaw had done all the edits in the mainspace (and they could still have, on unprotected pages), that would have been at least ten reverts to make (unless, of course, these edits were simple spacing additions), and the user would still get just one warning (even if a level-two one), because the edits were all very close together in time. Therefore, the current system might as well have just saved vandal-fighters 80% of the work they might have had to do otherwise (not to mention potential under-the-radar small but still hurtful changes in little-viewed articles). In any case, auto-confirmation, apart from being a means to deter vandals, is meant for little else. It is mostly an intermediate period between not having an account and having a proper account with full editing privileges. It should be a cool-down period for new, enthusiastic users who want to jump into editing without being properly equipped. It should not be a screening process. It should not present serious obstacles to well-meaning editors who just want to contribute. It should, if possible, be felt as little as possible by newcomers. Do not mistake a vestibule, which all should be able to cross promptly if they do not carry weapons, for a quarantine. Auto-confirmation is supposed to be useful, but do not expect too much of it. Especially a change in Wikipedia's fundamental values, and free-editability is one of them. True, it has been—and has had to be—compromised to an extent for anonymous editors, but that still does not mean that we should make their lives hard. Wikipedia owes them as much as it owes its registered editors. PS: It would be much more boring for Wteaw to have to make twenty, rather than ten, similarly pointless edits; many such users might quit halfway through. I beg the developers to see sense in this and raise the limit to seven days and twenty edits, the option which the majority of the participating Wikipedians has supported.
> Therefore, the current system might as well have just > saved vandal-fighters 80% of the work they might have had to do otherwise (not > to mention potential under-the-radar small but still hurtful changes in > little-viewed articles). Interesting point... but it is necessary to establish some intent/ability to edit articles prior to having access to Semi-protected articles. While I am flirting with blasphemy here, it wouldn't be tough to setup a way for all edits by a new user to be auto-reverted. > Do not mistake a vestibule, which all should be able to cross promptly if they > do not carry weapons, for a quarantine. Auto-confirmation is supposed to be > useful, but do not expect too much of it. While I'll take your point auto-confirmation is supposed to be, however, your expectations will not inform mine. "Do no carry weapons", I like that because it is exactly what auto-confirmation should on a basic level. A quick series of unnoticed non-edits shows what? Not much apart from patience. > Especially a change in Wikipedia's fundamental values, and free-editability is > one of them. True, it has been—and has had to be—compromised to an extent > for anonymous editors, but that still does not mean that we should make their > lives hard. Wikipedia owes them as much as it owes its registered editors. Yes yes, free-editability, I'm aware the majority of content comes from anons; but semi-protected pages tend to be well developed and do not need an infusion of content. Rather they need maintenance, protection and a more sophisticated approach to user permissions for vandalized high traffic articles. Wikipedia isn't the wild west anymore. A registered sleeper account with no edits to the article space is a User in name only; they have not earned any trust by Wikipedia to edit semi-protected articles. > PS: It would be much more boring for Wteaw to have to make twenty, rather than > ten, similarly pointless edits; many such users might quit halfway through. I > beg the developers to see sense in this and raise the limit to seven days and > twenty edits, the option which the majority of the participating Wikipedians > has supported. Indeed, its a start.
This is tiring... I have to deal with both those finding 7/20 too high, and those who want stricter criteria for edits. This might be the clearest evidence yet that the solution I continue to support is the best compromise. Anyway... Point one: We have rollback. It is not that far from what you are asking for, and significantly less controversial. Point two: This whole story is to make auto-confirmation more meaningful and substantial, not to completely change its character. It discourages vandals and sock-puppeteers; it does not perform customs check on them. The purpose of the change is to relieve stress on the already existing, and largely successful, anti-vandalism system: recent-changes patrolling and regular views of pages, both fitted with revert and often rollback, as well as bots and various other tools. What you are suggesting is to create an expensive overlap, and a system prone to errors and misunderstandings with a potential impact on our newcomers and the project's reputation overall. We are not issuing visas here—think of Wikipedia as an internal state of the Shengen zone: no border controls, but still an effective police force. Point three: Most of our semi-protected articles are Start- and B-class; they certainly need content and improvements, even if the need is not necessarily urgent. True, most drive-by editors will not have much new to offer, but we must not make it forbidding to experts and others who do have information to offer their resources as soon as they learn the basics of editing and policy. We must, again, balance the need to keep the articles accessible with the need to keep them secure. If we take out vandals, twenty edits will probably be constructive, and the editors at that time will practice in editing and perhaps read a few help pages (forget not that after a few edits they are likely to be welcomed and be provided with a series of useful links).
Page move vandalism is still a big problem on en.wiki. I think we should try the 7/20 that originally had the most support.
Agreed. Why hasn't that happened yet? I'll send an email to Brion to ask what the hold-up is.
Funny, I also sent an email off to Brion about 3 weeks ago. No reply or anything.
(In reply to comment #27) > Agreed. Why hasn't that happened yet? I'll send an email to Brion to ask what > the hold-up is. > It will be done when some system administrator has time to do it. Please do not email system administrators for non urgent requests. Brion is a busy man and probably does not have the time to deal with every enhancement request immediately.
(In reply to comment #29) > (In reply to comment #27) > > Agreed. Why hasn't that happened yet? I'll send an email to Brion to ask what > > the hold-up is. > > > It will be done when some system administrator has time to do it. Please do not > email system administrators for non urgent requests. Brion is a busy man and > probably does not have the time to deal with every enhancement request > immediately. > ...especially when he did it at first and then everyone changed what they originally wanted and changed the "consensus". Let it stick for longer so that there are obviously no objections, and it's not that urgent after all. :-)
Page move vandalism is effecting people's watchlists by adding things we can't undue, making it unlike other kinds of vandalism. The last one that triggered my own watchlist included a page move that renamed a userpage to a person's first and last name, their age, and where they lived. Thankfully that user was already open about that info. Perhaps the real issue here is that the page moves make automatic additions to the watchlist. The number of page-move vandalism does seem to be decreasing since the last change to autoconfirm, so I guess it isn't urgent, but please understand our frustration and concern.
I thought it would be appropriate to respond to this while I was tired, just for fun. (In reply to comment #25) > This is tiring... I have to deal with both those finding 7/20 too high, and > those who want stricter criteria for edits. This might be the clearest evidence > yet that the solution I continue to support is the best compromise. Anyway... They aren't "finding" anything. They "think" its too high; good for them. I think otherwise, good for me, based on my extensive Vandal Fighter experience. Try it, and let the actual findings dictate further action. We are operating in a Wiki environment after all. > Point one: We have rollback. It is not that far from what you are asking for, > and significantly less controversial. Okay. > Point two: This whole story is to make auto-confirmation more meaningful and > substantial, not to completely change its character. It discourages vandals and > sock-puppeteers; it does not perform customs check on them. The purpose of the > change is to relieve stress on the already existing, and largely successful, > anti-vandalism system: recent-changes patrolling and regular views of pages, > both fitted with revert and often rollback, as well as bots and various other > tools. What you are suggesting is to create an expensive overlap, and a system > prone to errors and misunderstandings with a potential impact on our newcomers > and the project's reputation overall. We are not issuing visas here—think of > Wikipedia as an internal state of the Shengen zone: no border controls, but > still an effective police force. Visas sounds awfully elaborate. I just want to know if they intend to do more than masturbate at the border, then once across unleash some inconvenient graffiti in high traffic locations. The fact its cleaned up quickly is nice, but isn't sufficient rationale to explain the ease with which they give us the finger while ignoring bots. > Point three: Most of our semi-protected articles are Start- and B-class; they > certainly need content and improvements, even if the need is not necessarily > urgent. True, most drive-by editors will not have much new to offer, but we > must not make it forbidding to experts and others who do have information to > offer their resources as soon as they learn the basics of editing and policy. > We must, again, balance the need to keep the articles accessible with the need > to keep them secure. If we take out vandals, twenty edits will probably be > constructive, and the editors at that time will practice in editing and perhaps > read a few help pages (forget not that after a few edits they are likely to be > welcomed and be provided with a series of useful links). http://en.wikipedia.org/wiki/Category:Semi-protected_against_vandalism Doing a quick scan of articles, by names alone there aren't many start articles. I would acknowledge semi-protected vandalism articles tend to be more watched than others; but this consequently means they tend to be more trafficked. Bots do have their limitations (usually designed) hence part of my dissatisfaction. Further our strategy needs to be accountable to the reality that vandals become comfortable with our anti-vandal strategies. (sectional blanking for example, rather than bot reverted article blanking)
I honestly cannot believe I'm the thirty-third commenter to this bug. These discussions true are not appropriate for this forum. However, from a technical standpoint, I will say that raising the limit to 7 / 20 would do nothing to solve the problem trying to be addressed currently. Grawp, et al. are currently using throwaway accounts to wait four days, make ten edits to a sandbox or userpage or revert a few things on RecentChanges, and then the accounts vandalize with the autoconfirmed status. Raising the limit would add three days and ten edits, but would have no real impact on anyone but legitimate users. Recommend RESOLVED FIXED and that we move on.
(In reply to comment #33) > However, from a technical standpoint, I will say that raising the limit to 7 / > 20 would do nothing to solve the problem trying to be addressed currently. Very possible, which is why I proposed we get some stats at http://en.wikipedia.org/wiki/Wikipedia:Administrators'_noticeboard#page_move_vandalism_statistics If nothing changes, then we just drop back down to 4/10, but I believe it's worthwhile to try and find out.
The old "4 days autoconfirmed" seemed perfectly satisfactory... page move vandalism will continue, unless moves are always set to sysop-only as $wgGroupPermissions['sysop']['move'] = true; - which is a very last resort. It should just have been left as it is for now.
(In reply to comment #35) > The old "4 days autoconfirmed" seemed perfectly satisfactory... page move > vandalism will continue, unless moves are always set to sysop-only > as $wgGroupPermissions['sysop']['move'] = true; - which is a very > last resort. > > It should just have been left as it is for now. That's all find and dandy that -you- feel that way, but when we asked the community they decided to go with 7/20.
Ugh, arguing on Bugzilla. Take it back to the wiki, please.
(In reply to comment #37) > Ugh, arguing on Bugzilla. Take it back to the wiki, please. > You seem to be missing the point here. We *already* argued about this on en-wp and then by *consensus* we determined that we should implement 7/20. See the link above. The only problem here is that the devs are stonewalling us. I have hoped that the devs were busy or something, but after almost a month of ignoring us I'm also considering the possibility that they are implementing their own consensus. It's a little coincidental that the reporter of this bug is a dev (without shell access) himself. Devs are more likely to trust one of their own. It's the same thing with admins, we trust each other. I know that's not going to help us, but I'm going to throw it out there anyways. I would just like to make sure people note that the devs are ignoring consensus right now, which is in violation of probably our most kept principal.
When this "survey" was taken, (http://en.wikipedia.org/wiki/Wikipedia:Autoconfirmed_Proposal/Poll#No_change), Grawp wasn't really doing much damage so it wasn't necessary, but in previous weeks, the vandalism levels due to him has increased and since 7/20 had 92 supports, it probably should be implemented but its advisable that you have another "final" poll, though I disagree with 7/20, due to its collateral damage on newer useful editors.
What would be the point of having another poll if the community is going to be ignored by the devs? If we have another poll and it gets 100% support for 7/20, would the devs change it to that? If they just need extra convincing of the community's consensus (as obvious as it may seem), they should state so.
Please keep discussion off this bug, and open a new bug for the new proposed change, with a link to unambiguous consensus for the proposal. Note that systems administrators are reluctant to do enwiki shell requests which do not have unequivocal consensus, after somebody tried to have a developer dealt with by the arbitration committee for implementing a request with "only" 70% support. Relatedly, please do not make comments on bugs which do not add substance to the discussion. Especially in shell requests, this discussion is best off done on the wiki, where making a comment does not send an email to all developers.
Are you kidding? The request that was implemented had only 17% support! I wouldn't call that "unequivocal consensus". Stating that we have to do another poll is a slap in the face to the community, but if that's what we have to do, we'll do it. Your statement that 4/10 had 83% support was absolutely untrue. I know this because I personally supported "7/20 or higher" not "7/20 or lower" as you falsely characterized everyone's vote. I would suggest that you don't file any more bug requests that concern poll results until you have taken a course in statistics.
PLEASE NOTE THAT THE REQUESTED CHANGE, IF IMPLEMENTED, WILL HAVE NO EFFECT ON PAGE MOVE VANDALISM. Given that the change was performed as requested (to 4 days, 10 edits from 4 days, 0 edits), a status quo which had existed for years, there's no real rush to make another change which will be equally ineffective; the difference between 10 sleeper edits and 20 sleeper edits is fairly inconsequential. If you're concerned about page move vandalism, THIS IS NOT THE PLACE TO PUT YOUR EFFORTS.
While it has been a bit frustrating that 7/20 that the community supported did not get changed, I've become convinced in the last few days that what Brion, MZM, Andrew, and others have said is pretty much true. Some new ideas are popping up on changing how autocomfirmed itself works, and other possible solutions, that would be best discussed back on the wiki. En.wiki can be pretty demanding/impatient at times, but I hope the developers and others reading these messages know that deep down we do appreciate all that you guys have done for us (and the thousands of other wikis that run on MediaWiki as well). My own apologies for any snippy comment I might have made, and/or just generally wasting time chasing after a solution that probably won't work.
*** Bug 10864 has been marked as a duplicate of this bug. ***
