Wikipedia:Village pump (proposals)/Proposal to require autoconfirmed status in order to create articles/Discussion on running a trial

Discussion on running a trial

In the interested of gathering evidence, I propose that we run a 6 month trial, ending in October, thus covering the September influx, and all of the summer months. In this trial, only autoconfirmed users would be able to create articles. This way we can get some emperical evidence to see if it makes things better or worse. --NickPenguin_(contribs) 15:26, 9 April 2011 (UTC)

• 6 months feels like a very long time to run a trial of a proposal which some people are quite strongly against, although I do think empirical evidence would be useful and appropriate. Are you paticularly committed to the time frame? Bob House 884 (talk) 16:46, 9 April 2011 (UTC)

Edit: a proposal above by Shooterwalker above for a 14 day trial, or one limited to a paticular subject area recieved quite strong support Bob House 884 (talk) 16:51, 9 April 2011 (UTC)

As to my proposal above, I meant to point out that we can discuss the parameters of a trial later. There's an overwhelming consensus to go ahead, with some saying "just do it", and others saying we proceed with various levels of caution. Because of the nature of the user activity, it will take us months to understand the impact on retention. But it doesn't mean we have to run the trial for as long as it takes for us to understand the data. Shooterwalker (talk) 19:20, 9 April 2011 (UTC)

• I think it can take a number of iterations to get the system working right, in technical ways (change user interface messages and tweak them as experience is gained) and shifts to the culture (the thing that new users need most is help and advice from experienced users). 6 months sounds better than 14 days. By the way, how many people in this discussion have actual experience submitting articles through AFC, or even looking at the stuff that gets submitted there and how it gets handled? I think it might change your perspective. 75.57.242.120 (talk) 01:31, 10 April 2011 (UTC)

I think a short trial would only show that article creation goes down for new users, it wouldn't give us enough valuable information about user retention. There is no technically possible way to 'limit article creation to a particular subject area' since people can create an article called anything and have it be about anything. They could very well mislabel the article titles for all we know. Some may think 6 months is too long a period of time, and perhaps so, but the trial should be in the order of months to at least get some idea of how it functions with retention. I certainly don't think we will scare away users by running this trial, or at least, not users that wouldn't have stayed anyways. --NickPenguin_(contribs) 02:17, 10 April 2011 (UTC)

I concur with NickPenguin and favour a trial, which should be of months rather than days. Creators of serious articles will not be deterred and will probably even appreciate the reasons why. Kudpung กุดผึ้ง (talk) 03:11, 10 April 2011 (UTC)

Agreed. Trial needs to be fairly long (3-6 months) to have a good chance of showing the longer-term benefits after allowing the change to bed down. Rd232 ^talk 03:36, 10 April 2011 (UTC)

The trial period where the autoconfirm barrier is in place need not be very long in order to collect editor retention data. It could, for example, be a month long, at which point the current system is restored. Then, at the 3 or 6 month mark, the effect on new editor retention could be examined by looking only at the cohort of editors who registered during the month of the tral. (I'm not saying that this is the best way to conduct a trial, just that it's an option.) Danger (talk) 04:48, 10 April 2011 (UTC)

Good idea. Real-world action will be the true test of this proposal's merits. Six months, I'm sure, will smack a bit too much of the pending changes "trial" for many, so a fixed term of a month followed by data analysis three or/and six months months after the end of the trial sounds like an excellent compromise to me. Brammers (talk/c) 07:58, 10 April 2011 (UTC)

"need not be very long in order to collect editor retention data." - indeed, if we assume that the sole thing we're testing is the proposed autoconfirm restriction in isolation. But it isn't - we also need to test how, once that change is in place, the community can adapt to the resulting change, eg switching efforts from NPP to AFC and making sure the assistance options are as clear as possible (in signposting, and in use). So I'd say 3 months minimum, better 6 months, to really understand how it works in practice. Rd232 ^talk 17:42, 10 April 2011 (UTC)

Oh, I don't disagree. I certainly think a trial longer than a month, at least three, would be ideal; just that there's no reason to give up all hope of good data if a longer trial is not the final consensus. And while the issues that you bring up are a big deal, they don't seem to come up as counterpoints to the proposal as much as the effect on new editorship, which I think is reasonable. I have more than enough confidence that the dedicated editors in the community will be able to adapt like we have done in the past to other changes. New editors are the real unknown though. --Danger (talk) 00:42, 11 April 2011 (UTC)

Like hell you can run a trial. Ask the FR/PC people for why you'll find some serious opposition. Protonk (talk) 01:51, 11 April 2011 (UTC)

Well, in the case that the consensus is to make this change the options are run a trial with a stated end date or flip the switch with no intention of unflipping it. I don't much care either way; either way data can be collected and the change can be evaluated. --Danger (talk) 02:28, 11 April 2011 (UTC)

In practice there isn't really a difference between the two. Once a trial gets started the existence of a trial will be used as reason to continue the trial or turn on the behavior. As such a trial isn't a middle ground, it is a foot in the door. Protonk (talk) 03:15, 11 April 2011 (UTC)

The substantive difference is in what's planned (a) whilst the trial is evaluated (continue with it? revert to status quo ante?) and (b) what to do if the trial is inconclusive or results are mixed and judgements vary about the different elements of success/failure. I'd suggest something like this: trial it for 3 months, then begin evaluating, leaving the trial continuing whilst evaluation is ongoing. If no consensus is reached by 6 months that experience shows it's a good idea, revert to the status quo ante. That, and plan what questions to ask, and hence what data to collect. Rd232 ^talk 03:30, 11 April 2011 (UTC)

And again, I'd oppose this outright. I have no doubt that calls for a trial are made in good faith but the last large scale trial we tried ended up not being anything like what you described but a means to introduce a contentious change under the cloak of rationality and conservatism. Protonk (talk) 03:37, 11 April 2011 (UTC)

Just because the last trial went badly it doesn't mean that this trial has to end badly, or become an abuse of process if it does end badly. We should take precautions this time. Make sure the trial has a definite start and end date. And wind it down during the analysis phase. Do NOT restart the trial (let alone make it permanent) until the analysis is done and another RFC has taken place. Shooterwalker (talk) 03:46, 11 April 2011 (UTC)

I don't think it is determinative, but the principal precaution is to close the barn door before the horse gets out. I'm sorry if that is frustration to those advocating for this specific redefinition of "anyone can edit" (contra the aforementioned redefinition) but there is no real way to engineer this trail so as to ensure it won't always result in a prolonged gray area or acceptance as a given. Protonk (talk) 03:59, 11 April 2011 (UTC)

First of all, anyone can edit. Anyone could edit when anonymous users could create articles. Anyone could still edit when we asked people to create an account to be able to create an article. Anyone will still be able to edit if we decide that someone should have 10 ordinary edits under their belt before they create another article. Second of all, I know you're frustrated because pending changes turned into a mess, and the process for winding it down has been a nightmare. But if we're never able to run a trial again, we'll never be able to improve Wikipedia. Besides the fact that this is worth trying... you might want to note the 80% of people supporting it. That same 80% might say to you "we don't need no stinking trial". But fortunately there are enough civil, good faith editors who believe Wikipedia should be based on verifiable facts, and that includes our decisions about the editing process. I'm confident that asking editors to make normal edits before creating a new article will benefit them as much as it benefits the entire encyclopedia. But I'd like to be able to WP:PROVEIT. So instead of stonewalling a trial... let's talk about how to make sure the trial is indeed just a trial. Shooterwalker (talk) 04:12, 11 April 2011 (UTC)

I think we can agree to disagree about the "anyone can edit" bit. but I'm not interested in forsaking any trial. Just any trial that is used as a stand in for serious widespread support for a contentious change. If a preponderance of people discussing something feel it is a good idea and feel that it would be helped in terms of implementation by a trial and some data, great. Where I get off is when a trial is proposed as a sort of half-way point between those who wanted the proposal enacted yesterday and those who never wanted it enacted. Protonk (talk) 04:16, 11 April 2011 (UTC)

I'm very firmly in the "this proposal is so obviously a good idea that I'm astonished it hasn't always been so" camp, but I see no harm in a trial to prove to those less convinced than myself that they are in fact wrong. Malleus Fatuorum 04:21, 11 April 2011 (UTC)

I just want to add that I'm making a very strong promise to make sure the trial is as temporary as possible to allow us to gather the data we need. I'm going to be right there advocating for a definite end-date. Shooterwalker (talk) 04:30, 11 April 2011 (UTC)

To avoid the problems with the PC trial, a hard end date should be set. Then we can evaluate calmly. Cenarium (talk) 14:42, 11 April 2011 (UTC)

If we decide to run a trial, there will be no problem with 'forgetting' to turn it off: Unlike the PC trial, these changes must be made by the devs. Mere editors and admins aren't capable of changing this. WhatamIdoing (talk) 22:13, 11 April 2011 (UTC)

The "t-word"

"Trial" can be a controversial word around here. Why not (assuming consensus, of course) just enact the proposed change in policy, study the data for however long it takes to form valid conclusions, and then, if those conclusions warrant it, start another RfC to return things to the way they were? All the advantages of a trial without having an actual trial. This may sound like mere quibbling over semantics, but I think it might be important. For one thing, trials generally have predefined end dates, but there's no reason that a policy change like this should be planned to end. (It certainly should end if there's clear consensus for that, but let's not cross that bridge before we come to it.) To put it another way, calling it a trial would essentially make the change temporary by default, and I'm not clear on why that would be preferable. Either way, we should end up in the same place six months or a year from now, but consider: if requiring autoconfirmation turns out well, without a trial we'll only have had to make one change in policy; with a trial, we'll have to change the rules three times. That ought to confuse a newbie or two. Rivertorch (talk) 06:51, 10 April 2011 (UTC)

Well, of course, anyone who has been following my comments here (and the work we have been doing in an attempt to improve NPP) will not be surprised that I wholly agree with this idea. --Kudpung กุดผึ้ง (talk) 1:26 pm, Today (UTC+2)

Well maybe that's the best way to go about it. I find with many proposals the initial resistance is to the idea of change itself. Perhaps if we simply change it, everyone can take a step back and get used to the new dynamic, and everyone can see for themselves if their respective workload goes down in their areas. Then, at a later and unspecified time, any interested party can call an RFC on this, we can evaluate what happened, and what we can do to make it better. That might be good to, because then users won't necessarily be waiting for that clock to tick over and launch the RFC right away. If the enacted proposal causes serious problem, then we can RFC and stop it right away. --NickPenguin_(contribs) 14:27, 10 April 2011 (UTC)

Naturally I think this idea will work out, so I don't see any downside to just going ahead, especially with the strong consensus there is to at least try it. But there's a reason we have trials with a definite end date: because it's VERY hard to stop something once it's been started. Offering to do a trial is a good faith concession that supporters can make to earn the trust of the small but significant opposition. Shooterwalker (talk) 20:17, 10 April 2011 (UTC)

I think that a clear end date, and a clear end mechanism, would be essential for a trial to avoid the drama of Pending Changes. I would fully support a trial; then we can sit back, look at the statistics, and make a long-term decision based on much clearer evidence. bobrayner (talk) 21:27, 10 April 2011 (UTC)

Yes, a clear end date would be prudent, for example, "exactly 3 months after the trial begins". We probably can't set a specific date since the beginning of the trial depends on a technical change (as well as some preparation by the community). I also agree that a trial is preferable to just flipping the switch, since once we start down this road it is going to be hard to go back even if the data suggests we should. Kaldari (talk) 21:47, 10 April 2011 (UTC)

It seems difficult to determine consensus on the whole issue just of the RFC, is it planned next to make some kind of proposal for a trial with poll/discussion ? Cenarium (talk) 22:01, 10 April 2011 (UTC)

Revised proposal to run a trial

The general feeling I get is that a 3 month trial is much more likely to be accepted. In that case, then the trial will run 90 days from when the technical aspects of the proposal go live. Then, the switch flips, and it goes back to how it is now, an RFC starts immediately, we present our data immediate data and discuss. Does that sound fair to all sides? --NickPenguin_(contribs) 05:14, 11 April 2011 (UTC)

