Door #8: Separate confirmation levels for semi-protected edits and page moves
I honestly feel like I want to support a really high standard for autoconfirm, because the lack of the ability to move pages really doesn't fly in the face of free-editability, as no one with constructive intentions who's been here less than a month is going to know how to, or feel the need to, move any pages. However even someone here a few seconds may want to edit semi-protected articles. They're such different privileges with such different associated risks, that I think they really need to be split into two different confirmations -- a high requirement for moves and a low (or unchanged) requirement for semi-protected edits.
I know the consensus above is going towards 7 days/20 edits, but this proposal was a response to recent move vandalism, and I urge everyone to really consider the effect that would have on semi-protection. If move vandalism is what we seek to address, then let's just address that, without having to deal with the issue of semi-protected edits, which is only even related due to a technicality in the software. I accept that the requirement for semi-protected edits may also warrant an increase, but I wonder if everyone really feels it warrants the same increase as the requirement for page moves.Equazcion •✗/C • 12:31, 12 May 2008 (UTC)
This is a much, much, much better idea than creating a longer window during which new users can't edit pages. Like I said in the talk pages, these are really two separate issues, and only one of them has presented itself as something that needs to be fixed. It seems rather harsh to punish new editors by further increasing the amount of time where they can't edit semi-protected pages just to change how long before they can perform page moves. Celarnor Talk to me 14:12, 12 May 2008 (UTC)
- This split is only justified if we are to adopt a high auto-confirmation threshold, and that does not seem to be consensus so far. How is seven days and twenty edits much? First of all, this is a measure against vandals; true, the usual vandalism on pages can be more easily reverted than moving around pages, but why not avoid this where we can? Semi-protection would be largely useless if an a vandal could create an account, leave it for four days, and then freely vandalise popular pages. Unless, of course, you should like to increase that limit as well: having, say, a threshold of four days and five edits for editing semi-protected pages and seven days and twenty edits for moving. At any event, they would be so close that it would be ridiculous. As for my other point, newcomers should not be able to edit semi-protected pages from their first seconds. These are usually much-viewed pages, and most newcomers' ignorance of Wikipedia's core values and editing practices would easily result in very public mistakes, and in the subsequent harsh comments. Not all editors—experienced or not—are good at avoiding newbie-biting; why let newbies go to the places where they would be most likely to receive it? As I have said again, a slightly higher auto-confirmation threshold than the current one (including editing pages with the silver padlock) would be beneficial for both the project and the newcomers. Waltham, The Duke of 15:11, 12 May 2008 (UTC)
- That sounds good in theory, but semi-protected articles are generally the ones people want to edit the most. If potential new users see an article they want to edit and then find out they can't until they wait a week and perform 20 edits, it's reasonable to conclude that a good many of these people simply won't bother. Having to wait 4 days without requiring any edits on the other hand isn't enough to deter constructive people. This discussion started because of page move vandalism, which is a pain to revert, and often even requires admin intervention. It can't remotely compare with edits to semi-protected articles, which can be fixed with a click or two by almost anyone. It doesn't make sense that something so much more potentially damaging has the same requirement as something so benign by comparison. Equazcion •✗/C • 15:30, 12 May 2008 (UTC)
- I do not believe that we really want some of our most popular articles to be treated as sandboxes. They are not just amongst the greater targets for vandalism, but they are also some of our strongest test-edit magnets. I insist that newcomers should pass from a brief adjustment period before being given access to articles which have been protected from editing by anonymous accounts for a very good reason. Auto-confirmation is a transitory period between being unregistered and being fully registered, and should be dealt with as such. It would be completely useless if someone could by-pass it simply by registering and waiting a little.
- Besides... The KISS principle has its merits. It will be much easier for newbies to accept a single intermediate period before receiving full editing privileges than having to pass through two (or more, if we are to pursue this trend further) such stages; it's too much to take in, especially for such a short time span. Explaining auto-confirmation in a place seen by all new users as they register will be enough to make them understand the concept that there will be some limitations. If they have the understanding that we want in Wikipedians, then there should be no problem. If not, then they are probably either going to leave early, or to cause problems (or both).
- Why should we content ourselves with fixing one problem when we could do away with another at the same time? Sure, simple vandalism can be reverted more easily than moves. But why keep valuable resources tied up in vandal-fighting when they could be more constructively used elsewhere? We have to think forward. Waltham, The Duke of 03:51, 13 May 2008 (UTC)
- Per above. There's no reason to keep the two inseparably linked like this if circumstances only call for changing one of them. Celarnor Talk to me 14:14, 12 May 2008 (UTC)
- The circumstances do call for changing both of them, because the current system is almost completely useless. Waltham, The Duke of 15:11, 12 May 2008 (UTC)
- How so? Changing the requisites for move rights would (possibly, although extremely unlikely, considering there are numerous avenues to farm edits with bots which would be trivial to write) eliminate the HAGGAR spam. Celarnor Talk to me 20:16, 12 May 2008 (UTC)
- The circumstances may call for changing them both, but not each by the same amount. Equazcion •✗/C • 15:31, 12 May 2008 (UTC)
- This sounds like a totally separate proposal to me that should be dealt with separately. Kaldari (talk) 18:23, 12 May 2008 (UTC)
- I disagree. The other options are to either extend or keep unchanged the requirement for doing both. This option says each privilege should have unique requirements instead. It's yet another possible answer to the same question. Equazcion •✗/C • 18:30, 12 May 2008 (UTC)
- I do think a too high page move limitation will have a unwanted sideeffect when well meaning new editors will get into the habit of doing page moves with cut and paste. Agathoclea (talk) 20:07, 12 May 2008 (UTC)
- That's easier to deal with. That can simply be deleted. Reverting a page move, especially when performed multiple times (i.e, A > B > C) isn't anywhere near as simple. Celarnor Talk to me 20:17, 12 May 2008 (UTC)
This is a great proposal. In this new access level, we could add all those new permissions that have been popping up recently (ie. rollback, accountcreator, ip-block exempt et certa) and confine it into one usergroup. Also high risk pages can be accessed by good-faith contributers like Special:Unwatchedpages. Additionally, we could also limit all those high risk scripts (twinkle) to this access level. -- penubag (talk) 01:43, 13 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)
- (ec)There's no reason to keep the two inseparably linked like this if circumstances only call for changing one of them. Please note that the standard MediaWiki software puts registered editors into one of two categories: not autoconfirmed, and autoconfirmed. Door #8 requires the software be changed, to something like "autoconfirm 1" and "autoconfirm 2", with different criteria and with each conferring different user rights. The poll being considered is the best that can be done given the existing software. Unless the developers commit to rolling out a software feature for two (or more) types/levels of autoconfirm, it's pointless to have this discussion. And even if there were consensus for multiple autoconfirms (sure, why not, it makes things flexible), if it's going to take six months to get there, then that's six months during which the above proposal doesn't get implemented, even though the vast majority agree that something needs to be done, NOW.. (If you don't think it will take six months, consider that not only do developers have to code and test the change, but decisions need to be made - by consensus? - as to (a) whether these are two sequential or two alternative autoconfirm levels; (b) what the criteria for reaching each will be [note the difficulty of agreeing when there is just one autoconfirm], and (c) what rights each autoconfirm type will grant, once reached.) So let's improve the current situation, NOW, and then turn to discussing how to improve on that, rather than being diverted into a debate about "great proposals" that actually can't be implemented any time soon. -- John Broughton (♫♫) 02:19, 13 May 2008 (UTC)
- The addition of an edit count requirement is also a change to the software. The addition of another confirmation level is yet another change to the software, granted, but they are both changes, and I think regardless of the added effort it may take, this is the smarter option.
- With regard to the recent moving of this discussion off this page, I ask kindly that you please leave this section here. Whether or not it's a viable alternative to the other options on this page is not for any one (or two) people to decide. If you disagree with it, simply say so. Equazcion •✗/C • 02:27, 13 May 2008 (UTC)
- The addition of an edit count requirement is also a change to the software. No, it is not. Changing the autoconfirmed threshold to require a combination of time and edits requires only an admin to act. This has already by implemented on other language Wikipedias; no new programming is required. By contrast, no Wikipedia has two different types of autoconfirm. That would require developer assistance, not to mention building community consensus (as discussed above). -- John Broughton (♫♫)
- Building community consensus, I believe that's what this page is for. As for the effort the change would take, see Mr. Z-Man's comment below, it apparently would be a fairly simple thing to implement. Equazcion •✗/C • 23:11, 16 May 2008 (UTC)
- To clarify: I think this option is important to consider because given that the alternative seems athis point to be changing the autoconfirm requirement to 7 days and 20 edits, my top concern is that this is a hasty response to the page move vandalism that's been occurring recently. People may feel the need to do what's necessary to put a stop to that, despite the incidental change to the semi-protection requirement, which they may see as unfortunate but nevertheless necessary to accomplish the page move restriction. I feel they shouldn't need to make that compromise -- there's no reason that both privileges should have the same requirement, and I think at this point it's detrimental that they don't. 7 days and 20 edits is a very significant change to semi-protected edits that I'm not sure everyone's fully thought through since this discussion has centered so much around page moves. Equazcion •✗/C • 02:49, 13 May 2008 (UTC)
- I think sleeper accounts used to edit semiprotected pages is nearly as much of a problem as pagemove vandalism. As for software issues, this would be fairly easy to do though - create a new autopromoted group, remove some rights from autoconfirm, add them to the new group. I would not necessarily be opposed to this, but I think with the issue of sleepers bypassing semiprotection (see the history of Evolution for a particularly bad example), WP:BITE problems associated with new users getting images deleted due to copyright reasons, and the potential (though I haven't seen it yet) of patrol abuse, that it would be better to just raise the requirements of all of them. I would be opposed to lumping all the new user groups together though. Mr.Z-man 03:01, 13 May 2008 (UTC)
- I agree that sleeper accounts might be a problem, and perhaps they occur at least as often as page move vandalism -- but they're definitely not equal in terms of how easily they are reverted. Move vandalism has so much more disruption potential because it takes multiple steps and admin tools to perform. Whereas semi-protected edits are reverted by anyone in one or two clicks. Equazcion •✗/C • 03:04, 13 May 2008 (UTC)
- Yes its easy to revert, but the point of semiprotection is to reduce the amount of reversion necessary to maintain articles. IMO it currently doesn't do that near as effectively as it could. Mr.Z-man 03:24, 13 May 2008 (UTC)
- I agree, however the need to prevent vandalism needs to be balanced with the need to keep the encyclopedia freely-editable. I'm not against increasing the requirement for semi-protected edits -- I just think a larger increase is warranted for moves, and there's no reason we must be locked in to changing both by the same amount. Equazcion •✗/C • 03:36, 13 May 2008 (UTC)
- You seem to be supporting a split on principle, but we have not heard anything specific yet as far as the proposed limits are concerned. I suppose you have a high edit threshold for page-moving in mind, or else the difference between the thresholds for semi-protected-page-editing and page-moving would be ridiculously small, too much for any meaningful distinction between the two groups. The fact remains that a) a high threshold for moving could generate other problems, some mentioned and others not yet discussed; and b) a low threshold for editing semi-protected pages would retain and prolong the existing problems. A good balance needs to be reached, and I believe that the community has been quite successful at that so far, judging by the poll above. We can kill several birds with one stone here, and none of them needs to belong to the protected species (a.k.a. newbies). Further changes to the software can be discussed later, in time, and with information available from the application of the selected solution here. As I've said again somewhere in this increasingly long page, let's take things one step at a time, please. Waltham, The Duke of 04:14, 13 May 2008 (UTC)
- For some reason I thought this was obvious, but personally I feel that if another confirmation level is created, I'm fine with the page move threshold being 7 days and 20 edits, or whatever people end up agreeing on here. I'm not trying to get the move requirement increased past that. My concern is that semi-protected edits really aren't what most people who voted here are concerned with tightening, at least not as much as page moves. I feel we should have the option to set unique limits for both, and I think forcing everyone to choose an across-the-board standard for two privileges that really have very different levels of risk involved is a very dangerous thing to do. Thinking of this as "a nice thought for the future" while we take the initiative to prevent move vandalism now by also vastly limiting semi-protected edits is, I think, a big mistake. Equazcion •✗/C • 04:22, 13 May 2008 (UTC)
- Philosophically, you might be right, considering the difference of revert times and levels of complexity. However, on a practical level, I have separately argued the need to raise the bar for edits on semi-protected pages as well. What is the benefit of letting brand-new editors edit pages which have been protected in order to fend off vandalism, test edits, and tendentious editing? People who come here and do not have the patience and understanding to look around and learn the basics of editing and policy, and would instead insist on editing straight away a very small number of very specific semi-protected pages, are most likely vandals or POV-pushers, and it would be a bloody good thing if they could not edit these pages, at least in the beginning and until the "cool off", as they say. Auto-confirmation should be a vestibule for all editors, and it should not be applied fragmentarily. People should know that we have behaviour standards in the community and editing standards in the encyclopaedia to uphold; it is not the undeniable right of everyone to come here and wreak havoc. Applying auto-confirmation universally is saying to people that if they want to enter they have to do it our way. It sends off a message that we want people to get. Semi-protecting pages, on the other hand, and letting people to register, wait four days, and then vandalise them at will or do whatever else they want to do in there, is like giving the world a reason not to take us seriously. And it's not changing the fact that we're flooded with sockpuppets and that thousands of man-hours are lost daily in vandal-fighting (and I mean the revert-with-a-click-of-a-button type). Waltham, The Duke of 07:03, 13 May 2008 (UTC)
- I understand that you want to prevent vandalism on our most sacred of pages, and I again agree that the requirement for semi-protected edits may need to be raised, but again that needs to be balanced with free editability. A lot of very popular articles are semi-protected pretty much on a permanent basis (Family Guy is one that comes to mind specifically) and people might join just so they can edit an article like that. Telling them they have to achieve our trust first before they can do that is leaning away from being welcoming and towards the elitism that we strive to avoid here. And autoconfirm was never meant to infer trust, by the way, just slow people down. They need to be slowed down more now, it seems, but let's be careful not to take the opportunity to create a class system. This is the encyclopedia anyone can edit, "you can edit this page right now", and so forth, and yeah sometimes that's a pain, but that's the way it is. People call us foolish, to be so trusting of people we never met, but that is nevertheless a fundamental principle of this place. Everyone is trusted until proven otherwise. We all knew that a long time ago. So in conclusion: semi-protected edits are a sticky situation because increasing its requirement means toying with free-editability, while page-moves are not quite as much of a concern there and also are more potentially disruptive. It therefore seems clear to me that one should be much harder to do than the other. Equazcion •✗/C • 08:16, 13 May 2008 (UTC)
- It looks like, based on the WP:Flagged Revisions, that there may be two new user rights: Surveyor and Reviewer. These are not administrative, rather article quality assessment functions. My point is that these rights would not be automatic, as is currently set for autoconfirmed, but more like rollbacker, granted after some vetting, but not a RfA type process (or a maybe a very minimal version of it). But Surveyor could (or some other unambiguous term), in effect, be a new level of trusted editor/established editor that the community knows is not a vandal, and is very familiar with editing requirements, policy, guidelines, tools, etc. In other words, one that the community knows can be trusted to assume some more responsibility, but at a lower level than admin. And that level could include page move, since it's a function that new editors don't need, and shouldn't be doing, until they are VERY familiar with WP processes. Yeah, I know, it's more bureaucracy, but we need more now that WP is gotten so immense. There needs to be a level, or several levels, between autoconfirmed and admin from a trust point of view. Autoconfirmed is not a trust level, it just means the user registered and waited four days. ie - a possible sleeper account. And the bar to admin rights is way to high for this kind of stuff. This will also split out the issue of increasing the autoconfirmed bar from that of page moving, since they really are different issues. IMO. — Becksguy (talk) 03:26, 13 May 2008 (UTC)
support for two separate confirmation levels
There are a lot of different things being discussed above, so to get this "poll" back on track, here's a designated section to voice your support of having two separate confirmation levels: one for page moves and one for semi-protected edits.
- I support my own idea based on my rationale above :) Equazcion •✗/C • 04:06, 13 May 2008 (UTC)
- How original... :-D Waltham, The Duke of 04:14, 13 May 2008 (UTC)
- Strong support-- penubag (talk) 04:08, 13 May 2008 (UTC)
- Support based on my previous reasoning. Celarnor Talk to me 04:09, 13 May 2008 (UTC)
- Support, I oppose increasing the level for editing semi portect articles but support raising it for page moves. Davewild (talk) 06:51, 13 May 2008 (UTC)
- Support but is this technically feasible? GameKeeper (talk) 07:50, 13 May 2008 (UTC)
- According to Mr. Z-Man in one of his comments above, it does seem to be feasible. Equazcion •✗/C • 07:58, 13 May 2008 (UTC)
- Support two levels and raising both, but with move much higher. — Becksguy (talk) 08:18, 13 May 2008 (UTC)
Oppose strongly - creating un-necessary complexity; I reckon that editing semi-pd pages and moving pages are both high-level functions that deserve equal, and high-level, guarding. —TreasuryTag—t—c 18:41, 13 May 2008 (UTC)
- I mostly agree, but I don't think people are supposed to oppose here... Waltham, The Duke of 20:56, 14 May 2008 (UTC)
- Oppose - new users often create articles with incorrect titles, they should be able to clean after themselves. What I would support is Move Protection of all established articles (defining established as , say more than 1 year old with more than 100 edits). Moving of such articles require WP:RM anyway out of respect to the authors. The protection from the pagemove vandalism is an additional benefit Alex Bakharev (talk) 10:40, 15 May 2008 (UTC)
- Support. Zginder 2008-05-15T19:40Z (UTC)
- oppose for now Alex makes a good suggestion above. Furthermore, since we seem to be almost certainly switching to 7/20 at this point it would be good to see how that goes before we do this. JoshuaZ (talk) 19:42, 15 May 2008 (UTC)
- Oppose for now - There isn't even agreement on whether the second group (for page moves) would be a variant of autoconfirm ("autopromote") or would be given only to more trusted editors ("Surveyors", for example), as part of a set of rights. It's far, far better to modify autoconfirm requirements (as seems to be the consensus, above), and then in a month or two, make a specific proposal about editing semi-protected pages or whatever other rights are to be split off, with a set of alternatives ("keep as is", an autoconfirm variant, bundled in with another type of right; for autoconfirmed variants, there are in turn multiple options). But this discussion, now, just adds much too much complexity to the proposal/poll above; it's not going to irretrievably harm the project if some new editors are temporarily discouraged because barriers are temporarily - for a couple of months - set too high. -- John Broughton (♫♫) 19:56, 17 May 2008 (UTC)
- Support per the reasoning above, assuming it is technically possible. There's no necessary reason why the two should be linked, and it seems to me that the ability to move pages is a considerably greater privilige than the ability to edit semi-protected ones - the latter should be much easier to obtain. Terraxos (talk) 01:44, 18 May 2008 (UTC)
- Oppose for no reason other than the added complexity, a lot of access levels already so let's not add more. GDonato (talk) 09:55, 18 May 2008 (UTC)
- Strong oppose: As said above, I don't see the need to make it complex. - Rjd0060 (talk) 18:16, 20 May 2008 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.