Might need a couple weeks with the data. In fact, we might want an entire month with the data, just to see what happens to the new users on day 90, a month after. But I think this is a good proposal. I can't think of a less intrusive way to get the data. Shooterwalker (talk) 05:16, 11 April 2011 (UTC)

I certainly think this is much better then just flipping the switch. For a change of this magnitude I think we owe it to ourselves if that's the decision. I also think any "well it's not a trial but we'll do another RfC while it keeps running" idea just leads us to making it "more" likely to never be fully re evaluated. If we don't have a defined trial we run a much stronger risk of never really looking at the data.

I still think it is an incredibly bad idea as a whole (in general I think it's a well intentioned but kneejerk decision based on either no data or misunderstood data; a short term solution that cuts off our head and doesn't solve either the short or longer term problems ;) ) but if the decision ends up being to go ahead then I think this is the way to go and I would anticipate trying my hardest to still make it work since I do not want to see a large cohort of new users go to waste for 3 months at a time when we really need them. Even though 'most' editors edit pages first, which makes sense giving all the articles we have, the number who create articles is more then significant enough to have a huge impact. James of UR (talk) 06:45, 11 April 2011 (UTC)

(edit conflict)A 3 month trial would definitely be a good idea, but with the autoconfirmed threshold sitting fairly low I don't think it'll do much, 10 edits and 4 days is not a long wait. If the threshold is increased to 15 edits and 2 weeks, I'd definitely support a trial. —James ^{(Talk • Contribs)} • 4:52pm • 06:52, 11 April 2011 (UTC)

I think that 90 days is much longer than necessary (I'd do no more than 60), and "immediately" far too soon to start discussing it. If you want to know about editor retention 90 days after, then you have to wait 90 days after the trial ends, i.e., up to 180 days after the start of a 90-day intervention, so that you can find out what happened to the editors who registered on the last day of the trial. Editor retention 180 days after the trial (=270 days after the start) might be even more interesting. And then you need weeks, if not months, to finish collecting the data.

The only thing you could legitimately do "immediately" is to start arguing about what constitutes a proper control group and how you would control for seasonal variations. WhatamIdoing (talk) 22:18, 11 April 2011 (UTC)

On what else to do in conjunction with this

Its always been my impression that this proposal always has had multiple facets:

• Reducing the influx of inappropriate articles
• Reducing the burden of experienced users dealing with that influx of articles so they can be more productive in other areas
• Improving the experience for new users so they can learn how to work within Wikipedia before diving into article creation right away

For me, the bold bit has been central; and insofar as I want this to work, we need to think carefully about how to make it work, by making sure that we have mechanisms in place to work with editors who wish to work through the 10 edits and 4 days; we want those 10 edits and 4 days to be as useful in teaching them Wikipedia, and so we need to do something a bit more than "flipping the switch" and watching what happens. We also need to have the means to deal with the change already in place when the switch is flipped. When this RFC started, I did a little free-form riffing on ideas that I had. I am not particularly attached to any of them; just sort of a brainstorm. They can be found at User:Jayron32/an immodest proposal. Again, just some ideas, none of which I have any strong attachment to, except the general idea that we need to make sure we do this right, and have the means necessary to make this a positive experience. We need to give this all the chance we can, and running blindly into this may not be the best idea. --Jayron32 05:58, 11 April 2011 (UTC)

I agree with Jayron32 here. The real point is provide a better experience to new users. We should prepare all this before pulling the switch on either a trial or for real. Perhaps start a wikiproject/workgroup to coordinate and prepare this? Yoenit (talk) 07:34, 11 April 2011 (UTC)

There is a wikiproject already that works along in these lines, Wikipedia:WikiProject Usability. It looks like it could use a little bit of prodding tho. --NickPenguin_(contribs) 15:07, 11 April 2011 (UTC)

Ya... I agree this is primarily about user experience. If you think of Wikipedia as a WP:MMO game, we can learn from the experts about how to make it more fun:

• “If you must guide players to the fun areas, it is probably because they are overwhelmed with the game’s complexity and do not know what they are supposed to do. ... Consider restricting the choices available at the beginning of the game. Players likely cannot make meaningful choices early in the learning process anyway, because they do not yet understand how the game elements interact. Give players more freedom and more choices over time: the new player needs simplicity during the first few hours of gameplay... These restrictions not only simplify the learning curve, but additional complexity can be presented as an additional reward for competent play.”

Read that quote carefully. It applies to anything with a learning curve, not just games. There isn't an organization in the world that would throw a volunteer or employee into the deep end without a warm up. (Except for jobs where there is no deep end.) Shooterwalker (talk) 12:55, 11 April 2011 (UTC)

An article wizard extension would be appreciable in either cases, I've started at thread on this at Wikipedia talk:Village pump (proposals)/Proposal to require autoconfirmed status in order to create articles#Article wizard extension. It may be appropriate to build consensus on this separately. Cenarium (talk) 15:30, 11 April 2011 (UTC)

Proposal: just do it

Just go ahead and do it on some agreed date (eg 1 May or 1 June), without farting around arguing endlessly about a trial. By all means prepare as much as possible, and figure out what data to collect for evaluating the effects. (No formal trial does not mean the change should not be evaluated and open to reversal if consensus agrees reversal.)

Users endorsing this view

1. Rd232 ^talk 13:18, 11 April 2011 (UTC)
2. Per my comments here. Rivertorch (talk) 15:52, 11 April 2011 (UTC)
3. Kansan (talk) 16:55, 11 April 2011 (UTC)
4. Basket of Puppies 02:30, 12 April 2011 (UTC)
5. per my comments above N419BH 02:52, 12 April 2011 (UTC)
6. MER-C 02:54, 12 April 2011 (UTC)
7. --Korruski^Talk 08:21, 12 April 2011 (UTC)
8. Dcoetzee 09:38, 12 April 2011 (UTC)
9. Hrafn^Talk_Stalk^(P) 16:05, 12 April 2011 (UTC)
10. --Kvng (talk) 22:34, 12 April 2011 (UTC)
11. ✓ indeed. If it goes horribly wrong, we turn it back; no worries. The specifics - the process - will quickly develop, once we jump in to the idea. Change We Need. There is, I think, "general agreement" that something needs to happen; and we need to remember WP:BOLD.  Chzz  ►  22:47, 14 April 2011 (UTC)
12. For some reason I Was unaware that non-AC users could create articles. I can't believe this wasn't already in place. Generally speaking the chances of a brand new user creating a useful article before being autoconfirmed are pretty slim. Yes, there is the odd one that I'm sure someone can point to, but overall, I think it's a net positive.--Crossmr (talk) 23:52, 14 April 2011 (UTC)
13. Please God no not another trial. We can say we're doing this on a trial basis and if it causes more problems than it solves we can undo it, but having a predetermined trial period for a feature is not a model that has worked out particularly well for us in the past. We end up arguing about the trial period instead of the real issue. Beeblebrox (talk) 22:37, 15 April 2011 (UTC)
14. Per Beeblebrox. » Swpb^{τ • ¢} 23:53, 17 April 2011 (UTC)
15. —mc10 (t/c) 02:13, 18 April 2011 (UTC)
16. -- 李博杰  | —Talk contribs email 16:34, 19 April 2011 (UTC)
17. Yes, and of course we should be monitoring it so that if it does completely fail, we can amend accordingly. The Blade of the Northern Lights (話して下さい) 17:34, 19 April 2011 (UTC)
18. Support Let's keep it simple. Turn it on. If this doesn't work (and I really believe that this will improve Wikipedia), it can be turned off. -- Donald Albury 19:37, 19 April 2011 (UTC)

Proposal: 3 month trial, then review whilst active, up to 3 months max

Trial it for 3 months, then begin evaluating, leaving the trial continuing whilst evaluation is ongoing. If no consensus about the outcome of the evaluation is reached by 6 months after trial begin, revert to the status quo ante. (After such a reversion, discussion may of course continue on what to do.) This sets a deadline for agreeing it was a good idea, without requiring a strongly supported idea to be undone while experience is reviewed.

Users endorsing this view

1. Rd232 ^talk 13:18, 11 April 2011 (UTC)
2. Nightenbelle (talk) 15:06, 11 April 2011 (UTC)
3. If there is consensus to go ahead despite opposition from myself and others, then yes there needs to be a trial. Apart from the many articles deleted in error, 2,606 articles from February 2011 that have not been deleted were created by newbies in their first five edits. I would regard the trial as a failure if significantly fewer new articles were getting onto the pedia from Newbies, and a success if that figure rose. ϢereSpielChequers 16:57, 11 April 2011 (UTC)
4. Shooterwalker (talk) 23:16, 11 April 2011 (UTC)
5. Yes, it does sound a little bit like the PC trial, but I think that it would be easier to do this way.  A p3rson ‽ 23:20, 11 April 2011 (UTC)
6.  Ronhjones  ^(Talk) 00:25, 12 April 2011 (UTC)
7. Much cleaner to do it this way. T. Canens (talk) 02:13, 12 April 2011 (UTC)
8. not ideal per my comments above but will work N419BH 02:52, 12 April 2011 (UTC)
9. MER-C 02:54, 12 April 2011 (UTC)
10. Korruski^Talk 08:22, 12 April 2011 (UTC)
11. Support over trial and revert - Not ideal - let's fix the background issues first. But if we must, the fewer changes the better.
12. Hrafn^Talk_Stalk^(P) 16:05, 12 April 2011 (UTC)
13. I would agree to a trial, as long as lessons are learnt from the PC one e.g. a clear date is set for the trial to end if no agreement is reached on continuation. CT Cooper · talk 10:25, 13 April 2011 (UTC)
14. --KidGwakebake 23:58, 13 April 2011 (UTC)
15. Agree, TRANSPORTERMAN (TALK) 14:19, 15 April 2011 (UTC)
16. Baseball Watcher 03:54, 16 April 2011 (UTC)

Proposal: 90 day trial, revert to current system, discuss for up to 3 additional months

Trial it for 90 days, flip the switch back, then begin evaluating. Running it and stopping it will more clearly show if it makes an impact at places like NPP and CSD, because if this works the workload will go down, and then spike back up. It will allow for more transparent observation of what goes on in both scenarios. The three months after the trial ends will allow enough time to evaluate the data and make a decision.

Users endorsing this view

1. NickPenguin_(contribs) 14:52, 11 April 2011 (UTC)
2. If we're going to do this then this is the way to do it. Discussing it again while it keeps running assumes a forgone conclusion and makes the discussion harder. I think we would want at least a month for everyone to gather data together (especially on editor retention) and then the real discussion can start. Speaking from a very non-informed point of view I believe it will not be hard to turn it back on once it is set up the first time (Currently we can not stop 'just article creation' it's page creation or talk page and that's it. Once we fix that it's a solved problem). James of UR (talk) 21:36, 11 April 2011 (UTC)
3. we want to know If it works first --Guerillero | My Talk | Review Me 22:11, 11 April 2011 (UTC)
4. Shooterwalker (talk) 23:16, 11 April 2011 (UTC)
5. I support a 90 day trial, but ... Review of the data is going to take longer than 3 months. We are (or should be) interested in long-term retention rates, we may not even be able to begin reviewing the data for 3 months after the trial ends. The number of new users who create an account and make an edit is mostly irrelevant, what's important is the number who actually stay. Mr.Z-man 03:33, 12 April 2011 (UTC)
6. I think this is a reasonable way to ease into the new policy. Ruby2010 comment! 19:45, 12 April 2011 (UTC)
7. Snowman304|talk 23:02, 17 April 2011 (UTC) This sounds like a good idea. This makes the most sense of all of the options listed here.

Proposal: get things up and running first

It seems fairly clear that this proposal is going to pass. It also seems fairly clear that anyone who doesn't think the existing article wizard and articles for creation systems are problematic is at best, a tad dim. Why don't we try fixing up the AfC/AW wizards, waiting to see what Lennart and the user interface people can work up, and then try it? Nobody wants this proposal to fall flat on its arse more than I, but simply launching into it with a crummy interface for the new users seems far too simple a way for it to fail.

Users endorsing this view

1. Ironholds (talk) 16:05, 11 April 2011 (UTC)
2. Good plan, the surrounding work should be completed before it all gets thrown into the wild. --NickPenguin_(contribs) 16:11, 11 April 2011 (UTC)
3. Regardless of how/if this is implemented, AfC/AW need a good hard look. --Danger (talk) 16:58, 11 April 2011 (UTC)
4. I'd rather we didn't stop newbies from creating articles, but if there is consensus to do this then I think we should get the alternatives working before we throw all the newbies at them. Just flicking a switch would take the pressure of newpage patrol but at the price of a mess elsewhere. ϢereSpielChequers 19:25, 11 April 2011 (UTC)
5. --Guerillero | My Talk | Review Me 22:10, 11 April 2011 (UTC)
6. per my comments above N419BH 02:52, 12 April 2011 (UTC)
7. see comments below --Jayron32 05:05, 12 April 2011 (UTC)
8. Cautious support. It's indisputable that the best way to implement this would be to have actually-functioning AfC and ACW ready to go; however, I'm a bit worried that this could turn into yet another round of wheel-spinning argument as RfCs are conducted on how to fix those things, drama is carried out about making the fixes, etc, and that we'll look up a year from now and realize that despite overwhelming support, this proposal still hasn't been implemented. A fluffernutter is a sandwich! (talk) 13:04, 12 April 2011 (UTC)
9. Support. Better to fix these related issues first. Nailing down a lot of potential contributors really doesn't help the encyclopedia, so let's try to fix some of the causes first. twilsonb (talk) 15:03, 12 April 2011 (UTC)
10. Duh. Why test a new product without first making it presentable? /ƒETCHCOMMS/ 21:58, 12 April 2011 (UTC)
11. Sensible proposal if this change is to go ahead, given how significant it is to Wikipedia. CT Cooper · talk 10:22, 13 April 2011 (UTC)
12. —mc10 (t/c) 02:14, 18 April 2011 (UTC)

Further discussion

1. I'd support this if and only if there's some sort of expectation that AfC and the ACW can actually be fixed. AfC is mostly a problem of volunteers, the AW is more of an interface tool that seems more likely to be fixable. What are the specific problems with AfC and ACW that must be fixed prior to starting the trial? Is it actually possible to fix them? One proposal would be to have a working group of 20 editors or so each propose (in a "secret shopper" fashion) at least one article to the AfC using dummy accounts created for that purpose, and then have each of the 20 editors pick and create an article from AfC using the ACW. Use those 20 opinions for some feedback to see what should realistically be changed to make those functions work better. I'd volunteer, I have a couple of articles I've been meaning to write for a while anyway. SDY (talk) 22:18, 11 April 2011 (UTC)

This is a very bad idea. per WP:NEWT --Guerillero | My Talk | Review Me 22:26, 11 April 2011 (UTC)

I see there's a bit of a dispute there about intentional confrontation. This is in no way as confrontational as deletions, and it isn't about users, it's about systems. Since we're adding twenty articles and creating twenty articles, the net workload change for AfC is zero, and any interactions with the ACW are obviously not going to involve any lasting conflicts. If we have to fix AfC/ACW before starting the trial, we're actually going to have to figure out what's wrong and what can be fixed. SDY (talk) 22:38, 11 April 2011 (UTC)

Experienced users deliberately lying to the community in an effort to see if they can trip them up? No, that's not as disruptive as deletion, it's more disruptive. We tried it, it went badly, and managed to actually drive some contributors off the project, upset that they'd been deceived. Ironholds (talk) 23:34, 11 April 2011 (UTC)

(e/c)That was only part of the problem with NEWT, the other problem was that it was so poorly conducted that the data was practically unusable. Its methodology was practically nonexistent. An experienced user can act like a new user all they want, they're still not going to have the same experience with the process. Mr.Z-man 23:42, 11 April 2011 (UTC)

Heck, if the anonymity is such a big deal we can just have people submit under their main acounts. It isn't really all that important to the proposal, it's mostly a question of testing whether the available tools have any flaws that are easily remedied. If we're serious about fixing these tools, we need to know what the problems are. I can't imagine where you see in the proposal that there's any attempt to intentionally "trip up" the community, and the only "lie" is the anonymity which isn't even necessary (just trying to add some blinding to the study, since it removes variables if the 20 know each other). The intent was that the 20 articles for creation would be created by the other people participating in the experiment, so the only people being "deceived" are people who know what they're getting into. SDY (talk) 00:41, 12 April 2011 (UTC)

• This entire RFC, and the proposal to restrict article creation to autoconfirmed users, should be taken as part of a package of upgrades to Wikipedia which includes a) revamping our welcoming procedures, with an emphasis on directing users to ways they can contribute, including making it easier for new users to find existing articles that need their help. b) improving the editing interface to a full WYSIWYG editor with easy-to-use referencing tools. c) better and more useful article creation system with more emphasis placed on reviewing new articles and helping new users get it right, in their userspace, before going live with them. I'm not sure all of these options need to "go live" the same day, or indeed in any particular order, but this entire system needs to be taken in the spirit of improving the new user experience; preventing them from making new articles until autoconfirmed is primarly about just that. This cannot be a "flip a switch and watch what happens" event. We need to consider this as part of a package of usability upgrades and improvements to Wikipedia. --Jayron32 05:05, 12 April 2011 (UTC)

Proposal: Prepare, implement, review

This is clearly a benefit to the community as a whole – including new editors. It in no way counters the mission of being "The encyclopedia that anyone can edit" because anyone still can. They can edit immediately and create in 4 days. They are not considered a Wikipedian before then and those 10 edits, so it is hardly unreasonable that certain limits should be in place during that time.

A trial that ends in reversion of policy while data is reviewed leads to three changes of policy if the trial is successful. And based on points made on this page, anecdotal evidence such as the 40%+ articles by ‘don’t care’ new users requiring speedy deletion (Kudpung) and the known vandalism problem, success seems highly likely.

Preparation

What is worth some careful consideration is the preparation for flicking the switch. Newly signed up users do still require information on the process towards creating an article. Rather than being told ‘You can’t do that’, they need to feel welcomed and informed ‘You will be able to do that once you’re familiar with this and have done that’. The WP:AFC process also needs to be easily discoverable, yet not presented in a way that will cause an influx of requests that can’t be met. These things will take a while to get right and will require further discussion – a group to do this, as suggested by Yoenit, would make a lot of sense. And of course the technical side needs preparing.

Implementation

Given the number of contributors to this page it’s tempting to think a group could be assembled and the preparation completed quite quickly. But a planned commencement date at this stage should probably be a guide only. The group could announce the actual date a week or so beforehand. On the announced date the relevant templates are switched and the code change made.

Review

Review is important – I would suggest months plural after commencement. Now is the time for decision on what qualifies as a successful new policy – it’s not satisfactory for someone to pull over the stats in 3 months and pronounce ‘Ah-ha! This figure shows that!’ Thinking about this now also gives us a chance to collect ‘before’ data. Are we able, for instance, to find out what percentage of 0-4-day-old user articles are quickly deleted versus 5-9-day? Or vandalism by the same ranges?

This policy can easily be reverted. But the review is not just about considering that. It could potentially lead to tweaking of the edit/day count values. (My feeling is that they’re about right.) Or to a further discussion on anti-vandalism measures which could extend the principal of limiting very extensive article changes such as blanking and wholesale substitution of text by unconfirmed users – something that could be identified by computer algorithm at time of attempted edit.

Will all this lead to a better Wikipedia, happier editors and a more positive experience for new signups? I’m very confident that it will.

RedactionalOne (talk) 16:51, 11 April 2011 (UTC)

I'd support this. Do we have any idea on target benchmarks? How many "articles not created" will we tolerate for every "article that should not have been created?" I think that'll be a sticking point, honestly. Losing one real article to prevent fifty fake ones is about the upper limit of exchange I'd tolerate, but I don't do NPP so I don't know what the percentages are. SDY (talk) 23:37, 11 April 2011 (UTC)

I don't think the emphasis in analysing the trial should be on articles, either in terms of quality or in terms of quantity. Of course we should measure those as best we can and take them into account, but the driving concern for me is how to get more editors contributing substantively to more than one article, especially if they start off by creating an article. The issue is getting more longer-term contributors with some substantive experience, who make a longer-term contribution to quality and coverage of the encyclopedia (which is NOT the same as quality and quantity of new articles!). Rd232 ^talk 00:21, 12 April 2011 (UTC)

We need to have some sort of surrogate endpoint. Maybe track the number of <2 week registered editors with >20 contribs and no warnings/blocks? Track the number of IP/newuser edits? Good editors are impossible to pick out with the anonymity, the only real tool we have is to recruit more and let them sort themselves out. There are really two objectives here: 1. Cut down the garbage at NPP, and 2. Don't scare away new contributors in the process. Cutting down the garbage at NPP is easy to quantify, not scaring away new editors is much harder to nail down. We need some sort of endpoint - otherwise we'll just say "well, garbage at NPP is down therefore success." SDY (talk) 00:54, 12 April 2011 (UTC)

Mmm, I think Target A of the proposal we're talking about should be noticeably increasing the absolute and relative numbers of readers becoming at least moderately experienced Wikipedians (let's say >100 edits, edits to >3 distinct-but-possibly-related articles, >5 edits to a talk page, that sort of ball park though obviously you can argue about the numbers). I'm quite prepared to except a decrease in the number of new accounts, number of new articles, number of editors achieving autoconfirmed status but not reaching "moderately experienced" status as defined above, if it makes Target A happen. Rd232 ^talk 01:21, 12 April 2011 (UTC)

Can we generate statistics on those types of editors (let's call them "contributors") using existing tools? I know the various edit counters will give that editor by editor, but is there any aggregate? In this case, we're looking at not reducing, so we'll also have to set a background rate of the number of new contributors we'd expect to see and whether that number takes a hit based on the trial. We'd also have to look at what a background rate is, and that may be difficult because there's probably some seasonality to new contributors (e.g. the start of the academic year probably has an effect). SDY (talk) 01:34, 12 April 2011 (UTC)

Proposal: Close discussions without any trial period

Motion that discussions should be closed as a failed proposal and no trial run should take place. It is clear that many wikipedians have expressed strong arguments in favour of this proposal whilst a significant minority present strong dissenting arguments. There is not a strong enough consensus in favour of the proposal to press ahead to the trial stage, and if a trial were conducted it would be either unhelpful or undesirable. No attempt should be made to run a trial and the proposal should be shelved.

Users endorsing this view

1. (my own views, which overlap with the proposal) I support shelving this idea. We have a numerically stronger camp arguing for imposing this policy for mainly practical reasons (1. reducing NPP workload and 2. having newbies stick to the shallow end to improve their experience) and a numerically weaker, but very significant camp arguing against on principled grounds (it is either wrong or un-wiki-like to stop new editors creating articles or to force them to edit in a paticular way). Testing sounds like a fantastic idea but even if we test for years and find that 100% of articles created by IPs are useless cruft, this won't address the concerns of the dissenters (it may address the issue of new user retention, but this seems to me to be a side-issue) As the discussions have run thier course and no consensus strong enough to justify a major change in wikipedia policy (or to be honest, even to appoint an admin) appears to have formed, this proposal should be shelved. Bob House 884 (talk) 00:42, 12 April 2011 (UTC)

   I'd hardly call 80% support "no consensus". Consensus doesn't require everyone to agree. Plus, the 20% against it aren't all opposed on "principled" grounds. Most Wikipedians don't see our work in ideological terms. Wikipedia is a practical, results-based project, and the debate is whether asking editors to take on 10 edits will scare them away or improve their learning curve. That's the whole point of a trial, to test what happens to user activity. You may also want to read what Jimbo said about this proposal, a trial, and allowing a tiny minority to stonewall. Shooterwalker (talk) 01:01, 12 April 2011 (UTC)

   I'd hardly call 20% a 'tiny minority' either. I'm obviously not speaking in the sense of moral or religious principles but the founding principles, the 'anyone can edit' principle - no matter how much of a slam dunk the results come back as, I don't think they'll address that concern. Bob House 884 (talk) 01:17, 12 April 2011 (UTC)

   The concern doesn't need addressing, because it's nonsense: (a) "anyone can edit" is already contingent, via protection/semi-protection; blocking, non-auto-confirmed move restriction, pending changes etc. The principle is often misinterpreted as "everyone can do anything at any time and have it live on Wikipedia immediately", despite the fact that that's not the original spirit. "anyone can edit" simply means that no particular real-world qualifications are needed by users to contribute, and that's not going to change. (b) the creation restrictions will be restrictions on unassisted creation: non-auto-confirmed users will continue to be able create articles with assistance. Rd232 ^talk 01:31, 12 April 2011 (UTC)

   This proposal is not related to the merits of the arguments, but the belief that no consensus has been reached, please don't bother criticising the substantial arguments on the proposal here. I'm not strongly for or against it, I just don't think that consensus has been reached. Bob House 884 (talk) 01:45, 12 April 2011 (UTC)

   ? Your remarks about "the 'anyone can edit' principle" go beyond the issue of gauging consensus. In any case, on both quality of argument and quantity of supporters, there is a clear consensus. Also your initial remarks seem to fundamentally misunderstand the issue: "[a test] may address the issue of new user retention, but this seems to me to be a side-issue" - it most certainly isn't a side issue. Rd232 ^talk 01:54, 12 April 2011 (UTC)

   siigh.. I mentioned that principle in the context of explaining to another user what I had meant by my eariler user of 'principled' and 'practical' which was intended in a neutral sense. I have gone out of my way to try to make this proposal, and my comments on it non-partisan, if I've failed I am very sorry. Bob House 884 (talk) 11:25, 12 April 2011 (UTC)

   TBH, the fact that we can get 80% support on such a major thing is rather huge. I mean, we settle for much less support for a lot of things, pretty much everything actually. In the last ArbCom election, only 3 of the 12 winning candidates got more than 75% support and only 1 got over 80%. We had less than 70% support for the flagged protection trial. 80% is plenty for appointing admins BTW, 80% is the cutoff for automatic passing, we still appoint admins down to 70% (and in rare cases, less). Mr.Z-man 02:24, 12 April 2011 (UTC)

2. Support I hate this idea. The reason I created an account on Wikipedia? To create an article. If I was unable to create an article after creating an account, I would not have understood this "autoconfirmed" jargon, and I would have probably given up and never returned. Wikipedia is becoming increasingly bias towards veteran users, and not nearly as helpful to newer users nowadays. First we don't let IPs create articles, now we don't let non-autoconfirmed users create articles. Next? Non-admin users won't be able to create articles. Talk about biting the newbies... Eagles 24/7 (C) 02:08, 12 April 2011 (UTC)

   Do you actually think there's no consensus, or do you just not like it? Mr.Z-man 02:24, 12 April 2011 (UTC)

   I know this thing will end up with a trial so my !vote doesn't count, but I just don't like it. I am intrigued to see how the trial goes, however. Eagles 24/7 (C) 02:26, 12 April 2011 (UTC)

   "If I was unable to create an article after creating an account, I would not have understood this "autoconfirmed" jargon, and I would have probably given up and never returned. " - say wha? where is it written that newcomers need to understand that jargon? And why do so many opponents of the proposal act as if under the proposal non-autoconfirmed users will be unable to create articles? [If the latter question doesn't make sense to anyone, read my View above.] Rd232 ^talk 02:28, 12 April 2011 (UTC)

   I'm saying that if I created an account on Wikipedia and I went to create an article, wouldn't I not be able because I am not "autoconfirmed"? I read your view, and I must say, there is so many different proposals and views on this page, I don't even know what I'm going against at this point. I liked your idea until I realized that it would take more work to help newbies create articles than to patrol new pages. We have a huge backlog for mentors, and there is no doubt in my mind that all of the newbies wanting to create articles will have to wait a long time for someone to help them. But whatever the community wants is what I'll support in the end. Eagles 24/7 (C) 02:38, 12 April 2011 (UTC)

   Eagles 24/7, your first edit was to create Marcus Mailei, about an NHL hockey player, a nice contribution including some fancy wiki-formatting (infobox) even in the first revision.[1] My guess is you already had some editing experience by then. What's the big deal about making the article in userspace and asking at WP:HOCKEY for someone to import it? Obviously the user interface would have to change some, to make that approach more natural. 69.111.194.167 (talk) 03:33, 19 April 2011 (UTC)

1. Wholeheartedly support - Close it. Frankly, I know the "slippery slope" argument is a bad one to use, but I'm gonna use it. Others have mentioned to me, and I agree with them, that the next step up from this will be requiring all users to have an account to do anything, something Wikipedia has been trying (and failing) to do for a long time, and with good reason. I said it in my view, and I'll say it again. Stop figuring out ways to prevent people from contributing. We're trying to encourage contributions, and this is NOT the way to do it. - Bugger off and write an article or something. Fish^Barking? 03:05, 12 April 2011 (UTC)

   A small but fairly vocal minority simply doesn't get it: the status quo, does not, as of 2011, work. The barrier to people creating articles without help is the very fact that Wikipedia has been around for 10 years and now has 6,822,553 articles and a bunch of non-obvious expectations about minimum standards. You can't get rid of that by pretending it's still 2002. You need to figure how to stop handing newcomers the keys to a very powerful vehicle without any training or assistance. Ignoring the large numbers that crash and burn is not an option indefinitely. There are only so many people who might reasonably be interested in becoming solid contributors, and every one we drive away by virtue of the status quo "here's petrol! here's matches! go nuts! ... ooh, fire pretty" approach is one probably lost forever. Rd232 ^talk 04:38, 12 April 2011 (UTC)

   Please assume good faith. It's one thing to hold a good faith belief that this proposal will have unintended consequences. But don't accuse people of purposefully trying to stop people from contributing when everyone has said the goal is exactly the opposite, to prevent new users from having a negative experience and improve retention. And don't tell people to bugger off. If you can't be WP:CIVIL then don't say anything at all. This is a discussion, not a crusade. Shooterwalker (talk) 12:54, 12 April 2011 (UTC)

   Please assume, that I do assume good faith. What I don't appreciate of this whole shebang is the fact that we are putting into place restrictions which we (the existing members of wikipedia) didn't have to go through. The people who started this proposal ARE purposefully stopping people editing by putting a restriction in place which says "you can write an article, but we're forcing you to let us work on it with you, or it's not happening until you wait 5 days and do this much work first." And when I tell people to "bugger off", it's because I'm angry that people are scheming over ways to stop newcomers writing without help, instead of getting on with writing.

   Perhaps you could extend your WP:AGF and WP:CIVIL warnings to users who are describing the oppose view as 'nonsense' or it's supporters as a 'tiny minority' or who refer to this proposal as 'stonewalling' by editors acting like 'religious fanatics'? I'd hate for it to look as though your concerns here were partisan or coatstanding. Bob House 884 (talk) 14:02, 12 April 2011 (UTC)

   I didn't describe "the opposing view" as "nonsense", I called the view that the "anyone can edit" principle is endangered by it nonsense. And I explained why it's nonsense. In any case, Bob, this useless and disruptive section is your creation. The only thing "let's not have a trial even though the proposal is supported by a large majority" could possibly achieve is the large majority saying "fine, if the minority aren't going to accept a trial, then we won't have one: we'll just do it." Rd232 ^talk 14:18, 12 April 2011 (UTC)

   Oh come on, if I wanted to be useless and disruptive I would be posting on the other proposals and pointlessly bludgeoning everybody supporting those. If you believe this proposal is a waste of time and not going to gain support, why are you bothering to engage with it? The trial is going to go ahead anyway so why do you have a problem with people who believe that it was wrong or premature to run the trial voicing their opinion on the record? (These questions are rhetorical by the way, you don't have to answer them and I suggest, if you don't want to waste any more time, that you don't bother answering) Bob House 884 (talk) 14:57, 12 April 2011 (UTC)

2. close and no trial, where did the 80% support come from? It looks to be a much smaller figure that like this idea. Graeme Bartlett (talk) 06:29, 12 April 2011 (UTC)

   Did you notice the 147 supports below Jayrons view? At the moment of writing Ironholds view is the oppose view with the most supports (47). 147/(47+147)= 75.7% support. This number has been 75-80% ever since the RFC started. What may make you think otherwise is the fact that some oppose voters are acting like religious fanatics, blocking any attempt at progress or data gathering because they know their view is the TRUTH^TM. Yoenit (talk) 07:29, 12 April 2011 (UTC)

   To be honest I only accepted the 80% point above for the sake of argument, I don't think its neccessarily accurate, but even if it is, I think thats very borderline. Also Yoenit I don't paticularly appreciate your insinuation that I am acting like a 'religious fanatic' - this proposal is practically my first post on this RFC and I am making an effort to engage in reasoned discussions. Bob House 884 (talk) 11:25, 12 April 2011 (UTC)

   On a Wikipedia discussion of this size, 75-80% is an overwhelming endorsement. To achieve this level of support for a change of this significance is even more impressive: most of the time, changing anything gets a large minority of people who can only see the costs and risks, in a "better the devil you know" sort of way. Rd232 ^talk 14:09, 12 April 2011 (UTC)

3. Support in shelving the idea per my view above. CycloneGU (talk) 20:56, 12 April 2011 (UTC)

Note

This proposal is being made on an invalid premise: that “a significant majority present strong dissenting arguments”. There is empirical evidence that the majority of contributors to this page support the original proposal: that non-Wikipedians should not be able to create articles unassisted. There is some debate over whether progress should be by implementation and review or trial. Obviously, most contributors to that debate are either pro the original proposal or at least not strongly opposed.

Note also that there are currently only 4 users supporting the ‘Close discussions without any trial period’ proposal. Because counters to comments made by this tiny minority are appearing in the ‘endorsing’ section, the appearance may be otherwise.

One of the naysayers to the original proposal made a strong case on Jimbo Wales’ Talk page. Now I imagine Jimbo’s wish would be for the community to be able to reach consensus – particularly on what most would have considered a non-contentious issue – without giving his view undue weight. But his wider point, relating to progressive change not being stifled by a tiny minority is well worth repeating here, along with the sentiment that this change would in no way breach the site’s philosophy:

My opinion is that I can't possibly have an opinion without empirical evidence. I think the community should send strong signals to the Foundation that we want them to test things, and that not every little change to Wikipedia requires a massive referendum, and that *especially* we have to let go of a culture that allows a tiny minority of people to block progressive change.--Jimbo Wales (talk) 21:37, 7 April 2011 (UTC)

Rd232 also makes an excellent point regarding our philosophy, and distinctions in when and how rather than what users can edit, see comment under (1) above.

We do have statistical data on new user page creation. It indicates that 18.2% created an article, of which 73.6% of articles were deleted. Of those whose articles were deleted, only 4.8% are still active, versus 10.4% retention for new users overall. This is not the whole picture, but we can establish a standard report and run it monthly, as Mr.Z-man, who ran the reports, suggests – this will give us comparative data for the policy change.

I would suggest that a successful policy improvement would be indicated by an increase in retention rate for new (or newly confirmed) users creating an article and a reduction in first article deletion rate.

RedactionalOne (talk) 18:07, 12 April 2011 (UTC)

Proposal: Implement these changes for all users, not just newbies

At least for the term of the trial, let's just apply these changes to all users. Experienced wikipedians will be able to tell us (and will, in great numbers!) if the AfC/ACW processes are irretrievably broken. A simple opt-out mechanism in user settings or something and a week-in-advance warning that the trial will happen should be enough that no one is really surprised or offended.

As a speculative trial, this would be authorized on a week by week basis, and if it's really disruptive, kill it off.

If we're assuming that Wikipedia already has an article on everything, then even experienced users should have to jump through some hoops (albeit pretty low ones, such as a second opinion) to create a new article. Maybe make it so an autoconfirmed user has the ability to authorize an article to "go live" but everyone needs a second opinion to bring a new article into the world. Probably have to have a separate process for redirects.

This isn't going to help NPP much, but it will give us useful feedback on what works and what doesn't, and it's not bitey at all. SDY (talk) 16:23, 12 April 2011 (UTC)

??? Good, so after you switch it on for everyone, you'll need to switch it back again 4 days after that. 'Cause that's what the idea is... Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 16:39, 12 April 2011 (UTC)

• Right. I've written almost 60 GAs and almost 20 pieces of featured content, out of the 600 articles I've created in total. Explain to me, if you will, why I am not considered competent to evaluate whether a subject is notable, and what the encyclopedia possibly gets out of banning me (or anyone else in a similar situation) from creating articles. Ironholds (talk) 16:43, 12 April 2011 (UTC)

(e/c) I'm sure that you'll concede that you're an extremely unusual user and the system should be built around typical users, not outliers. If nothing else, putting these restrictions on experienced editors means that the encyclopedia gets informed feedback on the article creation process. If, in good faith, we assume that there aren't many new articles that should be created, then any user would benefit from a double check. If we assume that there are still a lot of articles yet to be started, then we have no business cutting off the spigot of truly new articles and most of them will come from new users saying "there is no article on foo and my objective is to fix that." The purpose is to show that this is about managing content, not about users. SDY (talk) 17:10, 12 April 2011 (UTC)

• Yes. Excellent idea. Since we as existing editors didn't have to go through this when we joined Wikipedia, we'll be able to see it from the users view, and as SDY says, it'll generate a significant amount of feedback from editors as to whether AFC and ACW are bust (we already know they are, but confirmation is a plus). And Ironholds, what is does is put us in the same situation as the users, so we have a view from their side as to how helpful (or not) this will be. I'd support this in a heartbeat. It may actually show us as editors what effect this is liable to have on a newcomers view of Wikipedia. Fish^Barking? 16:56, 12 April 2011 (UTC)
  • Just about the craziest idea and the daftest support rationale I've seen on wikipedia today. Unless you're a new editor you can't possibly know what the new editor experience is like. Malleus Fatuorum 16:58, 12 April 2011 (UTC)

We may not be able to "be" a new editor, but at least we'll be able to figure out if the system is actually capable of producing valid results. If the ACW breaks or the instructions don't make sense, I want it to break for an experienced user so that they know where to go get help and get it fixed, not on a new user who says "this doesn't work, what a mess I'm not going to bother." Yes, I concede that the idea is crazy, but sometimes a little bit crazy is good. If nothing else, this is just a trial to collect data rather than a permanent solution. SDY (talk) 17:10, 12 April 2011 (UTC)

• As I said above, going with the idea of this whole proposal, you can only do this for 4 days. That's how long it takes to be autoconfirmed. So you'll just make everyone wait for 4 days. Very pointy, but ah well... Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 17:00, 12 April 2011 (UTC)
• I'm not quite sure what the "week-by-week" trial element really means, but a similar idea to turn on the AFC/ACW interface for all users by default (with option in preferences to turn it off) has been suggested on the talk page. The idea being that users are directed there when they try to create a page (unless the referring URL comes from the AFC/ACW page). I think it makes a lot of sense, because it would be a good way to clearly introduce new users to the available options, and retains it for individual users until they actually want to turn it off, rather than somehow removing it willynilly just because they've been around a couple of days and made a handful of edits. Rd232 ^talk 17:28, 12 April 2011 (UTC)

The trial would force that user setting to "on" for all users to try and get some people to use the tools. It'd be "presumed consent" and "opt out" rather than looking for volunteers to "opt in" because most users don't create an article (other than redirects) very often and people doing so for the purpose of challenging the system are probably going to go in with a biased view. I've played with the ACW, and it seems OK to me, though the article I was trying to start wasn't one of the standard article types the wizard tries to create. SDY (talk) 17:42, 12 April 2011 (UTC)

Herding new users onto WP:AFC isn’t what we’re trying to do here: the aim is that the user edits articles and/or becomes familiar with what’s what before trying to create any. It’s great that Wikipedia can be more up-to-date than any printed encyclopaedia, but I can’t think of any article that absolutely has to be up the same day! WP:AFC is not going to produce that improvement in new user experience and thus retention most of us here are hoping for. If new, unconfirmed signups, who are currently not encouraged to create articles, are suddenly encouraged to use WP:AFC obviously it’s going to break under the load – 9926 article creations a month by new signups = 320 a day! RedactionalOne (talk) 18:31, 12 April 2011 (UTC)

Do note that the AFC and Article Wizard systems are now combined; check out Wikipedia:Article wizard/Ready for submission for the options available at the point of drafting: AFC, userspace draft, or live via wizard. Rd232 ^talk 19:40, 12 April 2011 (UTC)

This looks excellent. (There just seems to be a missing graphic in Step 2.) I would be in favour of this wizard being the required route for the first article for all users, because it informs the user what the standards are without overwhelming them, gives links for more info, and presents choices for ‘Submit for review’, ‘Userspace draft’ and ‘Go live now!’, indicating which options are valid for whom. (It would be good if there was a link for more info for the ‘Submit for review’ option.) I’m sure it would significantly mitigate ‘deletion frustration’. In terms of the discussion on this page, it would only be necessary to change ‘registered users’ in Option 3 to ‘auto-confirmed users’.

Note that there’s actually no reason the same limit of 4 days / 10 edits has to apply for new article creation. A min 24 hours and 2 edits could be set, and a special wizard could be created to make those edits in a sandbox, starting with good (green tick) and bad (red cross) editing examples and then guiding the user through making two of their own on a dummy page, which they could then view. The 24 hour minimum would reduce deliberate abuse, and possible further restrictions down the line, like inability to add the ‘file’ tag or make extensive edits would be less controversial when applied only during the first 24 hours.

RedactionalOne (talk) 22:21, 12 April 2011 (UTC)

No hope to reach consensus on implementation in current format, suggesting proposal on new page

There's no hope of reaching consensus on implementation in the current format of the RFC, and this page is getting too long, I suggest that a clear proposal for a trial be made on a separate page. If you agree, we should discuss the format of the new page. I've tried to encompass the above proposals, I suggest asking two questions:

1. It is proposed that after a preparation period of one month, a trial where creation of articles will be restricted to confirmed users be conducted for three months. Do you support or oppose ?
2. Should we automatically revert to the present situation at the end of the trial ? If we don't, a reversion to the present situation will occur after three more months unless there is consensus to do otherwise.

The format for answering should be the standard support/oppose/comments. Cenarium (talk) 17:36, 12 April 2011 (UTC)

This makes a lot of sense, except that the half a dozen or so people strongly protesting the majority view will just start a whole load more derailing there. Maybe we should give it a day or two first. This would also give people a chance to seek additional stats, say. RedactionalOne (talk) 18:47, 12 April 2011 (UTC)

I'd like to note that the most widely endorsed views expressed above don't specifically advocate a trial. I would be inclined to vote against a trial, although I'm strongly in support of requiring autoconfirmation, so I think that any proposal should include a trial-free option. Rivertorch (talk) 18:59, 12 April 2011 (UTC)

The problem is that if we add a third option in the first question, it will be difficult to determine the consensus (people may support an option conditionally, or exclusively). Maybe then we need a preliminary question of which proposal it should be: trial or indefinite, we could do this below on this page. Cenarium (talk) 20:01, 12 April 2011 (UTC)

Right, let us talk some more, to decide if should talk more about talking more. Then we can talk some more about that, instead of improving or protecting content. Let us do something to protect content, instead talking for ever. History2007 (talk) 21:07, 12 April 2011 (UTC)

I don't feel strongly for or against, though I prefer Collect's suggestion above. However, if there is a trial, let's learn from our experience with Pending Changes. Let's make it crystal clear whether, if there were to be no consensus at the end of the trial, we would revert to the pre-trial position, or whether continuing the trial indefinitely would become the default option. Certes (talk) 19:28, 12 April 2011 (UTC)

• Just for amusement, I've created a separate subpage to address the basic question: should we have a trial at all? As WaID has pointed out on the talk page, we need to actually decide what we want the trial to prove before we start designing it, so also trying to collect that information there: Wikipedia:Village pump (proposals)/Autoconfirmed status trial. Hopefully this will give us a sense of whether there's consensus that a trial is needed. SDY (talk) 19:43, 12 April 2011 (UTC)

• The first personal computer was made just for amusement too. I have responded there, and I agree that that page should get attention. History2007 (talk) 20:25, 12 April 2011 (UTC)

• We shouldn't assume consensus exists for either. As noted, the level of participation is not high enough to legitimate the move yet, this RFC is just a first step. Two hundreds of users is little compared to the active community. Cenarium (talk) 20:37, 12 April 2011 (UTC)

• There's been plenty of discussion on this, and it's been well publicized. If this is not enough input on the proposal, how much more is needed? SDY (talk) 22:03, 12 April 2011 (UTC)

• As discussed here, for a change of this magnitude it hasn't been enough. A few hundreds users participating in a policy discussion happens quite occasionally. This is a major structural change precedented only by the restriction to registered users of page creation, it needs a sitenotice for registered users. Cenarium (talk) 22:07, 12 April 2011 (UTC)

• I've suggested a poll at Wikipedia:Village pump (proposals)/Restriction of article creation to autoconfirmed users. What do you think ? Cenarium (talk) 22:11, 12 April 2011 (UTC)

• Someone else did this too. CycloneGU (talk) 22:46, 12 April 2011 (UTC)

• Different questions. What I created was not a poll in general on the topic, it was a specific request for information about trials. SDY (talk) 23:22, 12 April 2011 (UTC)

I've come up with (hopefully) a far less divisive option - see at 'Proposal: Implement these changes for all users, not just newbies' above. Basically, it's use of the wizard combined with an even lower 'pole' of 24 hrs and 2 edits, separate from the auto-confirmed status requirements. RedactionalOne (talk) 22:30, 12 April 2011 (UTC)

Seems to me that the lack of consensus is because a quarter of participants strongly disagreed rather than the format of the page. Most of those 200 odd people have probably gone away, thinking the process to have ground to a halt, and a handful of proponents are continuing towards the original proposal as if the reason for the lack of consensus was a presentation problem. Well none of the opponents was saying 'This page is just too confusing so I'm going to oppose'. Isn't a continuation where the proposal and arguments remain the same but the debaters have disbursed in danger of being critisised as a way to get a controversial proposal through without consensus? Wouldn't it be better to try and find the middle ground? It would be a great shame if the trial being attempted became seen by some as another Trojan horse. RedactionalOne (talk) 16:38, 21 April 2011 (UTC)

Huh, 200 odd people strongly disagreed with what? Yoenit (talk) 17:08, 21 April 2011 (UTC)

Looks to me like they were disagreeing with the status quo more than the proposal. The Blade of the Northern Lights (話して下さい) 21:46, 21 April 2011 (UTC)

Yoenit, 200 odd original participants. The Blade of the Northern Lights, that's a highly creative interpretation. So the guy who thought the original proposal should be 'burnt with fire' was actually supporting it? RedactionalOne (talk) 14:07, 22 April 2011 (UTC)

Yeah, you said 200 odd people already, but what on earth did they disagree with? If you think 200 people disagreed with the original proposal you are wrong. About 400 people commented on the proposal [2], of which approximately 200 signed Jayron32's view. That does not mean the other 200 "strongly disagreed". Yoenit (talk) 14:36, 22 April 2011 (UTC)

That's the 200 I was referring to; those who signed Jayron32's comment. Stating the other 200 strongly disagreed is denying the antecedent; just because they didn't say they agreed with us doesn't mean they agreed with the other side. To crib from Yoenit in another unrelated discussion, that's like saying if it's raining when there are clouds, it's not raining when there aren't clouds. The Blade of the Northern Lights (話して下さい) 18:08, 22 April 2011 (UTC)

I wasn't saying there were 200 opponents - I was giving that as a ballpark figure of participants (if there were more then great) and saying most participants have now left the room. To crib from myself three days ago, "The proposal for using autoconfirmed status (4 days / 10 edits) seemed to gain about 75% support, but there were strong objections from a vocal minority, who were concerned that some of those signing up in order to contribute an article (perhaps after years of IP edits) would feel disenfranchised. For this reason, consensus did not appear to be achieved." I'm not one for denying the antecedent. But maybe there are some here who wish to affirm the consequent. RedactionalOne (talk) 18:59, 23 April 2011 (UTC)

No assurance that a "trial" is not a trojan horse

We had a "trial" of Pending changes and those who supported the "Trial" were promised that it would be "for a two month trial period that began on June 15, 2010." It didn't end. Then there was an RFC where the consensus was to give it an extension with a drop-dead date of December 2010. It didn't end. Now there is another RFC with a clear consensus (112 to 51) that it should be ended at once. Yet it has not ended. Given this history, I cannot support anything that is described as a trial with a defined ending point. Credibility has been damaged too much for that.

See Wikipedia:Pending changes/Request for Comment February 2011 for all the ugly details.Guy Macon (talk) 23:54, 12 April 2011 (UTC)

Strongly agree. Let's make sure a trial is actually asking a question that can be answered, and that one of the possible answers is no. If no is not a possible answer, just be honest and implement it directly. SDY (talk) 00:19, 13 April 2011 (UTC)

The issue with PC is that it's too hard to keep switching on and off; I can't imagine this would be nearly that difficult, so it shouldn't be as much of an issue. The Blade of the Northern Lights (話して下さい) 15:52, 13 April 2011 (UTC)

I have been following PC closely and never noticed a claim that there was an unanticipated technical reason why the promises to remove PC were broken. That would be very interesting information that would reduce a lot of the bad feelings that breaking the promise has caused. Guy Macon (talk) 16:16, 13 April 2011 (UTC)

At the beginning of the RfC in August/September (can't remember exactly, I think I'm right), the developers indicated that it would be way too difficult to turn PC off, then turn it back on if consensus was for it, so they left it on until consensus definitively developed one way or another. The Blade of the Northern Lights (話して下さい) 17:05, 13 April 2011 (UTC)

If I understand correctly, PC would be hard to reinstate once the infrastructure has been dismantled. However, it would be easy to remove PC from each article that has it, leaving the feature available but unused. This probably needs to happen even if PC becomes permanent, because the articles chosen for the trial may not be selected for live PC. Certes (talk) 18:45, 13 April 2011 (UTC)

That is also my understanding of what most people mean when they say "end the trial" - remove PC from each article that has it, leaving the feature available but unused. The fact that this has not been done despite a clear consensus to do so makes me question whether we can trust that a limited time "trial" of requiring autoconfirmed status in order to create articles will end when promised. I like the idea of requiring autoconfirmed status (possibly with shorter timeouts) for article creation, but I think any "trial" should be clearly labeled so the commenters know they are supporting or opposing an indefinite trial. Guy Macon (talk) 00:09, 14 April 2011 (UTC)

We're talking apples and oranges here.

• With PC, the devs have promised that if the software is de-installed at our request, they will refuse to re-install it. The feature can, however, be left unused at the discretion of the admins (just like the admin corps could refuse to delete any more articles, if that's what they wanted). PC continues to be used because no one in our admin corps chooses to lock the remaining half of PC articles back into semi-protection, not because of any technical issue.
• With autoconfirmation, the feature must be implemented by the devs. It's not up to "us" or "the admins"; our control is solely limited to making a request—which they can fulfill or not, at their discretion. We can't change the settings, and we can't change the necessary supporting infrastructure (like the contents of the "Unauthorized" page, which tells anons that they need to register an account to start a page.)
  If we make (and they accept) a request that says "Please configure the system like this for 30 days, and then restore it to the original settings", then I think we can be reasonably confident that the devs will fulfill their promises. (Of course, they have the right to refuse to do it at all; we can't force them to change the setting at all.)

In short, I believe there's no reason to worry about this. It might make a convenient WP:COATRACK for airing our discontents over the PC mess, but the situation is significantly and importantly different. WhatamIdoing (talk) 17:47, 14 April 2011 (UTC)

This could easily be implemented with an edit filter as an easy trial without using developers. hen we don't need to get into other difficulties with developers being annoyed at changing consensus. The edit filter would also tell us how many were knocked back. I am not sure if the filter could force the article wizard though. Graeme Bartlett (talk) 21:24, 15 April 2011 (UTC)

• The trial period model has not worked well for us. WP:PCRFC being a prime example of a spectacular failure. The real issue has been lost amongst the complaints about the trial was run and now it is a horrible quagmire with no end in sight. The fact is that almost everything about Wikipedia can be changed in the future if the community decides it isn't working. Defined trial periods are not needed as any action we take to day can be reversed in the future if hindsight proves it to have been a mistake. Beeblebrox (talk) 22:43, 15 April 2011 (UTC)

• I disagree, we just need to clearly state beforehand how it will end. We can require an automatic reversion to the current status, which the devs will make effective after three months in any case. Cenarium (talk) 22:52, 15 April 2011 (UTC)

Proposal: 24hr / 2 edit / wizard requirement for first article

See here for the revised proposal

There’s actually no reason the same limit of 4 days / 10 edits has to apply for new article creation. A minimum of 24 hours and 2 edits could be set, along with a requirement for the wizard – which now incorporates the AFC option – for the first article. (This wizard is so good at informing the user what the requirements are, why they’re there and where to get more info that I would suggest it as the required method for starting the first article for all users (not, obviously, applying to anyone who’s already created one).) The 4 days / 10 edits would remain in place for autoconfirmation.

A special wizard could be created to make those 2 edits in a sandbox (if they haven’t made them elsewhere), starting with good (green tick) and bad (red cross) editing examples and then guiding the user through making two of their own on a dummy page, which they could then view. The 24 hour minimum would reduce deliberate abuse, and possible further anti-vandalism restrictions down the line – like inability to add the ‘file’ tag or make extensive edits – would be less controversial when applied only during the first 24 hours.

Added as proposal here after suggestion by BarkingFish.

Users endorsing this view

RedactionalOne (talk) 00:02, 13 April 2011 (UTC) (proposer)

Guy Macon (talk) 00:28, 13 April 2011 (UTC)

Fish^Barking? 03:30, 13 April 2011 (UTC)

Discussion

"There’s actually no reason the same limit of 4 days / 10 edits has to apply for new article creation." - of course there is. You're effectively proposing the creation of a new Article Creator userright with slightly lower standards than auto-confirmed. Rationale for why this additional complexity is a good thing when autoconfirmed is anyway a low barrier and there are various assistance options for non-autoconfirmed users (see my View above) is not clearly given. There's a hint of "less controversial" (than applying autoconfirmed standards to article creation), but that seems unlikely to be significant. PS "editing examples", though, to say something positive, are something I've wanted for the Wizard for a while, modelled perhaps on the way WikiProject quality standards are done (describing B/C class etc, with links to example articles). Would definitely be helpful.Rd232 ^talk 04:04, 13 April 2011 (UTC)

I think the bar should be set much higher. Wikipedia is the new Craig's List now and unless more protection is added, it is well on its way to become "the largest rummage sale on the planet". Therefore, much more protection is needed. History2007 (talk) 06:22, 13 April 2011 (UTC)

Rd232, a 7th step for the article creation wizard? Yes, that could work. (Presumably, return users would be able to skip the making the two edits bit? I guess if one was being really fancy one could automatically hide that step if the user had edits under their belt.) Hopefully the rationale below is clearer. The original proposal was based on it being technically easy. But it seems obvious that it’s divisive, and even if it passes there will be lingering resentment of a fait accompli by a minority, which doesn’t seem good for the community. RedactionalOne (talk) 15:01, 13 April 2011 (UTC)

I didn't mean an extra step as such; I'd hope to be able to incorporate examples without that, eg by providing snippets at a relevant point and then linking elsewhere for more detail. Rd232 ^talk 18:22, 13 April 2011 (UTC)

Maybe a wizard specifically for making edits in a sandbox could be developed additionally, then. The idea is that this new user who's waited 24 hrs and is keen to create his/her first article shouldn't be required to go into live articles to make 2 edits that don't need making. Talk page edits wouldn't count, so the user would need a way of making a couple as if on a live article, after getting some guidance and seeing good/bad examples. The linking elsewhere you suggest could also link to this Edit wizard, because that would include the links to other editing info. RedactionalOne (talk) 19:48, 13 April 2011 (UTC)

2 edits that don't need making - What? There are millions of edits that can be made to improve our existing articles. Why on earth would we waste our time setting up such a system and new users time making useless edits? If we're going to guide users through their first edits, we should show them how to find articles that need improvement that they might be interested in. If they're not even remotely interested in making any edits other than creating their article, then we need to consider whether they're actually the kind of user we should be expending effort to retain (see views by Rivertorch and Malleus Fatuorum). But making 2 edits in a sandbox will hardly prepare a user for creating a new article. They'll get a feel for how editing actually works, but they won't get any real experience that they couldn't get by reading a help page or two. Mr.Z-man.sock (talk) 16:11, 14 April 2011 (UTC)

Well yes, my personal opinion is that the better thing before starting one’s first article is to spend a good couple of months editing articles and familiarising oneself with the guidelines and the community mechanisms. But a core principal of Wikipedia is that users should be able to contribute immediately, and a number here are evidently of the view that this should include the rapid access to article creation that they currently enjoy. Consensus has failed due to those objections, and so I’ve listened to them.

Now in the scenario that the user has joined (maybe having previously IP edited) specifically to create an article and has waited the 24 hours (in this proposal), if we require 10 edits the danger is they’re going to go into a random article, add commas, add and then remove words – whatever – in an attempt to notch up their edit count. This would frustrate both them and editors monitoring those articles. And it helps that first article not one bit.

The Edit wizard would also have another – in fact primary – purpose. To be the wizard offered immediately at signup. Bear in mind that around 75% of first contributions are edits, and this would be a quick, helpful way to guide the user through that process just as the Article wizard does for article creation.

Note that in 2010 only 63% of new users had made 10 edits within two months. It might seem like a minimal requirement for an editor with 1000 articles on their watchlist, but that’s not the way most newbies roll.

The 2 edits thing seems like a good idea notionally to me, but technically it’s slightly tricky with the sandbox, as it means either a separate counter or adding those 2 edits (technically incorrectly) to the mainspace edit count. A more workable alternative would be to simply make completion of the Edit wizard (once it existed) a requirement if the 2 real edits hadn’t been completed. Or, most simply, to have a 24 hr and Article wizard requirement only.

The 24 hrs addresses important issues of deliberate abuse – particularly by blocked users creating another account – and could deliver significant reduction in vandalism down the line if restrictions on major edits by < 24 hr users were later agreed. It also gives the user time to draft a better article and read procedures. And the requirement of the Article wizard for first article ought to help with article quality, reduce numbers of inappropriate articles, reduce ‘deletion frustration’ and increase retention. I’m not, however, sure that a 10 edit restriction would help at all – it might merely generate frustration, which itself leads to poorer quality articles.

Oops – rather verbose reply! And just to make it a bit longer: A nice addition to the last step of the Edit Wizard would be a list of articles identified as needing editing for consistency, so thanks for springboarding that thought.

RedactionalOne (talk) 22:54, 14 April 2011 (UTC)

IMO, 2 edits in a sandbox is worse than doing nothing. It accomplishes the same thing as doing nothing (letting users create an article with no useful experience), but with a useless delay, and at increased cost in terms of development time. Worse, if the sandbox system is too easy, it might give new users false confidence, leading to an even bigger letdown when their article is deleted. Or alternately, if its too hard, it might discourage users before they make a real edit. I don't really care about abuse, it shouldn't be a primary consideration in this. Again, if a user is frustrated by having to make 10 edits, they probably aren't a likely candidate for a long-term editor. The goal should not be to get as many articles as possible, the goal should be to get as many users as possible. In the long-term (and probably the short-term as well), we will be far better off with a larger active userbase and fewer articles than a large collection of articles that a small userbase struggles to maintain. I guess, to summarize, this proposal entirely misses the point. It appears to be trying to apply the same mechanisms as the general proposal to solve a different problem. Mr.Z-man 02:48, 15 April 2011 (UTC)

Again, I agree on a personal viewpoint level that quality articles and enough active editors to maintain them is a sound aspiration, but not at the expense of the Wikipedia philosophy. As already stated in this section, “...any measures instituted for security must address a compelling community interest, and must be narrowly tailored to achieve that objective and no other.” Additionally, “There must be ... no hierarchy or structure to get in the way of this openness to newcomers”, who should be “given full privileges ... [in] a very short period of time.” Also, “’You can edit this page right now’ is a core guiding check on everything that we do’” It is not going to be deemed acceptable – by either parts of the community or, probably, the Foundation – to set onerous requirements for first article creation. So what’s the point in proposing that again?

The research is indicating that we have plenty of editors and stable retention. However, the way the current system allows article degradation and defacement so easily must be frustrating. And newbie frustration must be significant for users who don’t run the Article wizard first time and get their article pulled. (In case you haven’t reviewed the wizard recently, here are the links: 1, 2, 3, 4, 5, 6. Note, particularly, Step 6.)

I’m not talking about a blank sandbox, I’m suggesting a helpful wizard that presents one or two realistic problem passages, explains why they’re substandard and allows the user to resolve them. It’s a problem for me to articulate just what I mean without paragraphs more of text or actually creating it. But I’m certainly confident that it would be helpful for anyone who hasn’t edited before, and I’m disappointed that you’re trashing the idea before you even see it in action.

I think the new proposal maintains the rationale at the top of this page, has important additional (foundational) advantages and is more in keeping with the guiding principals. An IP editor who signs up in order to create an article is going to be frustrated by having to wait 4 days and make 10 edits – and still in all likelihood have their new article deleted. What is your idea for moving forward?

RedactionalOne (talk) 14:58, 15 April 2011 (UTC)

Again, this is not a security measure. It will likely have the effect of reducing spam and vandalism, but that would just be a beneficial side effect, not a goal. The primary purposes of this are to A) Improve new users' experiences making them more likely to stay by B) reducing the number of new users who, in good faith, create an article that gets deleted. The idea that anyone can edit anything at any time actually seems to be a relatively recent idea, if not something just made up to oppose this (it sure wasn't around when we came up with semiprotection, or when we increased the 10 edit requirement to autoconfirmed). Historically its just been "anyone can edit," and anyone can still edit the existing 3.6 million articles. Given that nearly 80% of the community supports it and the current registration requirement was put in place by the foundation (sort of), I don't see that as an insurmountable obstacle. TBH, I don't see 24h/2e as much less of a barrier than 96h/10e. I think putting any requirement is going to be a significant barrier. Even 12 hours is still a fairly long time to wait.

A constant number of users is really not a good thing. A better metric is the editor/article ratio. Ideally it should be at least stable, if not increasing.

I just don't understand why, when we have hundreds of thousands of articles that need improvements and we even know what improvements they need, we would have users editing sandbox scenarios. I suppose its not definitely going to fail, but it seems a lot harder and more likely to fail. I don't see how it will be more useful than making real edits. Typically the main reason one would use an artificial scenario is because you can't use a real one. But we're buried up to our necks in examples of problematic articles.

Actually, based on the results of my most recent new user study, users who edit other articles in addition to creating one are much less likely to have their articles deleted. Of users who only created an article in their first 5 edits, 77% had it deleted. Of users who also edited an article other than one they created, only 37% had their article deleted. Mr.Z-man 20:14, 15 April 2011 (UTC)

Well 24h/2e is 25% of the wait and 20% of the edits. I think the chief objection from the vocal minority (I don’t include myself, as I do not oppose 4d/10e – I just think 24h/2e is more beneficial on balance) was the 4 day wait before creating first article. (Certainly that was the case for BarkingFish.) Are you saying 2 edits is too few? I’m getting confused, because you indicate that there’s little difference between 4d/10e and 24h/2e, and yet you seem bothered by the Edit wizard – which wouldn’t be a requirement. (It’s the Article wizard that would be, for the first article only.)

Yes, I’m very clear on the reasons for this discussion – my reference to rationale was meaning the four points above the Contents box. (Re #4, I actually think that a well-constructed Edit wizard could provide a more valuable editing experience than correcting 10 typos, because it would be addressing the issues of editing, rather than concentrating on the mechanics – exactly as the Article wizard does.)

I’ll try to clarify some things relating to the proposed Edit wizard:

• It would not need to be in place in order to implement this proposal (the new user could make two real edits)
• It should put the newbie at ease – she sees just a small snippet of code, on a split screen with the output, so the process unlocks itself easily
• It’s a welcoming, inclusive gesture, in line with core principals – helping in particular the vast majority of people with no coding knowledge
• Under the current system, well below 50% of new users have reached 10 edits after 10 days; 10 edits can therefore be seen as a not insignificant barrier
• There would be various article links, with Article-wizard-like explanations of their significance – plenty of useful stuff, even to an experienced IP editor
• With a list of random articles flagged for editing on the ‘wizard complete’ page, some would participate – useful article cleanup, and an article success benefit as per your findings

I got my information on Wikipedia’s principals from the horse’s mouth, so to speak. These are quite different to the ones you linked to, and, I would suggest, much more expansive and up-to-date and thus pertinent to this debate; as WhatamIdoing notes above, this change will need to be implemented by the devs, and will require the Foundation’s full backing.

I think 24 hrs is a very useful differentiation to have built into the system. Yes, I know vandalism wasn’t part of the original rationale, but that’s because the 4 day wait for autoconfirmation would be a controversial wait for granting major edit status. 24 hrs, on the other hand, seems to me about right. Now obviously that’s a whole other discussion, but hopefully most in the community would agree that would finally make an edit block mean something. It would also help reduce vandalism when, say, a news topic involving the subject of an article went viral. Use of the ‘file’ tag and blanking / wholesale replacement of text could also be prevented during the first 24 hrs, and I don’t think this would be too controversial. (If we end up proposing something similar to 24h/2e to the Foundation, we should mention this anti-vandalism outline – otherwise they might question the dev time in making the change.)

The subject of redirects is worth mentioning: Some editors here started with these after switching from IP editing, and a 4d/10e restriction would stifle these.

RedactionalOne (talk) 00:20, 16 April 2011 (UTC)

I'm mainly concerned that using a wizard to teach people how to edit, in which they don't actually make a real edit is going to leave users woefully unprepared for creating a new article, which is a fairly difficult editing task. To use the oft-referenced driving analogy, its like giving someone a drivers license after having them drive around an empty parking lot for 2 minutes. I don't understand why we're skipping straight to complicated solutions without even trying the simpler ones. I don't see why you're making the assumption that users would just fix 10 typos, when I've said – several times in this thread alone – that we could, and should, point them toward real articles that they might be interested in or real problems that they might be interested in fixing. They might even realize that they don't need to create a new article to add whatever bit of information they have, it might fit into an existing one on a broader topic. As for 24 hours still being a barrier, its like a fence. A 2 foot fence is smaller than an 8 foot fence, but its a fence nonetheless. I don't really understand how a copy of principles can be "up to date" - the principles of the site are not something that should be changing very often. Unless someone with authority from the foundation has actually expressed a concern, we shouldn't operate under the assumption that they will. Mr.Z-man 04:36, 16 April 2011 (UTC)

OK, let’s use the driving analogy: The current situation leaves the keys in the ignition of every car at the car hire lot (and also a couple of tanks out back). There’s a big sign saying ‘Please drive carefully and read the [bulky] Highway Code and Car Manual in the glove box’. The lot is right next to the high school. There’s one patrol vehicle and thousands of cars. If a driver gets nabbed, she just helps herself to another car.

4d/10e: As above, but cars aren’t allowed onto the freeway for four days. Also, to get on the freeway the engine has to be warm – this could be from careful three-point turns or burning rubber down residential streets at 3am. If they’re nabbed, they just get another car from the lot.

24hr/2e/wizard (with later major edit restrictions): The tanks and large-cc vehicles are off-limits for the first day. The learner is initially given the sort of car a driving school would use. Because those running this car hire firm recognise that many users will want to get going quickly (and these are bespoke cars, and their clients are all used to different road rules or can’t drive), they give them the tools for an intensive driving course: there is a quick-start guide to the motor vehicle and another for the Highway Code. The former is encouraged and the latter is required before highway driving.

The quick-start guides don’t guarantee proficiency, but the learner is warned that their car will be taken away if there’s dangerous driving, and they won’t get another for a day. They’re also given the option of driving in a town mock-up if they’re worried about mowing down pedestrians through poor clutch control. (All the cars are currently manuals – one day they hope to upgrade to autos).

The government has ruled that highway driving should be available quickly. The car hire firm staff are worried about this, but realise the safest course of action is to get the learner up to speed as quickly as possible.

Possibly an over-extended analogy there. ;) I don’t see it as a complicated solution. Basically, I’m just saying that those who’ve set out to create an article are just going to get frustrated and disenchanted by a 4 day wait, and so create a poorer quality first article or give up. I’m suggesting 1 day – 1 more than we have now. Direct access to a blank article is not easily discoverable, so I don’t think we even have to make the Article wizard a requirement – simply remove references to AfC from the welcome templates. (Remember that the AfC option now exists within the Article wizard – Step 6.)

The Edit wizard is highly desirable for reasons I’ve already gone into, including that it could be the wizard encouraged at signup – ie at 0 hrs. I think that for technical reasons, a 2 edit requirement at a system level might actually be more trouble than it’s worth. Instead, if the Article wizard was able to detect an edit count < 2, it could maybe either call the Edit wizard or highly recommend it in the first step – I haven’t yet looked to see what’s possible. (This would also give the advantage that we could adjust the edit count requirement experimentally just by tweaking the wizard(s), without system changes required.) So, while I see the Edit wizard as highly desirable, it wouldn’t need to be in place initially.

Really, all we need is the new 24 hr milestone to be in the system and for the Article wizard to be the more discoverable option and the only one linked in the welcome templates – the latter being something we can do ourselves.

RedactionalOne (talk) 19:41, 16 April 2011 (UTC)

Ah, haven’t quite addressed all your points. The world at large is not well-versed in any form of markup. Going, once again, back to the driving example, you wouldn’t park someone with zero driving experience on the highway hard shoulder and leave them to it! The Edit wizard would be for both the technical and policy issues of editing – and would encourage actual editing in the last step – and the Article wizard would (and does) guide the new user through the guidelines. A new editor who’d gone from Edit wizard to editing a suggested article to Article wizard, reading links on things they weren’t clear about, would potentially have more relevant experience for creating a notable, quality article than one who’d found their own way through making 10 edits over 4 days.

This is because the Article wizard is an excellent guide to policies. (I think the markup advice is open to improvement.) And I would hope the Edit wizard would be similarly beneficial for the editing process.

Note that there’s no intention to encourage article creation on Day 2 – there would be no message to the user on that day. If the new user has signed up in order to create an article, their mind is unlikely to be on editing others. However, yes, I’ve already said a couple of times that the addition of a list of articles flagged for editing at the completion screen for the Edit wizard would be great – it could see a significant volume of new users making minor but useful edits, especially if we include a link to it on the ‘signup complete’ screen. (I haven’t yet found what it is we say there.)

In summary, my solution is simpler than the original proposal, setting aside the Edit template; that isn’t a requirement, but is the obvious missing link in the chain for new user induction, and so is definitely worth the effort.

Re the core principals, the page I linked to was the user page of Jimmy Wales, co-founder of Wikipedia. They can be interpreted as a green light for progressive change subject to avoiding unnecessary obstacles. 4d/10e doesn’t seem like a massive obstacle to me for first article creation, but some disagree. For first redirect, there’s a strong case for saying it’s OTT.

RedactionalOne (talk) 20:58, 16 April 2011 (UTC) ETA RedactionalOne (talk) 21:02, 16 April 2011 (UTC)

Its not extremely complicated, but it is more complicated than simply pointing users toward existing articles. It also loses the advantages of getting users to improve other articles and potentially encouraging users to expand existing articles rather than creating new ones. So it will do almost nothing to reduce the load on NPP or reverse the quantity over quality philosophy that we encourage. Editing existing articles is really not very difficult compared to creating one. We prefer that users add citations to any new information, but outside of FAs, we don't really enforce it. An edit wizard is arguably riskier too. We have hard evidence that users who contribute to other articles before (or instead of) creating new ones are more successful and more likely to become long-term users (which most of the arguments against completely ignore in favor of speculation and anecdotal evidence). An edit wizard is essentially a completely untested idea. Given that the main proposal here has around 75% community support I don't see why we should rule it out as entirely infeasible. Mr.Z-man 20:33, 16 April 2011 (UTC)

(See also my previous comment - addendum to the last.) How about 24h/5e? As previously stated, I believe it's the 4 day wait most of the opposers were unhappy with. Also, as you know, I see the 24 hr marker as useful for future measures. RedactionalOne (talk) 21:09, 16 April 2011 (UTC)

5 edits would be better (though I'm not sure what you're basing your opinion on for what opposers are unhappy with, most don't seem to specify). My main opposition is to the edit wizard. I think that in the best case scenario, its unnecessary and in the worst case, unhelpful. If we're going to do a trial, we should have as few variables as possible. If we put in the edit wizard and a restriction on article creation, it will make interpreting the results of a trial much more difficult. Mr.Z-man 22:08, 16 April 2011 (UTC)

OK, I'll update the proposal (not right now). Re the 4 day wait being the primary objection from those strongly against the original proposal, I got that impression from the comments on this page, and BarkingFish said so explicitly (on a comment on my talk page). I agree that reducing variables is helpful for interpreting results. I think the Edit wizard will take quite a while to get right - and it shouldn't be offered until it is. Therefore, it's unlikely to be in place by the time of evaluation. If we go with 24h/5e, I think there'll be less insistence on a trial and revert plan. For this change (which won't impact most new users) it seems nonsensical to evaluate after reverting the policy. How long do you think would be needed for useful data - a couple of months? If we had a 3 month trial we could evaluate during the third month. All being well, if the trial was held to be successful it could simply be kept in place.

It would be very useful to know by what route each relevant user started their first article before and during this trial: Wizard, option 1, 2 or 3, AfC (not via wizard) or direct. Is this at all feasible? We could, for instance, expect to see far more successful articles when drafted on user page than added with 'Go live', but without the data this is mere speculation. Perhaps an easier stat to wrangle would be length of time in days from creation until live. Both drafted and AfCd would take longer but presumably have a far greater chance of success. RedactionalOne (talk) 15:27, 17 April 2011 (UTC)

A summary of my waffle below:

• We risk breaking a core principle by setting poorly tailored restrictions
• Our biggest challenges lie, I believe, with edits, not new article creation
• This proposal mitigates new article issues and lays groundwork for addressing editing issues
• This proposal is far less divisive than the 4 day / 10 edit option
• Analysing page deletion logs is useful for getting a handle on the issues
• What meets the ‘notable’ requirements will change over time based on usage

History2007, I’m not sure extending the limit to 4 days / 10 edits would significantly address that problem. Also, ‘too many articles’ doesn’t strike me as the big problem Wikipedia faces. Defacement and information content, neutrality and quality on medium/high traffic articles seem like the biggies.

I had a good look through the deleted pages log; a decision process had resulted in the removal of HelpingIsEasy.org. Now I dare say all reasonable care was taken to correctly interpret the ‘notable’ requirement. But in terms of the person putting that page up, they would have jumped through whatever hoops were there, believing it notable. The wizard (included in the proposal but not currently required for the first article) would have been the best way of convincing them otherwise, but might not have managed to.

The question of whether Wikipedia is a better place without that page (on what appears to be quite an influential charity in the NY area, with various web sites pointing to theirs) is an interesting one. An article’s existence on Wikipedia does not, I would argue, negatively impact the site as long as the search algorithm doesn’t give it undue weight and it meets certain standards of quality and relevance to people who would seek that quality information from us. What determines that is inevitably partly subjective, and is going to change over time depending on who uses Wikipedia for what. For instance, tech heads use us a lot, and there are detailed articles on obscure 80s computer games. This is deemed fine because a lot of editors are tech heads. In other areas things get more murky.

The log also reveals various overly promotional pages which, again, are not likely to be addressed by any reasonable measure, as well as some abusive ones. But the main defacement problem is with existing pages, and my proposal has a built in capability for planning future measures for addressing that which would still have some chance of gaining consensus – clearly, if the original proposal of 4 days / 10 edits to create first article is this divisive this would be likely to extend to future editing restrictions along similar lines.

Core Wikipedia principal #2 states that “...any measures instituted for security must address a compelling community interest, and must be narrowly tailored to achieve that objective and no other.” In this sense, I believe my proposal is a significant improvement on the original one. It could significantly reduce abuse, significantly reduce ‘deletion frustration’ and increase new user retention. No algorithm exits for deciding notability, and this is going to remain in the hands of the community, which is probably as it should be.

RedactionalOne (talk) 14:40, 13 April 2011 (UTC)

User:Samantha.pia I have no idea why I have been invited to this, as a new user I am still finding my way around and really don't qualify for this deep heavy stuff. Samantha.pia (talk) 11:26, 19 April 2011 (UTC)

Proposal (revised): 24hr / 5 edit requirement for first article

Following further research and discussion (see above), the 24hr / 2 edit / wizard proposal has been amended to a 24hr / 5 edit one. This simplified proposal involves:

• Setting up a new system user right enabled when the account is at least 24 hrs old and 5+ mainspace edits have been recorded
• Making the Article wizard the most discoverable method for starting first article, by modifying applicable articles and welcome templates

Rationale

• Consensus

The proposal for using autoconfirmed status (4 days / 10 edits) seemed to gain about 75% support, but there were strong objections from a vocal minority, who were concerned that some of those signing up in order to contribute an article (perhaps after years of IP edits) would feel disenfranchised. For this reason, consensus did not appear to be achieved.

• Core principals

Wikipedia is fundamentally against hindering openness, particularly to contributions from newcomers – and any such measures proposed will be subject to ‘strict scrutiny’. The Article wizard conforms to this principal, because it explains the standards, gives the user the option of drafting first and warns that unsuitable articles posted immediately could be quickly deleted. In the case of 4 days / 10 edits, the case is less clear.

The 24 hr / 5 edit alternative (this proposal) sets a 24 hr minimum account age primarily as an anti-vandalism measure. Its 5 edit condition combines anti-vandalism and editing experience aspects. However, it is the Article wizard process, which runs the new editor through notability, sources, quality, neutral point of view, etc., that is the primary gatekeeper for the new article. The new user could ignore all of that and post anyway, but then they could do the same at 4 days.

• The right balance

Being made to jump through hoops is a frustrating process. Frustration leads to anger. Anger leads to erratic thought, which can negatively impact research skills, openness to policies, attention to detail, neutrality – in short, an angry editor is likely to produce a poorer article. When that’s deleted they’re likely to become disillusioned. This is not the welcome we’re striving for. 4 days / 10 edits was chosen because it existed, not because it was the most suitable.

Further advantages of 24 hrs / 5 edits

• Better first articles – Article wizard helps with suitability and offers an option to draft article in user area, giving time to hone
• Less pressure on New Page Patrollers – new articles more suitable and honed
• Less pressure on Articles for Creation – a significant number will chose the wizard’s draft option
• Less disenfranchisement – wizard explains requirements for a successful article; this good communication mitigates deletion frustration
• Provides a more reasonable restriction on creating redirects
• By not coupling article creation with autoconfirm status, the requirements for being autoconfirmed could be increased if there was future consensus for such a change

Related developments

• The 24 hr / 5 edit user right could be key in future anti-vandalism measures – outline discussions have been for this as a requirement for major edits such as blanking, wholesale rewrites and use of the ‘file’ tag (further discussion required)
• A new Edit wizard could get signups up to speed quickly on this important skill, in the same way the Article wizard does for article creation – this could offer a selection of articles tagged for editing on its completion page, assisting in article cleanup and helping new users achieve their 5 edits (further work/discussion required)

Implementation A trial and revert model seems like an unnecessary complication. If there is to be a trial it would be better for evaluation to take place while it’s in place: for instance, a 3 month trial where data analysis and discussion begins at 2 months. If there’s consensus that the trial has been successful, the revised policy can then remain in place at the end of the 3 months.

Users endorsing this view

RedactionalOne (talk) 10:57, 20 April 2011 (UTC) (proposer)

Related proposal for article wizard extension

There is a related proposal at Wikipedia:Village pump (proposals)#Article wizard extension for requesting an article wizard extension. That is independent of this discussion, it doesn't imply any restriction. Cenarium (talk) 13:01, 13 April 2011 (UTC)

I agree with the auto confirmed status requirement but the other proposals here are just too much baggage, Wiki should remain as light and changeable as more or less it is now with a few fine tunings, like the one in this query. Msrafiq (talk) 13:46, 16 April 2011 (UTC)

Questions to be answered by a trial

I said elsewhere that smart people don't try to design a trial without knowing what they're trying to learn from it. This is a place to list questions that you would like to have answered.

Listing the question does not guarantee that any trial will happen or that any trial that might happen would answer your question. However, if we first identify the questions, we're more likely to run a trial (1) only if we need to and (2) that actually answers some questions.

I'll start with a list of the questions that are on my mind. Some of these, I think would be pretty easy to measure, and others I'm not sure we could manage (unless you're willing to spend 100 hours doing tedious manual reviews). Please add your own questions, or improve mine. WhatamIdoing (talk) 06:06, 24 April 2011 (UTC)

Questions about effects on new users

• Registrations: Does the number of users registering while autoconfirmed is required change? (Do fewer people register in the first place, since more work is required to create an article?)
• Short Retention: Does the number (proportion?) of accounts reaching autoconfirmed status change? (Do more people make ten edits?)
• Long Retention: Does the proportion of new users who are still active 30, 60, 90, 180 days after account creation change? (Are we retaining more of our new editors?)
• Learning Curve: Does the typical length of time that it takes accounts to reach autoconfirmed status change? (Do people make those ten edits much quicker?)
• Multiple Accounts: Are users less likely to switch accounts frequently (e.g., creating a different account every week, rather than trying to remember the previous user name)?

Questions about effects on encyclopedia articles

• Article Creation: Does the number of articles being created (by anyone, by new users) change?
• Article Deletion: Does the number (proportion?) of articles being deleted through CSD, PROD, or AFD change? (Articles created by anyone, by newer users?)
• Article Retention: Does the number (proportion?) of articles surviving the first month after their creation change?
• Vandalism: Does the amount of vandalism or good-faith-but-unhelpful edits in existing articles increase (e.g., as inexperienced folks make the ten edits required to become autoconfirmed)?

Questions about effects on other parts of Wikipedia

• Did you know...: Does the change affect WP:DYK (e.g., fewer new articles, therefore fewer DYK candidates)?
• Article creation requests: Does WP:Articles for creation drown in new requests? Are editors taken away from other areas to help with AFC requests?
• Patrolled new pages: Does WP:New page patrol see a difference in the number (quality?) of articles needing to be patrolled?

Questions about trial-related effects

• If we run a time-limited trial, does it depress activity in future months (e.g., people hear in "July" that newbies are not allowed to create new articles, and thus don't attempt to start an article in "August", when it is no longer the case)?
• If we run a time-limited trial, does pent-up demand during the intervention result in a spike in article creation immediately afterwards (e.g., all the new accounts who can't create articles during "July" [or whenever the intervention is] come back in "August" to create new articles)?

Discussion on trial questions

Many of the above questions could provide interesting data, but I think we should differentiate between that and the process of deciding whether any trial was successful. I would suggest that that should be based on as simple a set of criteria as possible. What came to mind when I pondered this was the following:

An indication of successful policy improvement would be an increase in retention rate for new (or newly confirmed) users creating an article and a reduction in first article deletion rate.

Of course, the significance and format of a trial are largely dependent on what's being trialled. A change to 24hrs / 5 edits would be instigating a fundamental anti-vandalism measure and a modest edit requirement. Because vandalism negatively impacts the encyclopaedia for readers, editors and administrators, it is hard to argue how such a measure would not have an overall positive effect (although this should still be monitored, of course). It is a benefit of setting such a specifically-tailored, dual-purpose threshold that the change becomes less controversial and a trial less critical.

The Article wizard is already the most discoverable method of creating articles, but we do not seem to have data on article creation method and how this influences article success and user retention. Mr.Z-man seems uninterested in providing that data, so we should probably look for another source.

RedactionalOne (talk) 09:40, 25 April 2011 (UTC)

Yes, I agree: If the change to AUTOCONFIRM is done on a temporary/provisional basis, then we should have some idea, agreed in advance, of what constitutes a good reason for turning it back on/keeping it turned on. The data we collect should be related to this decision. WhatamIdoing (talk) 19:49, 27 June 2011 (UTC)