Wikipedia

Wikipedia:Village pump (proposals)/Archive 107

< Wikipedia:Village pump (proposals)
Latest comment: 10 years ago by Xagg in topic Edit history of a selected area
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Noticeboard for protected talk pages

Latest comment: 10 years ago5 comments4 people in discussion

A non-negligible number of active talk pages are semi-protected, list in ms (I'll focus on mainspace). There exists no good way for non-autoconfirmed users to discuss those pages. At most there is WP:RFED at WP:RFPP which allows to make edit requests, but it's isn't adapted for discussion (fast archiving, position, etc), and it is seldom linked from semi-protected talk pages. To address this issue, I think we at least need a special protection template displayed in full mode explaining the situation and providing options for users. Furthermore, a centralized noticeboard to allow non-autoconfirmed users to both discuss articles and request edits would be helpful. One may argue that it may transfer the problems for which the talk page was protected, but a number of those would not easily transfer to a centralized page - spam for example, and it's still particularly important to provide an opportunity for non-autoconfirmed users to discuss those articles, whether the corresponding article is semi-protected (most of the time) or not. So that's what I'd propose, as the status quo is unsatisfactory, or maybe you have alternatives. Cenarium (talk) 20:47, 9 November 2013 (UTC)

For reference, here is a list of mainspace talk pages (excluding mainspace subpage talk pages -- for example, /Archive1 and such). 43 indefinite semi-protected talk pages, 47 non-indefinite semi-protected.
Protected mainspace talk pages

Indef semi (43)

Semi set to expire (47)

Theopolisme (talk) 01:01, 13 November 2013 (UTC)

Some articles that are unprotected, or only under pending changes protection (PC1), have their talk pages protected, allowing editing but not discussion. Most of these could be unprotected. List:
Unprotected (or only PC1-protected) articles with indefinitely protected talk pages
Talk pages were protected when the articles were already protected, most have probably just been forgotten:
Other talk pages were protected separately, but related to temporary article protection which had expired:
  • Causes of autism (article had been protected, talk page protected separately, but related disruptive editing on article seems to have stopped)
  • Huizhou University (The article had been protected during a dispute, and the reason for talk page protection is probably related. Since article protection expired, there have only been minor edits to the article, and editors involved in dispute have been inactive.)
One talk page was protected for a reason unrelated to article protection:
  • VBulletin (spambot target, but possibly insufficient activity to justify protection)
Other unprotected (or only PC1-protected) articles with protected talk pages
Related to expired protection of article:
"Spambot target":
"Sock puppetry":
IP disruption, maybe try edit filter on the Apollo and Chadli Bendjedid articles if it continues:
Peter James (talk) 13:36, 17 November 2013 (UTC)
Talk:John Prescott was protected by Jimbo Wales. עוד מישהו Od Mishehu 16:41, 17 November 2013 (UTC)
It looks like an ordinary protection, no indication that it was intended as anything else. Peter James (talk) 17:57, 17 November 2013 (UTC)

"Editor Desk"

Latest comment: 10 years ago1 comment1 person in discussion

Function

For users that help Wikipedia by improving articles that have severe and noticeable problems. The "Editor Desk" can involve more things than just changing some words.

Requirements

For the "Editor Desk" to work by itself, it would require Wikipedia pages to include a button that allows readers to report articles that are either misleading, contain poor grammar, or other issues that would help Wikipedia greatly if resolved.

Possible Outcomes

The main outcome that would result from this would be more "community" involvement with the improvement of Wikipedia without having to exhaust Wikipedia's (and/or Wiki media's) resources with articles and allows those resources to be put to use for more pressing issues or "projects".— Preceding unsigned comment added by Alternate-Minds (talk • contribs) 19:12, 11 November 2013‎

We already have a lot of noticeboards for coordinating on specific problems, such as WP:RSN and WP:BLPN. I am personally of the opinion that we already have too many such pages, in fact several of them have just been closed, so I am pretty skeptical about this fairly vague proposal. Beeblebrox (talk) 21:20, 15 November 2013 (UTC)

Enforce American or British spelling

Latest comment: 10 years ago11 comments10 people in discussion

I saw the perrenial proposal Enforce American or British spelling. I think there's a compromise that will satisfy the people who want to enforce it and the people who don't. Wikipedia could have a clickable link that brings you to a web page with a list of American and British spelling and circle boxes to the left of both members of the list to click the box of which ever verson of Englissh you want to use. The instant that feature is added, both the British version and American version of each article should be identical and after somebody makes an edit to an article, there should be 2 kinds of edit: the old method of editing which does the same edit to both versions of the article all at once and the other specialized method of editing for editing only the version of the article you're using. The second method of editing should only be used to fix spelling and grammar, not to fix the way the material in the article is organized. The French version of Wikipedia should have an option of using either of 2 types of french, one for Quebec and one for France. The proposal for enforcing a certain version of a language is a higher priority for French than English because the 2 versions of French are more different from each other. Blackbombchu (talk) 01:23, 13 November 2013 (UTC)

British and American English are not the only forms of English. There's New Zealand English, Australian English, Canadian English, Indian English, Jamaican English, South African English, Hiberno-English and more. That would rather complicate things. Neljack (talk) 07:05, 13 November 2013 (UTC)
You're also missing out on International English, and all the regional varieties of American, Canadian, British, and Australian English, which oftentimes differ in some grammatical constructs, as well as in vocabulary. VanIsaacWS Vexcontribs 07:16, 13 November 2013 (UTC)
I prefer Oxford spelling myself—the only convention that is hated equally by Americans and Britons :) Kaldari (talk) 07:35, 13 November 2013 (UTC)
Personally I'm a big fan of Indian English, which gave us the wonderful phrase "to do the needful". I tend to use it at work when people ask me what my job is. Ironholds (talk) 04:02, 14 November 2013 (UTC)
I personally think it could all be solved by adopting Canadian English, which incorporates the better parts of both British and American English.  ;) Resolute 14:51, 14 November 2013 (UTC)
Lojban to the rescue! --Stephan Schulz (talk) 15:14, 14 November 2013 (UTC)
Sorry, Lojban is far too ambiguous and imprecise. It's Ithkuil or nothing! VanIsaacWS Vexcontribs 16:24, 14 November 2013 (UTC)
And how would you deal with quoted text from another variation of English? Josh Parris 06:04, 15 November 2013 (UTC)
  • I'm not sure I even understand exactly what is being proposed here, the initial post is a bit unclear. However, where any idea like this breaks down is easy to see: take the word "lift". Let's say a user who prefers British English uses this word. They could be talking about lifting up an object, or they could be talking about what Americans call an elevator. No bot or automated process that we currently have is going to be smart enough to know which is meant. Beeblebrox (talk) 21:57, 15 November 2013 (UTC)
  • separated by a common language, yet again, and letting it waste our time. If as an American I want to call a commercial truck a lorry and some bloviating dickweed looks at me in bemused puzzlement, they're at fault for being an uncultured boob and presumptuously boorish for expecting me to reduce my knowledge to his low and regrettably all-too-common denominator of jingoistic unsophistication. One time I used the word "discomfited" and was accused of speaking slang by someone who thought paella was a south pacific fruit. I'd rather we reduce every article to Gullah English or Pitcairn Pidgin.--ColonelHenry (talk) 17:25, 17 November 2013 (UTC)

Disambiguation Day

Latest comment: 10 years ago2 comments2 people in discussion

I propose to officially declare December 15 of this year, and annually thereafter (or maybe just the third Sunday of every December thereafter), to be Disambiguation Day, to be marked by a 24-hour disambiguation link-fixing contest (and whatever other fun disambiguation-related editing contests and activities we can come up with). In furtherance of this proposal, I will personally pledge a $20 Amazon gift card to the editor who makes the most disambiguation fixes on that day. Cheers! bd2412 T 21:09, 15 November 2013 (UTC)

Input requested at WT:RFPP

Latest comment: 10 years ago1 comment1 person in discussion

Please comment at WT:RFPP#Mass protection lowering from "sysop" to "editprotected". Thanks. Anomie⚔ 15:59, 16 November 2013 (UTC)

Hey Wikipedians,

I've just thought of a nice tweak to the Wikipedia experience. When one examines a list of albums of a certain musical artist, why not have the track listing pop up over the link of an album?

The reasoning behind it here is that I sometimes like to place a certain track (that does not have a separate article on Wikipedia) in context of place and time, and I normally have to open articles for each album, until I find the song.

Cheers

Upload audio in french lessons

Latest comment: 10 years ago1 comment1 person in discussion

Hi there,

Is it possible to upload audio in "French lessons" to help me with the pronunciation?

Thank you,

Manon

Not very many articles have audio, which like everything else's round here is only done if someone feels compelled to make the effort. In any event we do not appear to have an article titled French lessons. Beeblebrox (talk) 03:07, 21 November 2013 (UTC)

Javascript problem

Latest comment: 10 years ago3 comments2 people in discussion

Can anyone please make a new, updated version of User:Pyrospirit/metadata/assesslinks.js, it kind of stopped working since the MediaWiki update in 2011. Pyrospirit is inactive since 2011. Thank you. PORTALandPORTAL2rocks 12:07, 16 November 2013 (UTC)

A common type of slightly wrong name access attempt

Latest comment: 10 years ago9 comments7 people in discussion
  • Today's edition of User:West.andrew.g/Popular redlinks (this edit) has 787 entries, and about 75% or more of them seem to be names of existing pages with 'm' or 'n' or occasionally 'p' appended, likely caused by something mishandling a control character or suchlike. Each of those names was attempted to be accessed 1000 or more times in a week. It would be useful if, if an attempt is made to access a nonexistent page named Xm or Xn or Xp, and page X exists, the "this page does not exist" display should ask "Were you looking for page X?". Anthony Appleyard (talk) 09:28, 17 November 2013 (UTC)
I think it would be good to query on any request for a non-existent page that differs by only one character from an existent page. Out of curiosity: why should 'm', 'n', and 'p' show up so often? The 'n' could be a malformed newline chr, but the others? ~ J. Johnson (JJ) (talk) 22:05, 17 November 2013 (UTC)
That's assuming that these requests were from humans, not a broken web crawler or something. Mr.Z-man 22:21, 17 November 2013 (UTC)
Bad interwiki? Josh Parris 22:07, 18 November 2013 (UTC)
I could imagine that being the case if it was at the beginning, but not at the end. Sven Manguard Wha? 04:15, 21 November 2013 (UTC)
Considering the positions of the characters on QWERTY and AZERTY keyboards, the distribution isn't random - they tend to be at the right end of a row of letters - so I think it's plausible that these would be typos made by human beings, who move their right hand back at the end of a word... bobrayner (talk) 14:26, 21 November 2013 (UTC)
Moving their hand back to hit the "Enter" key? Hmm. I was wondering if .the 'm' and 'n' cases might be malformed ctrl-m (carriage return) or ctrl-n (newline) characters. ~ J. Johnson (JJ) (talk) 00:07, 22 November 2013 (UTC)
Except that newline is control-j, control-n is the "shift out" control code and control-p is the "data link escape" code. --Carnildo (talk) 02:20, 22 November 2013 (UTC)
I'm actually mixing ctrl chrs with C escape codes. E.g.: C's "\n", "newline" in some contexts, is actually ASCII "LF" (line feed) = "^J" = "\0A". C's "\r" is ASCII "CR" (carriage return), which is also a newline in other contexts. (See ASCII#ASCII control code chart.) That these extraneous characters show up at the end of the string makes me wonder if they might be malformed "newline" characters. ~ J. Johnson (JJ) (talk) 22:46, 22 November 2013 (UTC)

Merge articles to be regulated

Latest comment: 10 years ago14 comments10 people in discussion

Hi All! WP:MERGE proposals of articles, i feel, are quite the neglected of maintenance tasks on Wikipedia. Editors put on merge tags and start discussions and later on without any quorum to reach conclusion, the mergers remain incomplete. Many merger proposals have not been visited by editors other than proposer. At times new editors have tagged articles but have not even started discussions. We have in Category:Monthly clean up category (Articles to be merged) counter articles with merge tags dated back to May 2010. These needs to be regulated.
(a) These articles need to be brought to attention of editors so they get the necessary discussion. We could highlight these articles in respective WikiProject's article alert lists.
(b) A time limit needs to be set for discussions to conclude. And then a closure needs to be done by admin/non-admin. (Lets encourage non-admins to do this more if admins are over burdened with other tasks. Or maybe there are other category of editors also out there who could do this.) A relisting could also be done. In case of no consensus, we can close such discussion without any action. That would at least get rid of that merge tag from top of the articles.
I know that even after discussion closure, we might simply end up flooding a category, like Category:Articles to be merged after an Articles for deletion discussion is with no actual mergers happening. But we at least are a step ahead. And there is good probability that the editor who proposed merger would merge the article than the editor who proposed to get it deleted but is stuck with a merge result post AfD. Suggestions welcome. §§Dharmadhyaksha§§ {T/C} 17:54, 19 November 2013 (UTC)

  • I wholeheartedly support any effort to inspire more attention to the merge backlog, and I note that there has already been a determination of consensus in favor of creating a WP:RM-like space for merge requests, which just has not yet been implemented. bd2412 T 18:33, 19 November 2013 (UTC)
  • Perhaps a more useful thing would be to change the guideline to explicitly say something like "If you've tagged both articles and started a discussion, and nobody has opposed it within 30 days, then you can WP:BOLDly merge the pages." The main problem with the merge backlog is that the people who are tagging the articles don't actually want to do boring and sometimes difficult work of actually merging the pages. WhatamIdoing (talk) 18:36, 19 November 2013 (UTC)
  • As WhatamIdoing suggests, the principal difficulty is with the second half of your part (b). Some merges, if done properly, may require significant amounts of time and effort. As a volunteer-driven project, we don't have any mechanism to force people to perform this particular editing task. I generally approve of any efforts that might be made to increase awareness of this issue and to encourage people to take on some of these tasks, though I would be very wary of unintended consequences which could attach to applying any sort of 'hard' deadlines to the merge process. TenOfAllTrades(talk) 18:44, 19 November 2013 (UTC)
  • Comment. Unfortunately (especially in regards to the two main merge backlogs: Articles to be merged after an AfD discussion and Pending Mergers), the work required to do the actual merging usually requires extensive copy-editing skills, grammar fluency, and a working knowledge of the many templates/boxes/categories one encounters across the myriad articles found here. That scares off many editors from actually doing the work they themselves have requested. Merging can be drudgery, believe me.
I would like to see some method developed to aid the few of us who engage willingly in this task, but it seems many editors are willing to tag/request the mergers, but few will: 1) Boldly move forward with the task, or 2) complete their merge even when a consensus discussion has been held and the decision is to do so. The fix that WhatamIdoing mentions above is, in practice, allowed now. However, very few merges by requester actually occur. Consequently, every month another bunch of proposed mergers slips into the "Approved: proposer should complete the merger" abyss, not to be seen for the two-plus years it currently takes to hit the back-end of the merger backlog. Then it falls on us few actively working mergists to do them. So, in response to your first point, these requests do have the attention of those of us actively involved with merging, we simply need more bodies willing to do the work.
To address your other point, Dharmadhyaksha, I am not an admin, but have been closing most of the discussions (when they do take place) for about a year now, but those are only the ones we are aware of at the Merger Noticeboard. Quite frankly, most proposal discussions find little activity or actual discussion these days.
Finally, I'm all for a "If nobody objects, then boldly move forward" approach to merge requests. If that could become policy, I'd absolutely support it. GenQuest "Talk to Me" 06:11, 20 November 2013 (UTC)
Perhaps we need to be a bit clearer:
  • If you propose a merge, and nobody objects within 30 days, then you or any other interested editor may WP:BOLDly perform the merger at any time.
  • If you see a merge proposal that is older than 30 days, and nobody has objected, and you personally believe the merge is appropriate, then you may WP:BOLDly perform the merger whenever you want.
  • There is no required 30-day discussion period. If a consensus in favor of the merger is formed in less than 30 days, then anyone may perform the merger whenever they want. If the proposal is obvious (e.g., the mistaken creation of a second page for the same subject under a slightly different name), then a discussion need not even be held.
  • Merges do not need to be approved by an admin. If the discussion is contentious, however, you can post it at WP:Proposed mergers to get some help.
  • If a page gets merged, and someone later objects, then a new discussion can be held. Mergers can be easily reversed if a consensus against the merge is formed shortly after the merge was performed.
Is there anything else we could say to make this clearer? WhatamIdoing (talk) 17:41, 20 November 2013 (UTC)
Looks good to me. Can we also start highlighting merge discussion on article alert pages, for example Wikipedia:WikiProject India/Article alerts? §§Dharmadhyaksha§§ {T/C} 04:23, 21 November 2013 (UTC)
Not sure this is actually any different than our current guidelines and procedures. How is this different than what has been established through Wikipedia:WikiProject Merge?--Mark Miller (talk) 09:22, 22 November 2013 (UTC)
It would be much better if the tags for merge were to be moved onto the talk pages and it process was under bot control as it is with WP:RM. If bots are going to place templates it is better that is done on the talk page. At the moment if someone objects to a merge template in article space they are likely as not remove them. This is less likely to happen on talk pages. The last thing we need is a bot and a human in a revert war in article space. I have not been following this recently so I am not sure how far user:Wbm1058 got with automation of the process (see here). -- PBS (talk) 11:39, 22 November 2013 (UTC)
I think the reasoning behind putting the merge tags on articles is that we want readers to know about the other article(s). In that sense, merge tags play a second role as another form of "see also" tags. Whereas, there is no consensus that readers need to be informed of article titling discussions (except perhaps after they've been appealed at Wikipedia:Move review). Sorry, I've "swapped out" my project merge work for now, but do intend to get back to it. I started working on a more comprehensive analysis, from which I hope some meaningful incremental improvements will emerge. For a peek at my approach, look here. Meanwhile, some speechmaking:
  • There is a good point in keeping the merge tag on the article page so readers are aware of it. Also, editors are more likely to reach article rather than article talks while surfing here and there. But as merge tag add a category to the article page, similar category can be added simultaneously on the article talk page. That we can keep check on discussions. Also, many times new editors propose merging but fail to actually start the merger discussion. Such flaws could be avoided if talk pages were in control loop also. §§Dharmadhyaksha§§ {T/C} 09:46, 25 November 2013 (UTC)
  • I think that this is a problem that WP:Flow will eventually solve. It's supposed to be possible to build a basic procedure in Flow, so you can tell Flow that you want to merge these two articles, and the discussion would immediately be started and automagically listed in all the correct places (and maybe the articles tagged, too?). It's a bit like a super-Twinkle for discussion-oriented work. User:Quiddity (WMF) can tell us whether I've got the idea right. WhatamIdoing (talk) 17:14, 25 November 2013 (UTC)
  • That is exactly the idea that Flow is aiming for. They're working on just the core user-to-user discussion system to begin with, to make sure that the architecture is sound, secure, and scalable. They want to get that "right" (ie. something we can and want to use) first. In future months (I'd guess 6+ months from now?) the workflow-systems will become the focus. (That's the ultra-brief version, to avoid tangenting this thread! If you have further Flow questions, WT:Flow would be best.) –Quiddity (WMF) (talk) 17:22, 25 November 2013 (UTC)

Proper Naming of a Country

Latest comment: 10 years ago3 comments3 people in discussion

To Whom It May Concern;

I am sending this message because I know there are many places where this needs to be changed.

The new and proper name of the African Country known to many as the (Ivory Coast) no longer wants to be known by that name. The wish to be known by their name in the French language as (Côte d’Ivoire). Just the same as we knew it first as East Timor is wishes to be known as Timor-Leste when that took place.

True that maybe the translation from French to English but officially it is not. Just wanted to bring that to the attention and hopefully all this can change when you have the time.

Sincerely yours;

Mr. Jazz J. Salcedo — Preceding unsigned comment added by 76.110.149.128 (talk) 14:22, 24 November 2013 (UTC)

The naming of that article has been discussed many times in the past; see the box near the top of Talk:Ivory Coast for a list of links to several past discussions. Anomie⚔ 14:32, 24 November 2013 (UTC)
You don't always get what you want. North Korea wants to be known as "Democratic People's Republic of Korea" (or just "Korea" with an implication that they also own South Korea). This is the English Wikipedia and we usually prefer the common English name which makes it easier for our readers to know what we talk about. PrimeHunter (talk) 01:29, 26 November 2013 (UTC)

Title of the article Padel Tennis should be changed

Latest comment: 10 years ago1 comment1 person in discussion

The Wikipedia Article Padel tennis may cause confusion. The sport referred in this article is called only Padel according UK Padel Federation. After reading this article of the UK Padel Federation http://www.padelfederation.co.uk/?page_id=500 is evident that the word "PADEL" is the only word is going to be use for call this sport.

There is a different sport called Paddle Tennis and phonetically can be confusing.

Thank you.


P.S: Sorry. I don't know why this proposal has been posted 4 times.— Preceding unsigned comment added by AntoWikiWriter (talk • contribs) 11:45, 25 November 2013‎

I get about 338,000 Google hits on "Padel tennis" so it's certainly wrong that "Padel" is the only used name. See Wikipedia:Requested moves for how to suggest a move (page rename). Note there is already a page at Padel so if you want to use that title for the sport then you would need another name like Padel (disambiguation) for the current content of Padel. Another option would be to keep Padel and name the sport article Padel (sport). PrimeHunter (talk) 01:18, 26 November 2013 (UTC)

WMF should officially request Google to restore Wikipedia layer in Google maps, and request OSM to add such a feature

Latest comment: 10 years ago2 comments2 people in discussion

Wikipedia layer in Google Map was a useful feature (positively reviewed in lifehacker ([1]) and other places on the web) that Google discontinued earlier that year. There's currently no good replacement for it. Some links for background information: Wikimedia-l discussion, Google devs claim low usage (also here) but Google forums discussions (particularly [2]) show that quite a few individuals found that useful in the past, as noted on many websites ([3]). It would be nice if WMF could officially ask Google about it, and discuss any reply in a blog post; even if Google doesn't bother to reply, it would be a good PR move, clarifying to the world that it's not WMF's fault this useful tool is gone. It would also be nice to get a report on WMF partnership (or lack of it) with OSM. Pinging User:Kolossos (and please ping any other parties that may be interested). --Piotr Konieczny aka Prokonsul Piotrus| reply here 03:54, 26 November 2013 (UTC)

Philippe might be a good person to get involved here. Killiondude (talk) 06:32, 26 November 2013 (UTC)

Make SidebarTranslate into a gadget

Latest comment: 10 years ago19 comments17 people in discussion
There is a clear consensus to add the SidebarTranslate script to the Gadgets. Armbrust The Homunculus 15:18, 26 November 2013 (UTC)

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

 
Screenshot

SidebarTranslate has been around for a long time as a popular user script, and it's often been suggested that it become a gadget. SidebarTranslate makes interwiki language links display in English, instead of displaying in their respective languages. For example, Chinese displays as the English word "Chinese", instead of as "汉语".

The original script/concept was by User:Tra, and it's been modified over the years by several people. I copied it to my userspace some time ago to fix some things, and just completed a total overhaul that updated the code to use jQuery, improved performance, added an auto-sort feature so languages are ordered alphabetically by their English names, and made all current and future languages automatically supported (viable due to WikiData and suggested by User:Edokter).

SidebarTranslate currently has roughly 90 users (based only on backlinks to my version and Tra's original -- there are likely more actual users), which is rather high for a user script. Realizing the arguments to keep the default as-is, this tweak will be useful to enough people that it makes sense as an opt-in gadget. I would imagine it's the ideal display for nearly all primary English speakers. equazcion → 10:31, 8 Nov 2013 (UTC)

Well, I'd support this. Rcsprinter (post) @ 16:10, 8 November 2013 (UTC)
I think I saw something related to interwikis among the upcoming Beta Features. Isn't this something that could be proposed there? --Elitre (talk) 16:22, 8 November 2013 (UTC)
Don't care where they propose it, count me as a Support. Peridon (talk) 18:48, 8 November 2013 (UTC)
@Elitre: Yup, see mw:Universal Language Selector/Design/Interlanguage links (Note that is an entirely unrelated redesign of the ULS system, to re-order the long lists into something potentially more useful). I'll ping the designer/developers working on that, about this, just so that they're aware. (Done, here). (side note: Nobody has suggested it yet, afaik, but to preemptively answer: We probably couldn't make this gadget default-on for all users, as it directly endorses a single translation service (there are wonderful built in links that lead to GoogleTranslate) - but it's perfect as an opt-in choice.) –Quiddity (talk) 20:55, 9 November 2013 (UTC)
I support, though I'd suggest using something different then a dotted circle for the translate link, a double arrow perhaps or translate icon. Also, addOnloadHook() is pretty outdated as well; use $(document).ready() instead. — Edokter (talk) — 22:37, 8 November 2013 (UTC)
Made the coding tweak and working on the icon -- moved exchange about this to User talk:Equazcion/SidebarTranslate. equazcion → 11:03, 9 Nov 2013 (UTC)
  • Support. I would have installed this long ago if I had known it existed :) Kaldari (talk) 06:23, 9 November 2013 (UTC)
  • I've faced this particular issue quite often. If only I'd known that this script existed. Support TheOriginalSoni (talk) 12:31, 9 November 2013 (UTC)
  • Support - I've used this for a few months, and adore it. –Quiddity (talk) 20:55, 9 November 2013 (UTC)
  • Support. I actually think it should be the default but that's another discussion. I've used the script since January 2009 and had many instances before I added it where I had to fumble around to figure out which language was which when I needed to know. By the way, if anyone who programs the script is watching, it fails to translate Serbian, Serbo-Croatian, Sorani, Bashkir, Belarusian (Taraškievica), Ossetian, Bishnupriya Manipuri, Anglo-Saxon, Acehnese, Zulu, Kurdish, Hill Mari, Norwegian (Bokmål), Norwegian (Nynorsk), Western Panjabi, Sanskrit, Tatar, Uyghur, Kabardian Circassian, Emilian-Romagnol, Hakka, Lezgian, Latgalian, Mingrelian, Mazandarani, Mirandese, Dutch Low Saxon, North Frisian, Meadow Mari, Uzbek, Palatinate German, Komi-Permyak, Rusyn, Northern Sotho, Sranan, Zhuang and Vepsian. That was a bigger project than I expected and I may have missed a few.--Fuhghettaboutit (talk) 15:53, 10 November 2013 (UTC)
    • The translation issue is because you're using User:Tra's original script rather than the current one. It might be time to redirect it, since Tra hasn't been active here in a while, the current script is much improved, and something like 50 people still have the old one installed. If you want to update your installation in the meantime, remove Tra's script from your monobook.js and follow the instructions at User:Equazcion/SidebarTranslate. equazcion → 18:51, 10 Nov 2013 (UTC)
@Equazcion: Ah, thanks, I've switched. Please note that your newer script (much appreciated; love the Google translate feature) is missing translations for Belarusian, Venetian, Tarantino, Lombard, Lak and Buryat (Russia).--Fuhghettaboutit (talk) 04:36, 11 November 2013 (UTC)
You're welcome :) My script doesn't have a list of translations like the old one did -- It rather uses WikiData's reported language names. It's possible some haven't been translated there into English yet, although Belarusian, for example, does show up as that English word for me. You can actually see it in the screenshot posted here to the right. If you're seeing something different let me know (probably best to post issues like that to User talk:Equazcion/SidebarTranslate). equazcion → 04:45, 11 Nov 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The Wikipedia Adventure: Beta-test Invites

Latest comment: 10 years ago7 comments3 people in discussion

Hi folks! I've been working for the past 6+ months on an onboarding game for new editors called The Wikipedia Adventure. It's an interactive 7-mission educational tutorial about how to contribute to Wikipedia. It takes place in the editors' userspace and is based on Guided Tours as a game engine. TWA was funded by an Individual Engagement Grant and part of the project's scope is to do a rigorous analysis of the game's impact on editor activity and retention and contribution quality. To gauage that, we're going to be grouping editors into a treatment group, which will be invited to play TWA and a control group with similar editing patterns that is invited but doesn't play, and then a second control group with similar editing patterns that is not invited. All groups will have made at least one edit and have a Snuggle desirability rating of over .8 (in other words, we're only going to be invititing likely good faith contributors). Comparing the edit activity, date of last edit, number of blocks, and some additional qualitative analytics will give us a good sense of whether or not the game accomplishes its goal. To facilitate the beta test, we have proposed a bot approvals request using HostBot, which is currently active in facilitating the invitation of good faith new editors to the Teahouse. This request would let us invite 100 good faith new editors per day for 2-4 weeks to play the game. The nice part about the invites is that editors who take up the game may well go on to be more active contributors, and because the game takes place in userspace, there's little chance of disruption (we'll also be monitoring those editors just in case for signs of problematic editing). Further information about the impact plan is here. So I'm just proposing this plan here to make sure I can address any thoughts up front. Cheers and thanks, Ocaasi t | c 09:01, 10 November 2013 (UTC)

An interesting tool, though I admit I only went as far as the Userpage changes- if the rest are of that quality and calibre, then it is a great idea and well implemented. Good work! Chaosdruid (talk) 17:10, 18 November 2013 (UTC)
@Ocaasi: The welcome message appears to have a timestamp fixed on 8:54 pm, 2 August 2013, Friday [link. Can this be changed? --Mdann52talk to me! 13:21, 22 November 2013 (UTC)
Mdann52, great catch. I am having a touch of technical difficulty. I want to substitute {{currentdate}}, which gives the current date, but I need to do that on the user's talk page but not on the page which stores the welcome message. Any idea how to do that? (something about includeonly perhaps?) Cheers and thanks for the feedback! Ocaasi t | c 13:45, 22 November 2013 (UTC)
@Ocaasi: <includeonly>{{subst:currentdate}}</includeonly>. --Mdann52talk to me! 13:51, 22 November 2013 (UTC)
Mdann52. Brilliant! User:Ocaasi/sandbox. I will use this on all the messages in the game now. Thanks :) Ocaasi t | c 13:55, 22 November 2013 (UTC)
Invite update

Per the recent HostBot 4 approval, we started running 100 Wikipedia Adventure invites per day since last Wednesday. So far, we have had no technical problems and positive feedback about the game is coming in. (One editor intends to use TWA in a second education program course. Another education program member is adapting the game for a sandbox tutorial). Several editors have played through the game entirely yielding a very positive learning pathway and final product. Technically and functionally it's all looking good.

Our playthrough rate is about 1 for every 150 invites. This is entirely normal for an online invitation. It tracks the same rate as the Teahouse invites did. Now that we know what the rate is, in order for us to demonstrate statistically significant impact we will need to increase the number of invites during the trial period, using the Snuggle stream of good faith new editors.

These editors are pre-selected for having good-faith contributor patterns by the WP:Snuggle's machine-learning algorithm. We exclude editors who have never made an edit, and also exclude those who are blocked. We have been monitoring activity from these new editors and continue to check on whether or not they're causing any maintenance hassles for experienced editors.

We'd like to run the increased invites per day for the full 4 weeks of the trial period. This will permit us to run a full analysis of the data in the timeframe of the Individual Engagement Grant, the final report for which is due January 1st. Because of the timeframe, and our desire to gather meaningfully more data during the collection period, I plan to increase invites this week. Of course, we'll be mindful of any new technical issues or objections and not 'overdo it'. In this trial phase we only want enough data to draw meaningful conclusions; this is not the time to promote the game to the broadest possible audience (hopefully good results will permit us to do that in the next phase). Cheers, Ocaasi t | c 14:33, 26 November 2013 (UTC)

Proposal for a newbie flag

Latest comment: 10 years ago28 comments11 people in discussion
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Request for closure made at WP:ANRFC. There appears to be several views on this. One is that with the many gadgets that are available, it is easy enough to check edit count/contributions without needing a flag, and WP:AGF should be applied in any case. Therefore, I feel that there is consensus not to impliment the proposal. --Mdann52talk to me! 08:41, 27 November 2013 (UTC) (non-admin closure)

While it is a long established Wikipedia principle that WP:Competence is required, this is relaxed for new editors. It is also expected that such newbies be treated more gently and more patiently than experienced editors. However, it is usually not evident if an unfamiliar editor is a newbie, and therefore should be treated specially. To better indicate the proper level of interaction, I propose implementation of a newbie flag, as follows.

A "newbie" icon to be suffixed to the signature of new editors, based on the presence of a newbie template in their Talk page, along with a suitable banner. This would provide instant identification without having to examine their Talk page or logs.

New editors to be advised that:

1) They are expected to not edit recklessly, but first become familiar with the basic principles. (I.e.: look before you leap. Even better, ask first.)
2) The newbie icon automatically suffixed to their signature cautions other editors to treat them gently and patiently; new editors are expected to not abuse that.
3) The newbie icon also reminds experienced editors to either explain any abbreviations and wikijargon they use, or add appropriate links.
4) The icon will go away when the newbie template is removed. The editor is then presumed to be familiar with various principles and expectations (i.e., "grown-up"), is expected to conduct themselves accordingly, and to not try the patience of other editors. They may expect any lapses to be treated summarily.

This proposal could be considered an extension of (and could incorporate) the {{I'm a new user!}} template, which only displays an icon and banner on the Talk page, and is not automatically included. This proposal is distinguished from the {{This is a new user}} template, which only reminds other editors to not bite the newbie.

The essence of this proposal is the automatic addition of a special icon to an editor's signature if the newbie template is present, and advising the editor of the significance of that.

~ J. Johnson (JJ) (talk) 20:43, 30 October 2013 (UTC)

Comments

We already have one. It's called WP:AGF. The only time any editor should treat someone as if they don't have the "newbie flag" is if you know, from previous interaction, or from their user page/talk page/contributions that they are an experienced editor who should know better. WP:Competence is required is much more about the ability to incorporate new information into your editing than it is about magically knowing everything before you start. VanIsaacWS Vexcontribs 21:49, 30 October 2013 (UTC)
Thanks for bringing this up. I think that, even with AGF in mind, it's nice to be able to note that someone is brand new. Otherwise, you have to guess, or go look at their contributions (which, to be frank, we don't always do). We've considered this idea at the Foundation too. See "user icons" as a general concept on MediaWiki.org, and the "new editor getting started" edit tag we've used for the GettingStarted feature. It would be trivial to show someone as new, if we use a function like autoconfirmed status. Otherwise, the question becomes who counts as new? Another option is to simply remove the link to the GettingStarted feature, and call out all first-time edits by registered users. Steven Walling (WMF) • talk 23:27, 30 October 2013 (UTC)
I tend to check if someone's new if they seem to be acting unaware or even just have a redlinked username. It might be a good idea to flag newbies, but I don't think the list of advisories is all that necessary. I don't think the first and fourth advisories are necessary. equazcion → 02:51, 31 Oct 2013 (UTC)
I agree with equazcion that the first is potentially problematic, if misinterpreted (which a newbie quite possibly would). No, people should not edit recklessly, but they should Be Bold. Sometimes you have to make mistakes to improve. And often even a mistake can be an improvement (e.g. adding a reference, but using a bare URL). As far as the specific proposal, I'm not sure. I use WP:POPUPS, so I can mouse over and see how many edits someone has. I could see how the icon might be useful to people without that (i.e. most users). However, we would have to be careful it didn't become a scarlet letter that actually makes us less welcoming to new users. There's also the question of what to do if a user obviously isn't new, but won't remove the template (perhaps hoping for ongoing special treatment). And it is important to assume good faith for all users (not just newbies), when it's not clear whether someone knows the standards of behavior in a particular area. Superm401 - Talk 09:22, 31 October 2013 (UTC)

The initial comments (for which I thank you all) seem to be facets of a common theme: whether we should (to borrow some language from Talk:User Icons) recognize two classes of editors. E.g., VanIsaac says WP:AGF should apply to all. Sure. But this is more than AGF. E.g., must we explain or wikilink every abbreviation and wikijargon we use just because some new editor not yet up to speed might be present? That would be like "cruising" (if you could call it that) the freeway in low-gear. We need to know when we can shift gears. (And should: unnecessary explanations are condescending.)

Steven asks, "who counts as new?" New accounts are presumptively new editors. If not, the editor presumably knows enough to remove the template himself. I think it is fine (generally) to let the editor decide when to graduate. I'm not quite certain what to make of non-new editors not removing the template, "perhaps hoping for special treatment". If someone seems to be abusing the status you can always look at their logs, etc. It certainly would be incongruous for an editor to claim newbie status while boasting of thousands of edits.

Would such an icon "become a scarlet letter that actually makes us less welcoming to new users"? I think not. It's hardly a badge of shame, more like a "student driver" sign. It is quite unrealistic to expect that a new editor can be instantly experienced, and I think most newcomers will find it more welcoming that they get a little extra consideration. When they reach a level where the icon embarrasses them they don't have to wear it any more.

~ J. Johnson (JJ) (talk) 21:17, 31 October 2013 (UTC)
To answer your question: Yes, you should wikilink any policy you are citing on its first occurrence in any discussion, just like you would the first time a term appears in an article. I don't care if the editor has a dozen edits and three days under their belt, or if they've been here a decade-and-a-half with 100k edits, there should be a link to any policy cited in any discussion, so that other parties can actually read it to see if the policy has recently changed, or if you are seeing a nuance they didn't notice before. And again, unless you have specific knowledge to the contrary about an editor's experience - if you see them using wiki-jargon, for example - you should use jargon transparently. None of that can be captured in a "newbie flag" - you have to actually look into a person's contributions, or assume that they didn't know what you are talking about. VanIsaacWS Vexcontribs 21:59, 31 October 2013 (UTC)
You address two different points. First is whether new editors should in any way be treated differently — whether more gently, more patiently or any other way — than experienced editors. You are saying that all editors should treated gently (etc.), which is to say: no difference. But the reality is that new editors often need a consideration (like explaining elementary terms) that would be condescending, even insulting, for experienced editors.
Your second point is that a newbie flag cannot capture the various criteria (such as the person's contributions, etc.) that one must "actually look into" to assess an editor's competence. Of course not, but you have missed the point. The purpose of such a flag is replace all of that with a single criterion: has the user taken down his newbie flag? That criterion reflects both a basic competency and the editor's preference. More to the point, by suffixing the icon to the editor's signature we can tell at a glance — without having to assess the editor's contributions — that a really dunderhead edit or comment might be just a beginner's misstep. ~ J. Johnson (JJ) (talk) 20:35, 3 November 2013 (UTC)
And I see nothing here about how the metric of "has the user taken down their newbie flag?" could possibly have any sort of relationship at all to those criteria that you need to evaluate when you post a message to a user, and more disturbingly, you seem to already be anticipating being able to do away with basic assumptions of good faith - that reaction to a "dunderhead edit or comment" should somehow be determined mechanically. For the record: anytime you are talking to an editor about a "mistake" of some sort, it should be tailored specifically to that editor's history regarding that matter, their level of overall competence, and your history with them - none of which can be captured by a flag. I can think of no reason to explicitly fight against imposing a scarlet letter on new editors more compelling than the attitude that you can treat someone who is new as if they don't know policies, or that someone who isn't new somehow knows them all. VanIsaacWS Vexcontribs 00:09, 5 November 2013 (UTC)
Your characterization of this proposal as "imposing a scarlet letter on new editors" is emotionally evocative but inaccurate. This, and your other mis-characterizations — such as your anticipation that I would "do away with basic assumptions of good faith" — is corrosive of civil discussion. Could you please discuss this with less passion and more objectivity?
I point out that the scarlet letter that Hester Prynne was forced to wear did not signify "I'm new here, please introduce yourself." Rather, it was a very public outing that she was an => ADULTRESS! <=, that she'd had SEXUAL RELATIONS with a man NOT HER HUSBAND!!! Is that what you think is implied when we identify someone as a new editor?
You seem to think that the two-valued state of the proposed flag implies that editors are similarly all or nothing in their competency. Not at all! No more than having a "student driver" sign implies that one is a hot and horny 15-year old who hardly knows which side of the road to drive on, or that the lack of such sign means you can drive the Indy 500.
A newbie flag is the equivalent of a "student driver" sign. It cautions other editors that this new user might not be up to speed on the basic expectations (including WP:AGF). It does not attempt to convey all the possibly relevant information that you say needs to be evaluated to specifically tailor your interaction with another user. But as you are not perfect enough to do so in all cases yourself, you should welcome having a reminder of when it is more important to do so. ~ J. Johnson (JJ) (talk) 21:09, 6 November 2013 (UTC)
I find it interesting that you would chide me about discussing things objectively when you have taken an off-hand remark likening these things to a scarlet letter, and yet failed to address any of my actual concerns. Specifically, that interacting with other editors requires a combination of prior iteraction and evaluation of their editing history, and that this proposal does absolutely nothing in regards to the standards that you should utilise in interacting with other editors. All it does is brand new editors (and old ones, by the contrapositive), short-circuiting AGF and WP:Civility. Now you may not like that you can't just shunt editors into one of two boxes and apply two vastly different standards to everyone based on their box, but editing a collective project requires much more nuance than can be captured by anything like this. VanIsaacWS Vexcontribs 00:37, 9 November 2013 (UTC)
You are not "discussing things objectively" when you expressly characterize the proposal as a "scarlet letter". And it is disingenuous for you to now try to duck that by calling it an "off-hand remark".
And I have addressed your stated concerns (above); your statement to the contrary is bullshit. It seems to me you did not even read my comments, so I see little purpose in responding to your gross mis-characterizations. ~ J. Johnson (JJ) (talk) 23:00, 11 November 2013 (UTC)
See also bugzilla:11800. Legoktm (talk) 20:36, 4 November 2013 (UTC)
Also buzilla 10789. (Thanks for bringing this to our attention.) The difference there is 1) to use color instead of an icon, and 2) apparently to base it on some kind of automatic assessment. I'll comment there as soon as I get a Bugzilla account. ~ J. Johnson (JJ) (talk) 23:17, 4 November 2013 (UTC)
I have another motto: competence can be learned, competence can be taught. --NaBUru38 (talk) 22:25, 4 November 2013 (UTC)
I have proposed something that would produce the same benefit, as well as other benefits. Rather than a newbie icon, I would have all new editors assigned a name which would indicate the date they joined. That would serve to identify that they were new, and even gives solid clues how new, (day one versus day 30). I believe newbies should be treated differently. My full proposal is at this page Addendum: It also addresses the competence hurdle issue - when the editor feels ready, they request an ordinary name.--S Philbrick(Talk) 22:00, 5 November 2013 (UTC)
Newbie here. Have enough growing pains with the help of several good faith users ad the teahouse. I'd prefer to say 'i'm new' than have a flag /tag etc added to my name. Finding the correct help to a question isn't easy via search. Another solution could be the 'where to get help' for new users, so we can help ourselves better without causing grief. Behind the text we are all human, and any tag, however functional, could feel like a brand. I'd suggest that newbies have an option in account set up, to self disclose status, rather than it be imposed.--Andrea edits (talk) 16:33, 8 November 2013 (UTC)
There is a {{I'm a new user!}} template you can add to your talk page to create a talk page banner, though it appears the newbies are expected to figure that out themselves :(. But part of the problem is that most (?) users don't check another user's talk page before interacting. Having this cautionary indication in the signature would avoid some of this "shoot first, then check" behavior. Don't forget that you would be fully free to remove the template, and thus the icon, at any time, including the very first time you edit.
It might be noted that the proposal is to automatically add the icon if the template is present, but makes no mention of when or how the template gets added. It could be automatic for new users, optionable at registration (as you suggest), or entirely "find it and add it yourself" (as the existing template). The last is somewhat pointless (by the time you find it and figure it out you may not need/desire it anymore), and automatic would be simpler than optionable. This is independent of the template/icon functionality. ~ J. Johnson (JJ) (talk) 23:37, 8 November 2013 (UTC)
You raise good points, and mention templates I had not found - so relying on 'finding it yourself' to me has no merit. Having thought more on it, the automatic colour variation in name/signature could be discreet for a newbie and serve the purpose needed by the community. Then as we learn more/have no edit wars/negative conduct, have a way for it to be 'removed/changed'. I can see something is necessary for the community. And as newbie, unless you put a 'flag' or 'l' plate, I'd not know if the colour of my signature was anything unusual, as I see so many styles & fonts etc etc. I don't know logistics, but a particular hue of blue in say the (Talk) part of signature would be subtle to newbie, made automatic to start with - or as part of setting up, for ease of beginner use. --Andrea edits (talk) 14:10, 14 November 2013 (UTC) How / when to remove is a different issue, since it seems newbies have a variety of reasons for joining. --Andrea edits (talk) 14:31, 14 November 2013 (UTC)
Changing the color of an editor's signature (either foreground or background) would run up against the editor's own color specifications. But note that this proposal does not specify the details of the icon. That could be (e.g.) a small, pale orange "middle dot": ·. Which would be a lot more subtle than messing with the color(s) of the signature itself. ~ J. Johnson (JJ) (talk) 22:59, 14 November 2013 (UTC)
It's possible that WP:Flow (the planned replacement for the current talk page system) would be able to do this in a way that is both relatively discreet and automatically updates, like the dots used at Apple's support forum (the more posts you make, the more dots under your name). I don't think that I'd want to do anything in the current system. WhatamIdoing (talk) 18:33, 14 November 2013 (UTC)
There is a key difference to note here. Other proposals would have the newbie indication conditioned on some algorithmic evaluation of the editor's experience (such as 10,000 edits, etc.), quantified experience being taken as a proxy for competency. (In this regard a certain objection raised above would be valid.) A key difference with this proposal is that the presence of the icon indicates only that editor either does not have the minimal competence to remove the template (explain everything!), or does not care. (Or perhaps prefers to have extra gentle handling or assistance.) Nothing more!
Another key difference is that even if the necessary wikimedia code is in place, there is absolutely no change in how things work if the template is not used, or (perhaps deliberately) not available. If rollout invokes some immense outcry, simply taking out the template effectively puts things back as they were. ~ J. Johnson (JJ) (talk) 23:13, 14 November 2013 (UTC)
3 points I see here I'd like to add comment. The tech points I can't comment on- always my week point. 1. Strongly agree with idea of icon being something like the pale orange dot mentioned above. 2. Templates and code (DYI) are easier for some newbies to figure out than others, as discussed this has pros & cons, I can't offer any ideas for that. 3. Strongly agree there is difference between Quality/quantity. If a discreet icon was used, could algorithm set at e.g. 10,001, generate message to alert user to apply to have a 'review' to consider removing icon? If person reviewing sees come criteria or issues that do not indicate sufficient of potential improvement, then with brief explanation, reset for a time period? This might flag/note newbies who ignore GF advice repeatedly, continue disrespectful behaviours or engage in time wasting edit undos rather than seeking consensus.--Andrea edits (talk) 05:14, 15 November 2013 (UTC) Off topic but an Eg of tech skills being no indication of other abilities, see my constant typos, my spell check goes on & off, and I don't notice. That's on talk pages. For any proper work, I use word, then check & transfer, so this is not indicative of my standard for wiki docs (BTW).--Andrea edits (talk) 05:29, 15 November 2013 (UTC)
Why should an editor "apply to have a 'review' to consider removing icon"? The proposal here is that a new editor is entirely free to remove the newbie template (which would automatically remove the icon) at any time. Even as their very first edit. This proposal has nothing to do with any kind of review. ~ J. Johnson (JJ) (talk) 01:04, 16 November 2013 (UTC)

To be honest, this is really a waste of time. Simply hover your mouse over their name - it tells you how many edits they have done. If it is less than 30, they are a probably a noob/newbie/(insert some other silly equally-derogatory title here).

To further find out their level of skills/experience, hover and click "contributions" to see what they have edited and how. This seems like a lazy way for more experienced editors to pigeon-hole editors on a scale that ignores "quality of edits". If a professor of biology, or someone with 30 years experience in lab work, edits three pages twice, a "noob" tag is unwarranted and probably offensive to them. Chaosdruid (talk) 17:19, 18 November 2013 (UTC)

I believe that the hover trick only works if you have WP:NAVPOP enabled. It certainly does not work for people with plain vanilla preferences. WhatamIdoing (talk) 18:35, 18 November 2013 (UTC)
Exactly! Chaosdruid (talk) 19:51, 19 November 2013 (UTC)
An editor with five years and 10,000 edits might be offended to be characterized as a new editor, regardless of what term is used. If you feel that "newbie" is inherently offensive then feel free suggest that the term be banned.
But: an editor with less than one edit is most likely in fact a new editor. How is that derogatory? Where is the shame? We all start with zero edits, zero years of experience, and zero acquaintance with the principles. If a new editor objects to having that pointed out then (as I keep saying over and over) he is perfectly free to remove the template. ~ J. Johnson (JJ) (talk) 22:25, 19 November 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Add words "show map" to Geohack (?) globe icon

Latest comment: 10 years ago2 comments2 people in discussion

I am one of the most active Wikipedans, active on en wiki for 9 years now, but it is only few weeks ago that I discovered that you can click on the globe icon in articles with GPS coordinates (which I've been adding to articles for years) and get a map feature. I just never thought that the globe icon is clickable (I've clicked through to the Geohack pages often - the coordinates are blue linked, after all). In other words, the globe is not an intuitive button people will click. Now, on pl wiki instead of the globe there's the word "map", blue linked, and so I've used this feature on pl wiki for years, wondering for all that time why English Wiki doesn't have it. Hence, I'd like to propose we add a simple modification to geohack, or whatever extension is powering this feature on en wiki: add words "show map" (perhaps in small font?) next to or below the globe icon. Please comment here on whether you support this proposal or not. To check how this looks on various wikis, compare Iksan, pl:Iksan, fr:Iksan (uses the word map instead of an icon, just like pl wiki) and de:Iksan (note that de wiki also has an icon for open street map, also a nifty feature we could use). PS. Ping: User:Kolossus, User:Egil, User:Dispenser, User:Magnus Manske, User:Docu, User:Pigsonthewing. --Piotr Konieczny aka Prokonsul Piotrus| reply here 03:16, 26 November 2013 (UTC)

I thought this was supposed to be kept a dark secret with a risk of bans and blocks for anyone mentioning it. However, now the cat is out of the bag, it is indeed a good feature and sometimes close to miraculous (River Thames, White House, Tycho (crater)). Why is it hidden like it is? I would still greatly welcome it if Google restored the WP layer (the discussion you have opened below). Thincat (talk) 17:03, 26 November 2013 (UTC)

Proposed new Draft namespace

Latest comment: 10 years ago302 comments130 people in discussion
The first thing to clear up is what exactly is being discussed. TheOriginalSoni's first proposal included discontinuing the use of userspace drafts and moving userspace drafts into the proposed drafts namespace. This has clearly and resoundingly been rejected by editors. TheOriginalSoni then modified the proposal to allow the continued use of userspace drafts. A number of users suggested that because of the change in what is being discussed, that the RfC was therefore hopeless and unsalvageable and that a new RfC should be conducted with a new proposal. I don't see consensus for that view given the number of people in both the support and oppose camps who have modified their !votes to reflect the changed proposal. WP:NOTBUREAUCRACY applies: having another RfC for this would be a triumph only for rules lawyers. The proposal was changed fairly soon after the opening of the RfC and enough discussion has taken place on the redrafted version of the RfC for this to no longer be a concern.

The case made for this change is that it will simplify the process of submitting draft articles (as has been done through AfC), and will help both experienced users and creators of bots and tools better support the processes around these articles. Some users have opposed on the basis that it will not help reduce the backlog of pages awaiting review at AfC. This is not something which the proposer suggested the change would bring about: it failing to do something it does not set out to do probably ought not to be considered a particularly compelling objection.

A number of users argued that a Drafts namespace would fix technical issues with the AFC process and enable the creation of a toolset that is slightly less "kludgey" to be constructed. The issue of search was raised: currently, searching for a topic in the 'Wikipedia talk' namespace brings up a significant number of AfC submissions. Segregating these off would make the search function more useful for editors.

Against the proposal were a number of objections. A number of users argued that there is a risk of creating new layers of bureaucracy. This is indeed a valid concern. A number of users objected that it fixes no problem, although no substantial discussion was given to rebut those claims made of exactly how it would fix problems.

After weighing the arguments, it seems clear that there is support for the principle at the heart of the proposal: a new namespace for Drafts. The participants in this discussion expressed a variety of views on the effectiveness of the Articles for Creation project, but no challenge was made to the proviso that AfC would continue as it currently does. This community discussion does not change the AfC process—any such decisions should be ones that the AfC WikiProject should make through further consensus-based discussion if they deem it to be necessary. A key part of this discussion is the very strong support for the principle that users should be able to store drafts in their userspace. This principle must be adhered to in the implementation of this RfC: the Drafts namespace may be strongly encouraged for new editor, but if a registered editor wishes to keep drafts in their userspace, they must be allowed to do so. The processes for deleting userspace drafts (like WP:MFD) remain the same; userspace drafts should be treated the same once the 'Drafts' namespace is in place as they are now.

—Tom Morris (talk) 22:32, 19 November 2013 (UTC)

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

Tracked in Phabricator
Task T59315

Rationale

Wikipedia:Articles for creation (AFC) has a regular backlog of over 1,500 submissions, all currently stored in various makeshift locations. These submissions fall on a handful of volunteers to review, provide feedback on, and potentially pass to article space. This is not only an issue at AFC, but at other article drafting venues. These venues (including AFC) handle new article submissions from newer users who aren't very familiar with Wikipedia's policies, and likely can't create articles on their own yet that would meet our inclusion or content standards.

One obstacle to this constant influx being manageable is the multitude of locations where new article submissions are placed. Some go to the submitter's userspace, others to AFC subpages, some to Wikipedia:Article Incubator, and so forth. This not only makes work difficult for the current volunteers, but also discourages new volunteers from participating, and creates an even more confusing situation for the submitting user.

Proposal

Proposed: Create a new namespace for article drafts, called "Draft:", to serve as a central location for new article submissions posted through Wikipedia:Articles for creation and the other venues aimed at newer users. This way, the task of reviewing submissions will be a less fragmented process, and it will be easier for volunteers to collaborate.

Additionally:

  • Submissions from anonymous users (IPs), which lack a true userspace, will be far easier to locate.
  • WP:Article incubator is currently not of any help, and it has reached a point where it is nearly non-functional.
  • A single location allows easier access for automated or semi-automated tools that check for copyright, BLP, and other issues.

Note: This proposal does not concern any reforms to the way drafts and reviewing is currently handled, but rather organizing where they are stored. Also note, this proposal came up at Wikipedia:WikiProject Articles for creation/RfC 2013, where there was significant support, but technicalities prevented it from being implemented at the time.

Details

The new Draft namespace would function as follows:

  1. A separate namespace, named Draft would be created. This namespace would serve as the location for creation and improvement of draft articles before being transferred into the mainspace. All articles in the draft namespace will be called using Draft:ArticleName in Wikitext. All pages on this namespace will be NOINDEXed.
  2. This namespace would supersede the current draft article locations as the default location for draft articles. These current locations include Article Incubator, Userspace drafts, AfCs and other such locations. Except userspace, all articles currently in these namespaces will be transferred to the Draft namespace.
  3. The current policies that currently apply to AfCs and Userspace drafts (with respect to deletion, content etc) would extend to the new namespace, including any other criteria as seen fit. Any drafts at AFC inactive/not edited for a period of six months would be liable for deletion, as is current policy.
  4. All policies pertaining to Userspace drafts would be now modified for the new namespace. Any new users creating drafts would be directed to the new namespace. Users would, however be permitted to retain and create their drafts in the userspace if so desired.
  5. WP:AfC would continue to operate the way it currently does. All articles created through AfC would contain the AFC codes and would pass through the review process as is currently followed. But as done for other drafts, it would be permissible to directly move articles from the Draft namespace to mainspace.
  6. There will be a separate discussion/RFC to decide the fate of the Article Incubator process. The RFC would decide whether the process remains the way it is, or if it is marked as historical, or any other alternatives.

TheOriginalSoni (talk) 19:05, 7 November 2013 (UTC) (later revised)

Revision of details: Userspace Drafts explicitly allowed

The original proposal contained a provision that:

"Articles will no longer be allowed in Userspace and any new articles in the userspace would be moved to the new namespace."

That provision met with opposition and has now been dropped from the proposal. Instead, the proposal now provides a guarantee that users may indeed retain and create drafts in their userspace.

Discussion

Any discussion about the proposal, or possible changes to it should be in this section

  • I would like to be able to keep drafts in my userspace. My sandbox has snippets of information for a dozen draft articles, along with proposed policy revisions and other things that I might want to look at in the future. I like the idea of having a draft namespace, but would like to clarify that I can continue to make drafts in userspace and move them into article space from there. bd2412 T 19:28, 7 November 2013 (UTC)
  • I, also would like to keep userspace drafts/sandbox articles in userspace (incidentally, Technical 13 has a great sandbox design template which I feel should be for all users, but that's for another day); perhaps it could be opt in here. I feel that the sandbox is a kind of personal space, a haven where less people look at. If one of my (many) drafts were in draftspace, I wouldn't feel so sure that no-one would edit, vandalise, or otherwise damage them. Thanks, Matty.007 20:23, 7 November 2013 (UTC)
  • I share the concern with this . It is sometimes appropriate to keep material in userspace, both in sandboxes and in subpages.Obviously this could be kept off-wiki, but it will be much easier not to make this a requirement. We will need some modification of the wording. I think Kudpung's wording is a good one to start with.
As a second concern, while all current policies will apply to this material, the policies should not be spelled out so exactly here. It is enough to say they apply until we should decide to change them. DGG ( talk ) 21:09, 7 November 2013 (UTC)
  • In the time since the failure to arrive at a consensus as to what to do with the incubator I have been working to clean up the dark corners there and many of the drafts that were languishing there are now either back in article space or deleted. Almost everything left pertains to upcoming films from India. Since it is now a tiny project with almost no regularly active users I think this might be an alternative that many of those who were opposed to just shutting it down could get behind. Beeblebrox (talk) 21:37, 7 November 2013 (UTC)
    • I agree. I've always had a love-hate relationship with the incubator. I've supported it in the past and tried to help it get off the ground, but it never quite could get there. Every time we talk about deleting it, there's a little burst of activity and then nothing. This Draft space idea is the best idea I've heard to supercede the incubator and consolidate the drafts, while also addressing the perennial proposal to noindex userspace. It's a well crafted idea that addresses several issues, and makes it all more user-friendly in the process. Gigs (talk) 22:05, 7 November 2013 (UTC)
      • How about stubs already in article space? I would be delighted to send quite a few of those "back to draft". bd2412 T 22:10, 7 November 2013 (UTC)
        • I think one of the most interesting ideas regarding a Draft namespace is that we could move articles back in to it from mainspace, rather than delete. I wonder how many A7 CSDs, PRODs, and AFDs could be easily dealt with my de-promoting an article by moving it back in to draft status. This could be really good for the encyclopedia, and good for authors, who would be able to continue working on a draft until it's up to snuff. Steven Walling (WMF) • talk 00:16, 8 November 2013 (UTC)
          • That will work until the moment that rules are put into place regarding how long a draft can go unedited before it gets speedy deleted. I predict that if this namespace is created, that will happen rather quickly, considering that part of the motivation behind this proposal is to get rid of stale userspace drafts. Sven Manguard Wha? 02:37, 8 November 2013 (UTC)
I've certainly !voted "Send to AfC" a few times in AfDs - I think for yet to be released albums and foreign language books and films. Michael Whalen (actor) is one such article I might do the same with should it go to AfD as I think much of the guy's notability rests in offline sources, if it exists at all. Ritchie333 (talk) (cont) 10:13, 8 November 2013 (UTC)
  • I just want to ensure that the new namespace would be natively transcludable and invokable. VanIsaacWS Vexcontribs 23:51, 7 November 2013 (UTC)
  • I have actually considered the idea of a "sub-Wikipedia" before, for articles that aren't quite yet ready for Prime-Time but hopefully one day will be, so you know I am down this this idea. I have also tried a couple of proposals that dealt with ways to centralize failed AFC submissions, stale user space drafts, and article incubator pages so that people can actually find and work on them, but to no avail. I am wondering if draft space articles will be searchable? Consider the user coming here and looking for Subject X but finds that there is no article... although there is a draft that the user can work on. Possibly also consider soft redirects to the draft space? BOZ (talk) 00:17, 8 November 2013 (UTC)
  • People want their drafts to be in their own userspaces so that they can work on them, in private, at their own pace. I can start a draft, let it sit there for several weeks, and then come back to it (which is useful, for example, if you start the draft when a video game comes out, but then have to wait a few weeks for the reviews to come in). Once we have a Draft namespace, there is inevitability going to be a whole bunch of policies and guidelines, dreamed up by people that cannot function in a world where everything is not governed by a whole bunch of policies and guidelines, and then forced on everyone else. Gone will be the ability to create a draft at a leisurely pace. Gone will be the ability to create a draft without sources (and then add them in later). Gone is the ability to just throw a bunch of sources on a page and let it sit there for when you're in the mood to write something. Wikipedia editors are notorious for creating policies based on their own personal views and then forcing those views on anyone that did not participate in the discussion. That is what several parts of the the Manual of Style are. That is what many WikiProject "policies" are. You can write a perfectly functional article having never read the MoS and having never joined a WikiProject, but that doesn't stop people from trying to force the MoS and WikiProject "policies" down your throat. It will happen to the new Drafts namespace. And when it does happen, I will simply stop writing drafts, because it's too much hassle. Which means that I'll stop writing in general, since everything I've done has come from a userspace draft. I don't mean to sound ranty (I know I do though), but I simply lack any confidence in the Wikipedia community not to build some unwieldy bureaucracy around the Drafts namespace. And that means that I can't support the namespace. Sven Manguard Wha? 00:52, 8 November 2013 (UTC)
    • Why does it have to be that way? Why can't we just let drafts develop in their own sweet time? There's no reason we have shim AfC's reviewing rules on to a new namespace. Like I said in the section about technical implementation, we should take an experimental approach here, rather than assume we have all the answers and design every policy about drafts up-front. I share your skepticism about requiring a rules-laden process and deadlines. Steven Walling (WMF) • talk 00:58, 8 November 2013 (UTC)
      • You're right, there is no reason why we have shim AfC's reviewing rules on to a new namespace. But even if there's no reason for it, it's still going to happen. There are enough people that like making rules and then forcing everyone to use those rules, and there's enough people that can't seem to function in an area that doesn't have rules, that rules will inevitably develop. Different projects have different cultures when it comes to bureaucracy, and English Wikipedia is very much a culture of over-bureaucratizing everything. Part of that is that there's a definite absence of inter-user trust, and the bad faith that goes along with that, but part of that is just that Wikipedia has been creating rules for everything for so long that it doesn't know any other way. Sven Manguard Wha? 02:34, 8 November 2013 (UTC)
  • My reason for strongly supporting the creation of a 'draft' namespace is almost entirely based on the possibilities it would open for improving and streamlining the way AfC submissions are handled, including the reviews, accepts, declines, and possible speedy deletions or other forms of deletion tagging. There is also the secondary benefit that it would replace the Incubator, but it should not become a replacement namespace where borderline possible articles should simply be parked just in case they might receive attention from a passing editor. All the normal practice at AfC would be retained for the draft pages. There is absolutely no technical hindrance for creating a draft namespace, and I agree that once done (with the provisos mentioned by many about innocuous drafts in user sub pages) and monitoring its use for a while, fine tuning and a future possible definitive deprecation of the Incubator could be discussed in future RfCs. Kudpung กุดผึ้ง (talk) 04:34, 8 November 2013 (UTC)
    • Hey Kudpung. Regarding "All the normal practice at AfC would be retained for the draft pages." This is true, but I would urge you to use the opportunity to create a new namespace to perhaps rethink some of the premise of AfC-style workflow. It is a very distinct possibility that, even with a new namespace, that the system of pre-approval for all drafts still doesn't scale. It will be a huge failure if we create a lovely new draft space, and new users still have to wait weeks or months to get review. Hope you're well, Steven Walling (WMF) • talk 05:25, 8 November 2013 (UTC)
Steven, this is precisely what is planned. It's been mentioned elswhere that with the potential possibilities afforded by a 'draft' namespace, the Helper Tool and other scrips may possibly be made redundant and replaced by something even better depending on the power of our resident programmers at AfC. It will be a new challenge for them, but it would certainly be rewarded not only by faster reviewing, but also with better quality. Perhaps you remember some of our discussion with Brandon and Erik in Hong Kong. Before we can do any of this though, the creation of the namspace comes first. Kudpung กุดผึ้ง (talk) 11:18, 8 November 2013 (UTC)
  • Regarding the comments about changing the proposal, I didn't know my explicit agreement was required to change the proposal. The way I understood it, I didn't own the proposal, and anyone can change it adequately if that is the consensus.
In any case, I'd agree to what the consensus says, but have a moderate solution of my own. The reason userspace drafts are included in this proposal is because half of them could be better mantained and monitored at AFC, which makes sense to include them into Draft namespace, where the articles can be easily checked for simple things like copyvio. Would it be fair enough if there was an opt-out of some sort which any user could enable, so their userspace drafts would not be moved? In my opinion, that would take care of both the concerns here (Getting the articles into draftspace and concerns by editors above). [I dont know the technical details of how this could be implemented, but the opt out will be made adequaltely clear in the notice the users would be getting before the move, and would possibly be something as simple as adding a template on the top of the page to make it clear it is not to be moved to Draftspace.]
If others with objections are okay with this possible solution, we'd alter the proposal to say so. If not, then I'm open to anyone modifying the proposal to take out that userspace draft point. TheOriginalSoni (talk) 10:36, 8 November 2013 (UTC)
    • @BD2412, Kudpung, Matty.007, DGG, and Sven Manguard: @Beeblebrox, BOZ, Samwalton9, LukeSurl, and Legoktm: @MER-C, BilCat, Johnuniq, SilkTork, and Charlesdrakew:@Equazcion and Philon: Please check the alternate proposal I have made just above, and register your opinion on whether it would be an acceptable compromise to the issue noted by almost all editors in the proposal. TheOriginalSoni (talk) 10:59, 8 November 2013 (UTC)
      • I'm not crazy about the alternate proposal, and I don't think that will appease most of the people who don't like the userspace prohibition. People drafting in their userspace won't all necessarily be made aware of the need for any opt-out procedure. I think concerns about drafting are sufficiently addressed by directing new AFC drafts to the new namespace going forward, while also allowing unfettered userspace drafting for those experienced enough to have a preference for it. FYI The reason people are apprehensive about altering your proposal is because it's essentially a signed discussion comment, and that's aside from the fact that many proposers do indeed consider their proposals "owned" (this isn't an article, after all, so the ownership policy doesn't really apply). equazcion → 11:07, 8 Nov 2013 (UTC)
        • Personally I would be all for a method by which users can move their userspace drafts to draft as they want to. As I see it, userspace drafts are for individual editors to put together their article as they want to in their own time without the contribution of other editors (unless requested), and the draft namespace would be a collaborative draft area. With this view I would see it as a very helpful thing to be able to move my personal userspace drafts over when I've done as much as I want/can, to allow others to have input on it before moving it to article properly. I wouldn't necessarily want my drafts to be moved over instantly and possibly without my prior knowledge as Equazcion pointed out. My personal preference, therefore, would be a method by which when editors feel the need for help with their article that they can move it to draft space then, rather than automatically. If nothing else, the draft space is going to fill up with a TON of useless/barely started pages if everything was moved over. Samwalton9 (talk) 12:52, 8 November 2013 (UTC)
  • Note - As a preliminary measure, all points regarding the transfer of and not allowing userspace drafts has been removed. If the above alternate proposal gains traction, the proposal would be changed as required. TheOriginalSoni (talk) 12:03, 8 November 2013 (UTC)
  • (after ec) The proposal to ban userspace drafts is idiotic. There is nothing to be gained by pissing off established editors by forcibly clearing out their userspace. I have dozens of proto-articles and just ideas for articles (sometimes just a list of potential references) in my userspace. Most of these are not even at the stage where they could be offered as drafts for others to work on/review. Many have not been touched for months or even years but the set as a whole still produces a steady stream of new articles for Wikipedia. Automatic deletion of these would be a disaster as far as I am concerned. There may be some sort of case for going through the draft articles of long inactive editors, but I still would not be in favour of automatic deletion. Anything with potential should be retained, possibly moving into mainspace where the higher visibility will get it worked on. Deleting useful material should never be done however long it has not been worked on. Each page should only be deleted on its own merits. SpinningSpark 12:07, 8 November 2013 (UTC)
  • Point 2 still says Any inactive drafts would, however, be deleted which could be read as including userspace drafts. In any case, I am opposed to deleting drafts on this basis, whether or not userspace is included. Drafts should be deleted or kept on their merits, not on when the last edit happened to have been made. SpinningSpark 12:38, 8 November 2013 (UTC)
  • It may be too late now to change the course of this RfC. That happens typically when RfCs try to address too many different objectives or ones that are peripheral to the main one. The RfC began well with response from those who see the need for the draft namespace for the operations at AfC, but editors coming here now from the RFC/Cent template may not be aware of the concerns at AfC and are simply worried, and rightly, about the existence of reasonable dratfs in their user space. As I've said below, it's probably best to get the draft namespace created, and then decide in future RfCs what it can be used for beyond enhancing operations at AfC. Kudpung กุดผึ้ง (talk) 12:50, 8 November 2013 (UTC)
    • If this was conceived solely as an aid to AfC, TheOriginalSoni botched this royally, because when I look at it I see AfC as being a periphery concern to the drafter and to the respondents. If this was built to make AfC work better, it should have been explicitly framed as a tool for AfC that only applied to AfC. But it didn't; it was framed as a tool for all drafts, including those in the userspaces of experienced users. Surprise, surprise, the experianed users came out in force and said "no, I don't want to cede control of my drafts to a new userspace that has new rules and lacks the privacy of being in my userspace". Spinningspark perfectly encapsulates the anger that such fuddling in 'other people's stuff' results in. (My above responses, on the other hand, perfectly encapsulate what happens when editors lose confidence in the broader community to property manage the project, a related but broader issue). But I agree with Kudpung, it's too late for this proposal. I advocate shelving it, reading over the feedback, and coming up with a new proposal that takes into account the reservations expressed by many people here. Sven Manguard Wha? 15:52, 8 November 2013 (UTC)
      • I agree, start again with a new reworked proposal. Although it is claimed userspace drafts have been edited out, the proposal still talks about user drafts as if this will be the new default (at point #2), and userspace policy will be modified (at point #3). Write it again just from the perspective of AFC. Also, the claim that it is policy that AFC drafts not edited for six months are liable for deletion is not correct. CSD G13 is only for drafts that are rejected or unsubmitted for six months, and I am dubious that "unsubmitted" ever had consensus in the first place as I remember the RFC. SpinningSpark 16:43, 8 November 2013 (UTC)
  • The proposal is much more attractive now that users would "be permitted" to work in user space, although the quoted phrase has a threatening overtone (we permit you to do it now buddy, but permission will be revoked if you so much as blink). My proposal would be that any RfC intended for wide discussion spend a few days in draft form so the typos can be removed and the wording can be cleared up (what does "All policies pertaining to Userspace drafts would be now modified for the new namespace" mean?). Johnuniq (talk) 22:53, 8 November 2013 (UTC)
  • This should totally leave out userspace drafts, which serve a useful purpose for experienced editors who want to develop articles at their own pace, without any necessity for intermediate stages to be worthy of others' eyes. This cannot readily be done off-wiki because of the need for wiki formatting. If stale user subpages from editors who have retired are really becoming a problem, they can be readily deleted by some unrelated process, possibly a new speedy category for them. Espresso Addict (talk) 04:09, 9 November 2013 (UTC)
  • Yes, start again and totally leave out userspace drafts. I agree with the comments of Sven, Equazcion and others. --Stfg (talk) 11:57, 9 November 2013 (UTC)
  • As an editor who does a lot of reviewing in Afc, it seems to me that the current process, which lets new users create drafts at Wikipedia talk:Articles for creation/Title, and more experienced users create drafts in their own user space which are then moved either to Afc for review or directly to article space works well. The lack of separate talk pages in Afc means that review comments, categories and templates can easily be removed when the article is created. If a new draft space is created, there would still need to be a way to separate drafts submitted for review from other drafts, so I can't see that a draft space would simplify things much. If the draft space were only for drafts to be reviewed, then one advantage that I can see is that typing "Draft:" is a lot quicker than typing "Wikipedia:Articles for Creation". I am currently helping to check through the tens of thousands of abandoned drafts before they are deleted with db-g13, and I can say that this process would never be practical if they weren't all in one place and easily found. I agree with leaving the userspace drafts where they are. Right now, the Hasteurbot reminds users who have AfC drafts when they haven't edited them for six months; the same could be done for userspace drafts if there was a consensus that it would be helpful. However, perhaps another advantage of a Draft namespace would be that if an editor started a draft in his or her userspace and then lost interest or was about to retire he or she could move it to the new area where others would then have six months to show an interest in it. —Anne Delong (talk) 14:54, 9 November 2013 (UTC)
  • My largest concern, and this is something that I need to be assured will not be the case, that articles started in the main namespace will be prohibited by policy as a result of introducing this particular namespace. Over and over again I have seen proposals and even flat out assumptions that it is already policy that the AfC process is the one and uniquely only way to create new articles (something that a close reading of actual policy shows to be flat out wrong). There is much to the idea of a draft namespace, something I might even simply use for new articles that I will create myself. I do see some advantages of this idea but it should remain an option and a tool to help editors, not something that is used to bash over the head of editors (experienced or novice.... it shouldn't matter) demanding that they absolutely must use this namespace for new articles. I agree with other statements that userspace drafts ought to be kept as well.

    The idea that the draft space could combine the AfC and Article Incubator projects together is also a very good idea. They both could use some help and a well put together proposal that sort of merges those two projects and allows some incubation away from the main article namespace but also encourages new article creation to be supervised by the same group of people would go a long way to helping both projects. The devil is in the details, so I would like to see more formally how this is actually going to work in terms of article reviewing/creation work flow within Wikipedia, but as a general idea I like where this is going. --Robert Horning (talk) 00:28, 10 November 2013 (UTC)
Robert Horning, I find it hard to imagine experienced editors who have created plenty of articles ever agreeing to give up the ability to create pages in mainspace. Neljack (talk) 08:49, 10 November 2013 (UTC)
You say that, but I've seen discussions on the Village Pump (usually the policy area) where this attitude of no mainspace article creation (at least for brand-new articles) has been stated as a fact of policy, even if it was refuted not much later in the discussion. It drives the New Page Patrol crowd where there is most definitely an overly aggressive attitude toward squashing any new articles in the main namespace. I could point to other discussions about this, but I am pointing out that this is a significant concern which needs to be explicitly addressed in a proposal of this nature. I agree that there would be a holy policy war if it ever became actual policy to stop mainspace article creation by experienced users, but I do perceive this as a back door approach to making such a policy. --Robert Horning (talk) 19:34, 10 November 2013 (UTC)
If you are meaning that some editors would advocate for all articles having to be reviewed before being moved into the encyclopedia, then I agree with you; first of all, there aren't likely ever to be enough reviewers to look at them all, and secondly, it's a waste of time reviewing articles by experienced users unless they are COI articles, and slows article creation down as well. However, if you are just meaning that users would have to create an article "User:Me/My article" and then move it to "My article" when ready, rather than creating "My article" instantly, that's what I do already except for the occasional disambiguation page. —Anne Delong (talk) 01:13, 11 November 2013 (UTC)
  • I think that this is a possibly very good idea, if well implemented. I think the change allowing continued use of userspace for drafts was a good one. I foresee a three-teir structure: userspace for notes, fragments, and 'private' drafts that the user is not ready to encourage collaborative development on, drat space for public drafts on which collaboration is minvited, inmcluding the sort of reviewing that AfC does now, or one-on-one mentorship, but in which notability requirements are for the moment waived, and mainspace for articles where all policies including notability are in fill force. Then all we need are more volunteers willing to do reveiwing and soem training on how mto do it well, and perhaps editor retention will significantly improve. DES (talk) 14:36, 10 November 2013 (UTC)
  • This should be one of the WP:Perennials. It's a lot like "WP:VPP/Allowing users to keep private drafts of their work" from 2012 (around this same time of year!), which suggested an extension to Mediawiki, and passed supported, but resulted in no change. As then, I support almost any provision which permits slow-going draft development without prejudice. My main concern is that such drafts should have absolutely no public visibility or searchability (only registered editors can see/search) - the principle is that you can't violate policy and merit sanctions if nobody can see your work in progress, or happen upon it accidentally. Our current ineffective sop: __NOINDEX__ is weak tea. --Lexein (talk) 00:41, 12 November 2013 (UTC)
  • With the clarification that 'the proposal now provides a guarantee that users may indeed retain and create drafts in their userspace', as a newbie I see value in a "Draft" space. For many newbies, I think word Draft, is easier to know that's where a new article draft should be submitted.--Andrea edits (talk) 06:07, 15 November 2013 (UTC)

I would love to hear more of what active AfC volunteers think of this proposal. You know, the folks who are actually working to reduce the backlog. I did a quick-and-dirty crosscheck of people who signed up at Wikipedia:WikiProject Articles for creation/Participants, and among those, 8 have voted yes and 2 have voted no. I just thought that was interesting. – Quadell (talk) 23:48, 17 November 2013 (UTC)

Or 9 yes-votes, now that I can count myself. – Quadell (talk) 20:00, 19 November 2013 (UTC)

A solution in search of a problem???

I see comments that this is a "a solution in search a problem", and I want to remind you-- the problem exists. The first step to solving any problem is admitting its existence, and Wikipedia has a problem. We peaked in active users in 2007. Our editor community has been 'decline' for six years now.

We've studied the problem, and we know what's happening. Our new users aren't sticking around. They're coming, editing once, having a bad experience, and leaving.

I conducted an experiment, you should too. Create a new user account and with your first edit, create a new article in the way a brand new user would-- no wikitext, simple words, write only a sentence or two, and don't link to any sources (while making sure there are good sources out there to be found with a google search). WP:Requested Articles is good for ideas.

I conducted this experiment recently, creating a new username, making my first edit be a new article about an obscure subject that could be verified to exist with a good search. Now sit back and see if your article gets rehabilitated or deleted.

I did this test, made my edit and sat back and watched. Within 1 minute (seriously, ONE minute), it had been CSDed. I contested the deletion as new user might, and the article was deleted over my protestations within 16 minutes of its creation. I received no human communication, just the standard CSD template placed on my talk.

Now none of this hurt my feelings because I'm an experienced user. But if I were a genuine new user and this was my introductory experience, would I ever come back again???

It's not a solution in search of a problem. It's a problem that's caused us to spend six years searching for a solution. --HectorMoffet (talk) 03:33, 10 November 2013 (UTC)

I think "solution in search of a problem" is largely due to the way the watchlist notice for this proposal is worded. It just mentions proposing a draft namespace, without mentioning why. Most people will (actually, quite understandably) make an angry snap judgment due to the fact that all articles on Wikipedia are merely "drafts", and anyone who feels the need to "draft" already has several options. They don't read through the proposal to find out about the problem of new users not being able create articles on their own that won't get deleted, nor that the system we've been using to deal with this isn't running efficiently because it's only been half-implemented.
People see "draft namespace" and think someone figured it would be something that's nice to have. I know that's what I would've thought. Granted, I probably would've read the proposal -- but I'm the sort of guy who's into proposals. The general public doesn't work that way. PS. I mentioned this at the watchlist notice page. equazcion → 04:03, 10 Nov 2013 (UTC)
Maybe we should re-titled it the "Multi-user Drafting" namespace (to distinguish between userspace drafts). Or perhaps an apt name would be the "Mentorship" namespace-- something that emphasizes it's a namespace allocated to fix an unsolved problem, rather than a replacement for our existing userspace drafts or a straight-to-article editing ability. --HectorMoffet (talk) 04:53, 10 November 2013 (UTC)
I agree with HectorMoffet above that current NPP is too quick on the triger and too hostile. This is, of course largely becaue they are streached thin, and there is a LOT of junk posted every day. But a draft namespace and tools combined with good reviewing might help alleviate this a bit. This is at least a possible orpartial solution to a huge problem. DES (talk) 14:40, 10 November 2013 (UTC)

Current AFC volunteer:Couple things:

  1. I know that some AfC volunteers set a significant bar to pass in order to promote a submission out of the AfC space, which is good.
  2. The reason why AfC uses the Wikipedia talk space is because of the technical prohibition of unregistered editors creating a namespace page.
  3. There is already a reaper process that comes through and works on submissions that are effectively abandoned. It is called CSD:G13.
  4. Under the strictest interpertation of the CSD, the Wikipedia Talk pages do eventually get removed (unless the editor keeps sneaking around the deadline).
  5. If the community makes this authorization several bots/guidelines/procedures/tools will need to be re-written to support both locations, and then eventually deprecated off the WikipediaTalk location.
  6. For all the arguing that is being done here, there's 975 pending submissions that need reviewing. Hasteur (talk) 21:31, 14 November 2013 (UTC)
  • One thing that puts me off looking at AfC is the number of BLPs about borderline notable people, sports clubs, bands etc. I think it would help immensely if articles at AfC were categorised. A few dozen catagories to loosely sort the type of article would help reviews find articles that they are knowledgeable about.Martin451 00:32, 17 November 2013 (UTC)

Current difficulties in searching Wikipedia_Talk because of all the AFC results

Have you tried going to advanced search and looking for something in wikipedia_talk namespace? You get overloaded by article text AFC results.

This is, effectively, a bug-- one that can be easily fixed by creating a namespace. --HectorMoffet (talk) 00:03, 13 November 2013 (UTC)

I have the same problem in the WP: namespace due to AFDs. I keep wishing for a "don't search the subpages" filter. WhatamIdoing (talk) 01:53, 13 November 2013 (UTC)

There should be some kind of progress tracking on an article, launching it when it's good enough. Maybe also some specific tags that note what the particular draft needs. HTMLCODER.exe (talk) 23:00, 15 November 2013 (UTC)

Technical Feasiblity and Implementation

Tracked in Phabricator
Task T59315

Could someone with the technical expertise (and preferably from WMF) please tell us if a new namespace is actually technically possible, and whether the WMF would be willing to implement that if the consensus is in favour of this proposal? TheOriginalSoni (talk) 19:05, 7 November 2013 (UTC)

Officially, I can say yes this is a definite possibility, though I can't commit to a deadline just yet. It is technically quite feasible to make a new Draft namespace, and I think this is potentially a great idea. I do have some reservations about points 3-6, since if we create a new Draft namespace, we probably want to ...
  • roll it out across Wikipedia language editions, so certain technical aspects of it (like editing and moving permissions) may not be appropriate to hard code based solely on English Wikipedia policy
  • I think when it comes to questions like "What kind of drafts should we delete immediately?", "Can users publish their own drafts, or do we force them to be reviewed by someone with a relevant userright?" or "How long can we let drafts sit unedited before deleting?" we should take an approach driven by data. This means that we would need to run controlled experiments with different groups of new users, to see how different approaches to draft creation and management work. That way, we can design a system based on rigorous, objective results rather than just our well-informed guesses based on experience with AfC and so on. My team has the time, engineering resources, and remit to run these tests for sure. In fact, we just started basic design documents and research work exploring the topic of article creation.
In the long run, I think we should really consider whether we want to replace AfC and the Incubator with a proper Draft namespace. I fully agree with your summary bullet points above, TheOriginalSoni. Having multiple competing methods for creating an article is very confusing for new people. There are so many options, and they have a hard time evaluating the many options. If we test a new Drafts creation system well, we can compare its results (in terms of article quality and new editor retention) objectively with AfC, and really compare the two approaches to mmake a call. Steven Walling (WMF) • talk 00:07, 8 November 2013 (UTC)
  • Regarding rolling out the namespace across several languages, I think that issue can be easily resolved by having Draftspace itself have any attributes necessary in all the languages, and locally enforcing the rest of the rules in the English Wiki through various measures. Would that solve the issue?
  • I completely agree with the point that we ought to be using research in our favour to understand what works and what doesn't. I personally do not know what kind of experiments would answer which questions, but something of this sort would be but helpful. TheOriginalSoni (talk) 10:53, 8 November 2013 (UTC)
  • As I have said somewhere previously, I'm surprised that the WMF is taking a sudden interest in this. In my experience, the hunger for stats before they will approve community consensus can delay a proposal like this for anything up to a year. I think if we concentrate on simply creating the extra namespace - which can be done in a few minutes - the community would be able to decide through further RfCs what they want to do with it and the AfC programmers will have something they can devise their new scripts (and/or permission levels) for. I'm sure it's immediate use would be at AfC, and as regards whatever happens to userspace drafts, let us not forget that this 'draft' namespace proposal was born directly out of a need for it expressed during an RfC concerning AfC. Perhaps this current RfC attempts to address too many things at once. Kudpung กุดผึ้ง (talk) 11:31, 8 November 2013 (UTC)
    • I was curious about that as well. My possibly wishful thinking tells me that the WMF isn't sure how to handle the article creation issue and is welcoming what they see as a viable partial solution that's at least innocuous. Perhaps related and a bit more realistic is their wanting to repair some damaged PR from the WP:ACTRIAL incident, by being accepting of something that's again rather innocuous in comparison. equazcion → 11:44, 8 Nov 2013 (UTC)
      • The reason I'm interested in this proposal is because...
  1. Within the WMF, we've seriously discussed proposing this idea ourselves all the way back to 2011-12. Barring any disagreement over the particulars, it has wide support within Foundation engineering. So I'm gung-ho about supporting this RfC (with revisions, such as allowing userspace drafts still) because if the community clearly supports a proper Drafts namespace, this means editors and the WMF finally agree on something for once. ;)
  2. My team put article creation work on our year's roadmap months ago (see our 2013-14 goals description). We're focusing on this because our job is to attract and retain more valuable new contributors to the encyclopedia, and a large proportion of newcomers are joining Wikipedia to create a new article. (I'm not in a huge hurry to get started building things; we're still in the design stage and we need to collect some basic data as well.)
To be totally honest, regardless of the outcome of this particular RfC, I want to test asking new article creators if they want to start a draft first before publishing to mainspace. At first, "draft" might lead them to a userspace draft, but in general myself and the designers want to get data on what the reaction of new editors will be to the concept. About the ACTRIAL thing: I have no qualms about the outcome there, though I wish we'd said our peace sooner rather than at the last minute. Steven Walling (WMF) • talk 17:50, 8 November 2013 (UTC)
Steven, I am really thrilled that the Foundation sees the request for this draft namespace as positive, especially as one staff member has vociferously claimed that AfC is not within the Foundation's remit. Some requests to the WMF get no response at all, while other threads with the Foundation about AfC start well, but are left hanging for a continuation.To be also totally honest however, where anything up to 80 - 90% of the submissions at AfC are unmitigated junk or even blatant vandalism, from the AfC point of view I am not specifically concerned with the opinions of where the registered creators of the 10 - 20% genuine articles prefer their drafts to reside because for the very reasons ACTRIAL was declined, registered users cannot be forced to submit through AfC or pass through the Article Wizard (although many do because they think they have to - not a bad thing really). If your intended research is for rebooting development of Brandon's truly brilliant Article Creation Work Flow that the WMF later decided was not important, then I'm all for it especially if the community is involved in its development and I would work hard again to help with it, because a proper landing page, in spite of WP:ACTRIAL, is still not available over 2 years later.
The olive branch we were given in response to the harsh way in which ACTRIAL was declined (although I accept the philosophical reasoning) , has still not addressed the core issues and suffers from the same ailments as AfC. If this RfC closes with consensus for the draft namespace, all it needs is a minor tweak to the site software - the community would be suspicious of a reaction from the Foundation on the lines of: "Well, yeah, but we're not going to make that tweak until we've done our own research", especially where you would not even allow the testing proposed by WP:ACTRIAL - the key morpheme in that acronym being trial. Such projects as those however, require excellent, unbiased, coordination between the Foundation and the community, rather than forcing top-down solutions on the editors and and on the regular voluntary clean-up brigades, who, with all due respect, often already know best what they need for the benefit of the control of new articles on Wikipedia. Kudpung กุดผึ้ง (talk) 04:02, 9 November 2013 (UTC)
Believe it or not, I actually worked on an extension implementation of Brandon's Article Creation Workflow. The main reason it never saw the light of day is because no one could agree on a good workflow for drafts. Maybe if we had a drafts namespace, it could be revived, although I think Steven's team might have bigger and better ideas at this point. Kaldari (talk) 06:08, 9 November 2013 (UTC)
I am happy to see that we're continuing to allow users the choice of continuing to create in userspace. However, I think we need to provide the user advice on this. Default should create to draft space, with a note to the user that they could instead create the article in their user space, with a rationale as to why that might be appropriate/inappropriate and helpful/unhelpful to the user. Dovid (talk) 02:50, 10 November 2013 (UTC)

A solution to AfC?

Several people have commented that this will be a huge improvement to AfC, or a solution to AfC's current problems and backlog. They have mentioned the somewhat kludgy nature of the AfC mechanism (using what is nominally a talk page for a content page, and mixing comments and content on the same page) and have opined that a clumsy or awkward workflow is the main source of AfC's issues. Are they right? I think this proposal, if implemented would alow a somewhat better workflow at AfC or some similar process. It would allow some of the current kludge to be dropped. However I have done a number of reviews at AfC, although not as many as the true regulars there. I didn't find the somewhat kludgy tools to be a significant obstacle. I don't think they increased the time I spent by more than 5%, 10% at most, and perhaps less than that. The real obstacle to AfC is the shortage of reviewers, particularly good careful reviewers, ones willing to work with novice editors to a degree, ones who can spot a promising article that is not yet ready for mainspace and encourage or help the inexperienced editor to get it ready, and on the other hand, ones who do not demand B-class or better before they approve a draft. Without a sustained commitment of volunteers, and perhaps a program to teach the skills of good reviewing, the problems of AfC or any successor process will, IMO, continue. No technical solution can fix this until we have a compute capable of writing decent articles on its own :). DES (talk) 14:54, 10 November 2013 (UTC)

There are so many usability issues with AfC, I could go on forever about the way better software could ease things. However, I'll give a couple examples of ways we could have tools that bring in more and better reviewers...
  1. Right now, literally as soon as I save my AfC draft, I see a big green button telling me to proceed with requesting review. My draft could be empty or just one sentence, but I am being told to go forward with the process. Very basic software could fix this issue, and not tell users to request review until there is more content worth reviewing. This would save time for reviewers.
  2. We have a notifications system that delivers things to your attention when you're on-wiki, or via email. In the future, we could easily develop reviewer lists based on topics of expertise; for instance, WikiProject Med and Military History have a lot of expertise and manpower to lend to reviewing articles of those topics. There's no reason why we couldn't let people opt-in to get review requests for topically relevant drafts. (Or all new drafts, for that matter.) Carefully used notifications could pull more reviewers in to the process at the right time, rather than hoping we can get hundreds more people in to the habit of going to comb through the entire list of drafts.
These are just a couple small ideas. There are a lot more out there, and they're ways software can be used to accomplish community goals in improving draft reviews. Steven Walling (WMF) • talk 23:53, 10 November 2013 (UTC)
  • I have a question, if it has been addressed, please excuse this redundancy; but I think it is important. Will this new name space allow IP editors to create pages? If not, it will do nothing to support AfC's charter, which was to bridge the IP's inability under the software's technical restrictions. IIRC, this is why AfC coordinates reviews from the talk page as well. If IPs can not create pages in the draft name space, how will you compensate an IP editor who wants to create an article?—John Cline (talk) 01:59, 11 November 2013 (UTC)
    • It wasn't explicitly mentioned in the proposal, but since this is one of the key reasons for creating a draft namespace in the first place, I expect that when we go in for the implementation, it will be ensured that IPs can create new drafts in the proposed namespace. TheOriginalSoni (talk) 08:25, 15 November 2013 (UTC)

Steven, I've touched on this several times in various places, but I'm not seeing any direct response: A colleague of yours has emphatically stated that AfC is not within the Foundation's remit; how do you reconcile this from your WMF signature with nevertheless welcome comments about "...and they're ways software can be used to accomplish community goals in improving draft reviews" if that software can only be implemented by the WMF? Kudpung กุดผึ้ง (talk) 09:10, 15 November 2013 (UTC)

Draft namespace work and AfC are not the same thing. AfC's technical implementation was done 100% without WMF assistance using community-owned tools like bots, gadgets, and templates. Unless somebody asks for help or if they create a larger technical problem (like gadgets that slow the site down), changing those things is not in our remit. A Draft namespace requires WMF staff to change the configuration of the site. Steven Walling (WMF) • talk 21:38, 15 November 2013 (UTC)

Two-letter acronym for this namespace?

I'm going to throw out this proposal in here to see some thoughts: if this namespace is created, should there be a two-letter acronym/shortcut designated for the "Draft:" namespace? Unfortunately, the "D:" shortcut was recently assigned to Wikidata (so, unfortunately, that option is out.) I think that if there was to be a two-letter acronym/shortcut for this namespace, it could be either "DR:" or "DT:" Any thoughts on this? Steel1943 (talk) 09:58, 15 November 2013 (UTC)

"DT:" is no good, as it would be too easily confused with the Draft Talk namespace. Too bad about "D:", though. VanIsaacWS Vexcontribs 11:53, 15 November 2013 (UTC)
It's a whole 3 letters you'd be saving, and I doubt draft pages would be linked as often as Wikipedia-namespace pages that the savings would be worth it. WP:PEREN#Create shortcut namespace aliases for various namespaces goes into more detail on reasons previous proposals for additional namespace abbreviations have been rejected. Anomie⚔ 13:16, 15 November 2013 (UTC)

Votes

It is requested to keep the votes section free from discussion threads, and try and keep discussions limited to mostly the discussion section above.

Note to RfC closer: Some votes and concerns were voiced prior to the revision regarding User space drafts. Please take this into consideration when determining consensus. Steel1943 (talk) 09:44, 15 November 2013 (UTC)

Support

  • Support - As proposer. TheOriginalSoni (talk) 19:05, 7 November 2013 (UTC)
  • Strong support - with one reservation that I have replied to in BD2412's comment above. Kudpung กุดผึ้ง (talk) 20:03, 7 November 2013 (UTC)
    • Note that Kudpung's concerns have been addressed, and the offending terms removed from the proposal. equazcion → 21:30, 8 Nov 2013 (UTC)
  • Strong support - as long as the point about userspace drafts is resolved. Matty.007 20:27, 7 November 2013 (UTC)
  • Oppose until the proposal is modified as Kudpung suggests' DGG ( talk ) 21:10, 7 November 2013 (UTC) Changed to: Support the modified proposal which addresses the concern. DGG ( talk ) 14:43, 8 November 2013 (UTC)
  • Support Kudpung's concern is valid, but I think we can work that out easily as I noted above. This is with the caveat that we don't just bulk delete userspace staledrafts without plenty of notice to the user, and that we do retain some convention for not-ready-for-public drafts such as I proposed above. Gigs (talk) 21:27, 7 November 2013 (UTC)
  • qualified support. I think the general idea of centralizing draft articles is a good one but users should still be able to retain the option to draft in userspace. Beeblebrox (talk) 21:32, 7 November 2013 (UTC)
  • Qualified support I think we should take an experimental approach to this, objectively testing out how a new Drafts namespace should work. But I think that the answer whether we should try this out is a most emphatic Yes. Steven Walling (WMF) • talk 00:08, 8 November 2013 (UTC)
  • Support with the caveat that (as consensus seems to be supporting) user space drafts are still allowed. BOZ (talk) 00:18, 8 November 2013 (UTC)
  • Support. I don't think it's a great idea to oppose a proposal based on the fact that you predict others won't support it (in response largely to portions of Sven's comment above), as people can tend to pick up that trend ("I agree: I don't think this will gain enough support as proposed"), and then good proposals die based on something imaginary and we never really know if support was there. I think drafts can be allowed in userspace, but won't oppose because my ideal version of this proposal isn't currently posted here (another good way to kill good proposals) -- but the precise rules can be tweaked later based on discussion. Even if we do allow userspace drafts, I think experienced users will opt for that when they want to develop something privately, and the new Draft namespace will get the brunt of the AFC submissions (as that will be the default path where AFC directs users). equazcion → 00:41, 8 Nov 2013 (UTC)
    • You're missing the point of my oppose. The point of my oppose is that "drafts can be allowed in userspace" is the consensus, and the Draft namespace makes no sense when combined with "drafts can be allowed in userspace" because the proposal was put forth largely to address the issues caused by "drafts can be allowed in userspace". Sven Manguard Wha? 02:29, 8 November 2013 (UTC)
      • I addressed that, more towards the end of my comment. The proposal's necessity doesn't lie in userspace drafts being allowed, but in that they've always been directed to reside there. The proposer is taking this a step further in saying we won't allow them, as s/he appears to think (as you apparently do) that without a prohibition, article drafting will still tend to wind up in userspace -- but I don't see any reason to think that. Rather the opposite, the inexperienced users submitting articles through AFC won't have any such preference and will go where directed. We can still allow userspace drafting so that experienced editors who prefer that can still do so. equazcion → 03:20, 8 Nov 2013 (UTC)
  • Qualified Support - Sounds like a great idea generally but I agree with the concerns of Kudpung. Samwalton9 (talk) 00:43, 8 November 2013 (UTC)
  • Qualified Support. Would be a boon to AfC. Same reservations as others above about userspace drafts, as they're fairly innocuous and enforcing this aspect too vigorously could annoy more than it helps. But overall, this would be a good thing. --LukeSurl t c 00:45, 8 November 2013 (UTC)
    Amending !vote as the problematic part of the policy has been rescinded. --LukeSurl t c 12:58, 8 November 2013 (UTC)
    Furthermore, capability to shift wholly inadequate articles on notable topics to the Draft namespace (as an alternative to deletion) is very appealing. --LukeSurl t c 13:43, 8 November 2013 (UTC)
    A new namespace means that drafts will have talkpages, which is very much desirable. And additionally, when FLOW comes in we won't be able to use the Wikipedia_talk namespace anyway, and will have to think up some new hack. Creating a Draft namespace is the only logical solution to that future problem. --LukeSurl t c 15:56, 19 November 2013 (UTC)
  • Conditional Support. We should still allow drafts in userspace, but at the same time point new editors towards the new namespace in order to better screen out attack/spam/copyvio pages. MER-C 03:31, 8 November 2013 (UTC)
  • Oppose unless the userspace-draft prohibition is removed. – Ypnypn (talk) 03:32, 8 November 2013 (UTC) Support -- Ypnypn (talk) 23:25, 9 November 2013 (UTC)
  • Conditional support, so long as nominally active editors are permitted to keep drafts in userspace. bd2412 T 04:09, 8 November 2013 (UTC)
    What's wrong with inactive editors having drafts? Legoktm (talk) 05:52, 8 November 2013 (UTC)
    We have a lot of stuff in userspace from editors who are highly likely to be gone forever. Some of it is garbage and will never be an article, or anything else useful to an encyclopedia. Some of it is quite useful, but because the user is gone, it will just never be brought up to a standard to be moved into article space. bd2412 T 14:48, 8 November 2013 (UTC)
  • Conditional support - I like the idea in general, as long as userspace draft are allowed. I can see myself moving my draft from my userspace to draft space when the draft is nearly complete, but needs some colaboration to finalize the article. - BilCat (talk) 09:55, 8 November 2013 (UTC)
  • Support the general idea of a draft space. This has a number of potentially attractive possibilities that can be explored and developed. There is much that still needs to be discussed - but I think it would be inappropriate to reject an interesting idea at this stage because there are still points to discuss. Along with points regarding retaining userspace drafts, there are also questions such as: How visible would the draft articles be? Though not accessible to search engines, would general readers be offered access during a search? (We don't have an article on "Places of worship in Malvern, Worcestershire", but here is a draft version that editors are working on, and which you may be able to help out with). If at AfD an article is deemed not yet notable we have the option to userfy - the draft space would be an appropriate alternative. But what procedures would we adopt for when an article can be moved from Main into Draft space - and who would be given permissions to do that? Any user, or just admins? I think there's lots to discuss. I think this is an interesting idea that has legs. Let's help it walk! SilkTork ✔Tea time 10:36, 8 November 2013 (UTC)
  • Support per Beeblebrox. Seems important to me that we grease the wheels of processes helping new users create articles Jebus989✰ 13:54, 8 November 2013 (UTC)
  • Support now that the proposal has been adjusted to allow userspace drafts to be retained. This way new editors woould be directed to the Draftspace and only experienced users would know that they have the option of creating semi-private drafts in their userspaces, and that's probably just as well. Bryanrutherford0 (talk) 14:05, 8 November 2013 (UTC)
  • Support I sounds like an amalgamation from existing spaces. More clarity is always welcome. The Banner talk 15:25, 8 November 2013 (UTC)
  • Support. This newbie sees structured Draftspace as good 'guide'. Don't see value in removing private draft spaces for folk with WIP.--Andrea edits (talk) 15:51, 8 November 2013 (UTC)
  • Conditional support, iff the prohibitions on userspace drafts and proposals to automatically move them are removed from the proposal. I could not support with these, but like the idea otherwise. Seraphimblade Talk to me 16:04, 8 November 2013 (UTC)
    • Those were already removed from the proposal a while before you voted :) equazcion → 21:30, 8 Nov 2013 (UTC)
  • Support It is in our best interest to get AfC and all draft work better organized. There is already so much to do at AfC for volunteers and bots, and this seems like a good way to "formalize" the process. I agree that this doesn't actually solve the core issue, but neither does this increase bureaucracy to be honest. If anything, this helps keep things sorted and simple for new users. Just because currently many drafts are in userspace and hidden out of sight, doesn't make them not a problem. At least this proposal moves in the right direction. —  HELLKNOWZ  ▎TALK 18:11, 8 November 2013 (UTC)
  • Support — This is not a solution in search of a problem. Admittedly, I like my userspace, and, given the comments above and below, editors should remain able to create personal drafts in their own userspace. However, a "Draft" namespace would better organize the article creation process, and includes some added side benefits. Each draft, for instance, could have its own talk page, and VisualEditor may be enabled to better help new editors format their drafts. In the end, we will have an improved article creation process. The purpose of this RfC is to simplify things, not to add complexity. We have many confusing namespaces now, and this proposal will help alleviate that issue. Michaelzeng7 (talk) 21:56, 8 November 2013 (UTC)
  • Support. Consolidating to a Draft namespace will simplify things for new users, and also help us to improve tools and workflows in the area. Any users who wish to keep their drafts in userspace should be allowed to do so though. the wub "?!" 22:57, 8 November 2013 (UTC)
  • Sure. I wouldn't use this, but I wouldn't want to stop other people using it if they wish.—S Marshall T/C 23:44, 8 November 2013 (UTC)
  • Support. I couldn't have supported the prohibition of userspace drafts, but I see that provision has been dropped from the proposal. Apart from that, I wholeheartedly support this move to get rid of the ancient "Wikipedia talk:Articles for creation/" hack and put draft articles in a more sensible location. — This, that and the other (talk) 00:01, 9 November 2013 (UTC)
  • Conditional support based on the non-exclusion of userspace drafts like User:SarekOfVulcan/Bangor Band (which I see has been dropped, but still conditionalizing). --SarekOfVulcan (talk) 01:20, 9 November 2013 (UTC)
  • Support. The lack of talk pages at AfC hampers discussion and wastes a perfect opportunity to acclimate new users to the joys and pains of the Talk: namespace. This would also prevent some cases of duplicated work; right now someone who wanted to create Sahlins–Obeyesekere debate would have to start at square one, without knowing that I have already begun a draft. —Neil 01:23, 9 November 2013 (UTC)
  • Support I found it hard to understand there was a draft area available.Saltybone (talk) 01:48, 9 November 2013 (UTC)
  • Support. As currently written, this seems like a good idea: have a centralized place for maintaining article drafts, while leaving users to maintain their own userspace. —Gordon P. Hemsley→✉ 02:36, 9 November 2013 (UTC)
  • Support. Good idea, and good timing for it. Let's move these drafts out of projectspace and into draftspace, but leave userspace alone. -- œ™ 03:35, 9 November 2013 (UTC)
  • ConditionalStrong Support per User:Steven (WMF) above. Let's try it out first; Condition: leave username-space drafts alone. Perhaps this could be privilege added at the start of the program for experienced editors, and thereafter as a license (such as "rollbacker") for the less experienced to strive for. GenQuest "Talk to Me" 06:08, 9 November 2013 (UTC)
  • Support in principle, provided this does not affect current policy allowing userspace drafts to remain. —sroc 💬 09:33, 9 November 2013 (UTC)
  • Support. I often see reasonable articles getting deleted due to being slightly under the notability guidelines or because they are not quite good enough, only to end up having to be completely be rewritten a few months later (wasting a lot of time). The draft namespace would let us just move these articles to this new space, allowing them to be worked on before being moved back. Although there is an article incubator, it seems to me to be near useless, very little work actually seems to get done on those articles. Cliff12345 (talk) 13:41, 9 November 2013 (UTC)
  • Strong support. It's not 2003 anymore-- back then if you showed up as a brand new user and with your very first edit, you made a new article, it virtually never got deleted. We were so happy to see a new user, we would rehabilitate any new article. But now, we're the planets #1 reference source, and our standards are so high that a new user trying to create a new article on their first edit is virtually doomed to failure. A "Draft" namespace would go a long way to creating a "safe space" for newbies to get their feet wet without stepping on our toes. --HectorMoffet (talk) 18:51, 9 November 2013 (UTC)
  • Qualified support only as a technical fix to simplify some aspects of AfC.
Outside AfC though, we should still encourage early publication of notable topics in articlespace for further collaborative editing (a hellish combination of deletionist taggers and a shortage of low-hanging fruit seems to have killed this dead of late). We should also still permit and encourage userspace drafting by registered editors with access to userspace. Andy Dingley (talk) 00:14, 10 November 2013 (UTC)
  • Support Dovid (talk) 03:31, 10 November 2013 (UTC)
  • Weak support - I'm not really convinced that this will address the stated problem (I doubt that the slight confusion as to where AFC drafts go has a significant impact on new editor retention). But at the very least this is a technical improvement over the hacky AFC subpage pseudo-namespace that we're currently using. Mr.Z-man 04:39, 10 November 2013 (UTC)
This guy gets it! :) . Even if you don't expect it to help much, let's at least give the Wikimedia Foundation techies the latitude they need to make technical improvements to enrich the new user experience. --HectorMoffet (talk) 05:14, 10 November 2013 (UTC)
  • Support As others have said, would hopefully address some of the issues with AfC. Neljack (talk) 08:50, 10 November 2013 (UTC)
  • Support While it's obvious that the organization would help established editors with AFC organization, I consistently see new users asking for help in IRC that are confused about the technicalities of AFC (for example "where is their article") and I think this new organization will help them even more, because it is simply intuitive. --Shirik (Questions or Comments?) 09:06, 10 November 2013 (UTC)
  • Support A Draft namespace, as outlined in the proposal, seems like just what the wiki needs to consolidate the various places new or in-need-of-improvement articles currently reside. Should make article creation easier for new users too. Novusuna talk 11:27, 10 November 2013 (UTC)
  • Qualified support with the caveat userspace drafts are excluded (among other things, managing what constitutes a userspace draft and what doesn't would make this proposal unworkable). SFB 11:47, 10 November 2013 (UTC)
  • Strong support This would go a very long way to solving many of the limitations and restrictions that the AfC process is struggling under. The kludgy system AfC currently uses is hopelessly inadequate. Roger (Dodger67) (talk) 12:02, 10 November 2013 (UTC)
  • Support This would have been qualified before the changes removing the ban on userspace drafts. See my comments in the discussion above for more reasoning. DES (talk) 14:42, 10 November 2013 (UTC)
  • Sure, it's at least a step in the right direction to help new editors overcome the nearly vertical learning curve that can be so frustrating. --SB_Johnny | talk✌ 15:15, 10 November 2013 (UTC)
  • Support. This will help the AfC backlog, as well as to organize it. As for userspace drafts, being as they can be kept, if an editor truly wants to benefit the project, then they would have no objections to moving their userspace drafts (which could be possibly stale and infrequently worked on) to the Draft namespace, where it would be easier for other editors to find and improve them. I feel that more editors would be willing to help with drafts if they were centered in the new namespace. — TheJJJunk (say hello) 15:30, 10 November 2013 (UTC)
  • Strongly Support. This might be a good thing to do for people that are creating articles with very advanced embedded information. 𝕁𝕠𝕣𝕕𝕒𝕟𝕂𝕪𝕤𝕖𝕣𝟚𝟚 19:36, 10 November 2013 (UTC)
  • Conditional Support - As I mentioned, it would be an excellent way to combine the AfC and Article Incubator projects. There is a huge need for a Wikiproject to support this endeavor as well, where espcially new users shouldn't be left to their own devices. I see the need for some policy changes as well that would specifically address how interaction with the draft namespace works (perhaps lower bars on deletion policy). I really don't think the MfC process would be good for drafts as well, so my point here is that the proposal needs some refinement and improvement, but the overall idea is good and sound as far as it goes. The use of a specific namespace also enables a number of tools for admins and people genuinely wanting to help out with assisting new users and perhaps clearing out a huge backlog of people really needing help. At worst, this simply becomes a dumping ground for experiments and a sandbox that can be cleared out routinely. --Robert Horning (talk) 19:53, 10 November 2013 (UTC)
  • Support - A good idea that would be useful for multiple users to work on an article before making it go live. --GrapedApe (talk) 22:50, 10 November 2013 (UTC)
  • Suppot - Great way to organize drafts will be easier to search for one as well. ///EuroCarGT 00:31, 11 November 2013 (UTC)
  • Support only if userspace drafts are still permitted, as per the modified proposal --Aude (talk) 00:46, 11 November 2013 (UTC)
  • Support - This would actually be a boon for many problems, aside from just bouncing of AFD, the draft space could be an active area for piecemeal revisions to article content that is contested. This would more readily allow cooperation and interaction instead of bouncing one person's ideas off in contentious arguments. There is something to be said for talking a problem section, proposing a new wording on a separate slate and allowing people to take an rearrange those pieces before ultimately inserting it into the article. ChrisGualtieri (talk)
  • Weak support I don't see how this will help with the AfC workflow as that seems to be more closely related to manpower and organizational challenges but this proposal seems innocuous and may be a step in the right direction. There is also merit in achieving an "easy win" with an small change that is supported by the WMF staff so we can help repair a very damaged relationship between the foundation and the en.wikipedia community. ElKevbo (talk) 15:42, 11 November 2013 (UTC)
  • Support - with emphasis on importance of keeping userspace drafting available, and also like the idea above of article creation in mainspace being a reward that you can access after a certain level of project involvement and editing experience - perhaps a mix of editing, reviewing, policy discussion etc Depthdiver (talk) 04:48, 11 November 2013 (UTC)
  • Support This needs to be done. Flow soon will take over talk pages, and we need somewhere for the IPs to create "articles" buffbills7701 00:41, 12 November 2013 (UTC)
  • Support - This will improve the project by increasing participation by and retention of new editors. Jojalozzo 02:02, 12 November 2013 (UTC)
  • Support - Seems like a sensible way to move all the draft work into one place. -- King of ♥ ♦ ♣ ♠ 03:20, 12 November 2013 (UTC)
  • Support. This proposal, in and of itself, does not solve any problems. However, it's a start in the right direction. Having a separate draft namespace will enable us to develop improvements to MediaWiki that take advantage of this namespace and help with the article creation process. --(ʞɿɐʇ) ɐuɐʞsǝp 17:56, 12 November 2013 (UTC)
  • Support as long as userspace drafts are still allowed (and they are). AutomaticStrikeout (₵) 17:58, 12 November 2013 (UTC)
  • Support. We are going to need a place for AfCs when talk pages move to Flow anyway, and it would be highly beneficial if AfC drafts had a talk page - for comments, tagging for submission or review, etc. Especially if we can get a namespace shortcut eg "D:", it would make pre-launch testing of templates a lot easier. Agree that userspace drafts should not be banned, but a draft namespace would also be very nice for collaborations among editors. VanIsaacWS Vexcontribs 02:32, 13 November 2013 (UTC)
  • Support - Such a namespace would benefit established editors drafting new articles before they go live. AfC seems to be geared to more inexperienced editors. Also would be preferable to userfication as it would be more centrally located to encourage collective editing and less issues of WP:OWN.--TriiipleThreat (talk) 13:28, 13 November 2013 (UTC)
  • Support as long as userspace drafts are still allowed. I don't entirely trust the survey responses about new accounts wanting to create new articles though. If respondents haven't said what article they wanted to create we don't know whether it already existed (e.g. as a section of an existing article), so the survey may be pointing to a wider problem about search. - Pointillist (talk) 23:46, 13 November 2013 (UTC)
  • Support - This namespace is a good idea and should be implemented in some form.   — C M B J   01:41, 14 November 2013 (UTC)
  • Support creating the draft namespace. The en Wiki editor community can evolve a use for it or choose to ignore it depending on what works, but I do not see any down side to having the option. VQuakr (talk) 08:39, 14 November 2013 (UTC)
  • Support, per many of the reasons already listed above. It would be helpful for editors to have a neutral location to collaboratively edit articles that aren't necessarily ready for inclusion in article-space. And as others have said, this is but one step towards helping improve the article creation process. —Locke Cole • t • c 17:23, 14 November 2013 (UTC)
  • Support combining the many ways to submit articles will simplify the process. Dan653 (talk) 22:26, 14 November 2013 (UTC)
  • Support - I don't know how this RFC started, but I've been wanting this for over a year now. When I saw this RFC notification come up, I thought that I had started this RFC in my sleep and forgot about it. But seriously, I almost started a similar RFC half a year ago ... wanting this namespace created is even on my User page since months ago! Anyways, now that I got that off my chest, I think this is a brilliant idea, and should be implemented to consolidate all drafts into one space, rather than having them in a subpage of a page in the Wikipedia namespace. I mean, these drafts are in at least three, if not four, subpages: WP:AFC, WT:AFC, and WP:AI. Completely unnecessary. Hopefully consensus agrees to the creation of this namespace! Steel1943 (talk) 01:00, 15 November 2013 (UTC)
  • Support It would seriously improve search functionality.--v/r - TP 23:33, 14 November 2013 (UTC)
  • Support This namespace seems like a good idea, as long as userspace drafts are still allowed. It will be easier to search for the drafts, and multiple users can work on it before it goes live. StevenD99 Contribs Sign 05:13, 15 November 2013 (UTC)
  • Support - 'the proposal now provides a guarantee that users may indeed retain and create drafts in their userspace'.--Andrea edits (talk) 06:27, 15 November 2013 (UTC)
  • Support as per GrapedApe. Babakathy (talk) 12:54, 15 November 2013 (UTC)
  • Support Of course the userspace drafts should be allowed, but the namespace itself will probably encourage more editors to collaborate in a more-less organized way. HÆDOreply 19:16, 15 November 2013 (UTC)
  • Support reasonable idea.--Tomwsulcer (talk) 00:03, 16 November 2013 (UTC)
  • Support, but needs work. I appreciate the revisions pertaining to userspace drafts. That said, there remains a bit of contradiction in #2 in the "Details" section above. We need to fine-tune the details of the proposal to ensure, rather than assume that we are all on the same page. Cindy(talk) 00:35, 16 November 2013 (UTC)
  • Support seems like a good idea. -- Taku (talk) 20:58, 16 November 2013 (UTC)
  • Strong support - It would be far easier for automated tools (bots, scripts) to edit/search pages in a separate namespace than with the current AFC system. Similarly, it would be much easier to post WikiProject templates on Draft namespace talk pages (or even directly on Draft pages), encouraging WikiProject editors to become involved in clearing drafts. Similarly, if a Draft page were deleted, with an explanation in the deletion log, that would make it more obvious (and easier to search) than with the current AfC pages. In short, the AfC system currently is a kludge; this would be much cleaner. -- John Broughton (♫♫) 22:45, 16 November 2013 (UTC)
  • Very weak support I support this in a very weak way. I am worried about creep, and would not want to see future attempts to stop user page drafts. Of course WP:BLP applies so does anything libellous towards companies, organisations etc. but what about other policies. A new user creating a draft that is immediatly hit with CN tags, big headers etc. could be put off, so could a new user who finds their draft ripped apart by an experienced user (or just a troll/vandal). I do however see advantages, articles could be loosely catagorised, e.g. BLP draft, scientific draft, geographic draft etc.Martin451 00:23, 17 November 2013 (UTC)
  • Obvious support - as long as we can keep our userspace drafts, then there is literally no good reason to oppose this. The entire AfC system is based on a half-baked, half-arsed hackaround; do the underlying basics properly, and then we can begin to actually tackle that dump. Hell, even the WMF are on board on this one (or some of them, anyway). Lukeno94 (tell Luke off here) 00:55, 17 November 2013 (UTC)
  • Support, since it will remove confusion about what is and what is not intended as an article draft. Disallowing drafts in userspace will also help reinforce WP:OWN (there is also WP:UP#OWN, but it seems to be widely disregarded, unfortunately). I think it will also give us a clearer picture of what userspace really is, which will pave the way for less vague policies regarding it. Although I wonder if "Draft:" would ever need to be a prefix of a real article title, which makes me a bit nervous. But maybe I am just being OCD-ish here. Keφr 07:58, 17 November 2013 (UTC)
    • It should be noted that the portion of the proposal disallowing userspace drafts was removed shortly after discussion began. The other points still stand, though. Novusuna talk 11:10, 17 November 2013 (UTC)
      • What a shame. I shall also note that since telling drafts from non-drafts would be easy (if they are allowed only in the dedicated namespace), it would make implementation of some technical measures easier. For example, a mandatory notice like {{user draft}} for the whole namespace, or enabling certain scripts only in the draft namespace. Also, it would make defining deletion criteria for drafts easier and mitigate WP:FAKEARTICLE-style loopholes. Keφr 17:14, 17 November 2013 (UTC)
  • Support, while encouraging (but not forcing) established users to use this in stead of userspace drafts. עוד מישהו Od Mishehu 15:43, 17 November 2013 (UTC)
  • Strongest Possible Support - using a talk page for drafting is awkward. Creating a streamlined experience will help reduce the "learning curve" that new users feel. theonesean 01:33, 18 November 2013 (UTC)
  • Support, this is an intuitive way to deal with drafts that newbies are likely to understand. It won't fix the most important problems, but it will make the situation a little better. – Quadell (talk) 13:50, 18 November 2013 (UTC)
  • Strong Support In addition to the reasons listed above, I'll add one I haven't seen. As an OTRS volunteer, it is common for an editor to be using some text from a website; this creates a potential copyright violation, which can be cured if the copyright holder files a permission statement with OTRS. When the text is in an ordinary article, the permission tag is added to the talk page (See Talk:Jay_Bulger for an example, if you are not familiar with the tag). Because Afc submissions are on talk pages, there is no good place to add the tag, so it has to be dropped in the article, which means it has to be separated out if the article is accepted. Not the biggest of problems, but a problem nonetheless. --S Philbrick(Talk) 21:51, 19 November 2013 (UTC)
  • Support. I very much like the concept of streamlining the three, major article-drafting zones (Articles for Creation, userspace drafts and the Article Incubator), and the proposal to apply NOINDEX-ing automatically (in a manner similar to how it is in-built in talk pages). No doubt many IP and newly-registered users unfamiliar with AfC find it odd to be creating and editing article drafts in "Wikipedia talk", and the establishment of a dedicated "Draft" namespace would help considerably in resolving this confusion. I agree, however, that migration from userspace should not be compulsory. For better or for worse, the userspace-drafting mechanism is not something that can, or should, be jettisoned lightly. SuperMarioMan 22:37, 19 November 2013 (UTC)

Oppose

  • Strong Oppose there is a clear consensus that people want to retain userspace drafts. Without that modification, this doesn't have the support to be adopted, but with that modification, the primary utility of this change is removed, rendering it largely useless. I don't like the idea of creating a redundant namespace that isn't going to be used by established users, many of whom will continue to use userspace drafts, but which may be forced upon new users, who don't have the knowledge or community standing to resist pressure to adopt the new system, Sven Manguard Wha? 00:29, 8 November 2013 (UTC)
    • Additionally (as I mentioned above) I simply don't trust the broader community not to pile so many rules and guidelines on the Draft namespace that it becomes a nightmare to work in. Sven Manguard Wha? 04:36, 14 November 2013 (UTC)
  • Oppose per "Any inactive drafts would, however, be deleted." and "Articles will no longer be allowed in Userspace". Legoktm (talk) 02:57, 8 November 2013 (UTC)
    • TheOriginalSoni Perhaps given the feedback, even from those who support the proposal overall, it could be amended to eliminate that userspace prohibition? equazcion → 03:26, 8 Nov 2013 (UTC)
  • Oppose as written. Wikipedia works because of the autonomy given to editors who can work how they like, where they like, and when they like (provided they benefit the encyclopedia and don't bother other people). Forcing people to conform to new rules for how drafts should be written would be unproductive. Also, let's not give people another thing to argue about (User:BusyBody moves [User:Example/todo] to the new location "because it's the basis for a new article"—not it's not, yes it is, no it's not...). A Draft namespace would be fine if it helps AfC (how?), but no bureaucracy please. What would be the purpose of user space if drafts are not permitted (and if Flow prevents talk page archiving)? Johnuniq (talk) 10:11, 8 November 2013 (UTC)
  • Strong oppose unless drafts can continue to be kept in userspace. I believe disallowing editors from working on drafts as they find time or material over an extended period, in the semi-privacy of their space, would be a disincentive to many of our best editors. It takes time to settle down to serious editing as distinct from general maintenance tasks which can be done during a coffee break.--Charles (talk) 10:43, 8 November 2013 (UTC)
  • Still not convinced that there is such a problem that a new layer of complexity is needed. The spam and self promotion that so many new users are only interested in writing will just sit there until eventually deleted, so they would be better left out of public view in user space until eventually deleted by speedy or MfD.--Charles (talk) 09:00, 15 November 2013 (UTC)
  • Strong oppose. Forcibly removing or deleting drafts from userspace will cause unnecessary heartache all round. I am also opposed to automatic deletion of stale drafts. Anything that has merit should be kept, moved to mainspace even. SpinningSpark 11:50, 8 November 2013 (UTC)
  • User:Spinningspark there exist draft articles that have not been edited in over a year, and possibly would not even pass notability guideleines. Wouldn't we be better off deleting them, rather than allow Userspace or draftspace to become a watershed for all articles that fail to be in mainspace? TheOriginalSoni (talk) 11:56, 8 November 2013 (UTC)
I thought - or certainly hoped - that this request for a draft namaspace was to be 90% based on a requirement for improving AfC. Maybe I was wrong. However, WP:STALEDRAFT has never really been a problem, and unless the occasional stale draft is from a user who has no other intention of contributing to the encyclopedia, and in which case the are plenty of stale drafts that go to MfD, I think that if we continue on these lines, we'll end up with witch hunts for stale user drafts and gum up our bureaucracy even more, rather than alleviate the pressures on AfC.Kudpung กุดผึ้ง (talk) 12:05, 8 November 2013 (UTC)
(edit conflict) I think that's best addressed later on, TheOriginalSoni. If/when the Draft space appears to exhibit that issue, another proposal could be discussed to impose a time limit on inactivity. Don't try to do to much right now. I would go ahead and remove the bit about inactive drafts for the sake of this proposal (no prejudice at all to it being imposed at some point though). equazcion → 12:08, 8 Nov 2013 (UTC)
(edit conflict) I personally had never thought that removal of stale drafts was really that much of a concern. If it was stale, I believe we already had policies stating they ought to be removed, which was what I felt was logical to continue. I'm not of the opinion that it should change, but once again, discussions and potential modifications of the proposals do us no harm.
(After ec) That bit about removing inactive drafts has been borrowed from AFC, where we delete inactive drafts after reasonable time (Iirc it is also six months). As I said, if others feel the same, we could decouple that out and discuss it potentially in a different proposal. TheOriginalSoni (talk) 12:16, 8 November 2013 (UTC)
I would mention in the terms above that it's merely carried over from current AFC procedure, so people don't think you're trying to impose something new there -- but have it only apply to AFC submissions, so that you really aren't imposing something new. I get the impression that attempting to impose new limits in conjunction with this will invite some continued resistance. equazcion → 12:21, 8 Nov 2013 (UTC)
  • (after ec)If you have a problem with one of my draft pages then I expect you to take it XFD where I can defend it. Summarily deleting it for some bureaucratic tidy-up mission is completely unacceptable and utterly against the principles and mission of Wikipedia. To answer your question, no, it is not better to delete drafts that have not been edited for a long time. That is an entirely bad criterion for deletion. It is ok to delete drafts that are rubbish. Ones that are not should be left alone, or even moved to mainspace. (after reading conflicting edit) As for the AFC policy, I opposed that as well, but I believe even there that old drafts are only deleted if they have not been worked on after being reviewed and rejected. SpinningSpark 12:26, 8 November 2013 (UTC)
  • Oppose Seems too much a solution for a problem which is not self-evident. Collect (talk) 12:35, 8 November 2013 (UTC)
  • Oppose It's just extra bureaucracy and complication for a non-existent problem. Editors who want to post a polished article for which they can take credit are not going to open their working drafts to the public, and those who are happy to post a stub and have the community join in expanding it are not going to bother with the "draft" process. Rwxrwxrwx (talk) 13:10, 8 November 2013 (UTC)
    • Looks like people aren't actually reading the proposal, and I think the watchlist notice was way too quick. This could've used some polishing first. I'm gonna try to add something. Edit: Did it now, hopefully it helps. equazcion → 13:15, 8 Nov 2013 (UTC)
  • Oppose This is just making up a problem that you want to exist so that you can propose a solution. We already have plenty of confusing namespaces. AfC chugs along fine. I prefer my userspace. It will turn into a kind of "other mainspace" where writers whose articles were deleted re-post articles and leave them. In short: it ain't broke, so don't fix it. Rcsprinter (talk) @ 16:08, 8 November 2013 (UTC)
  • Oppose. Solution in search of a problem. Ruslik_Zero 19:34, 8 November 2013 (UTC)
    • @Ruslik0: Did you check out the Rationale section above? The community has put in a lot of effort with helper scripts, bots, and hackishly using the Wikipedia talk namespace, but for new article creation by registered users, it's just not working. Reviews take weeks or even longer than a month. Part of this is because the tools for creating and reviewing are terrible and limited by lack of a proper namespace to put drafts. People experienced with AfC and other methods for page creation are asking for this solution because the current tools at AfC have been completely unable to handle the volume of new article submissions. Steven Walling (WMF) • talk 21:40, 8 November 2013 (UTC)
  • Weak oppose - I appreciate the concerns of the proposers but this really strikes me as adding an extra layer of complexity to wikipedia for what is essentially a backlog, however I concede that I have not edited much in the area so am not overly familiar with the problem. Cas Liber (talk · contribs) 19:38, 8 November 2013 (UTC)
  • Oppose - This proposal seems to solve nonexistent problems, while its tenets will not mitigate the highlighted problems of backlogs and scattered drafts. The AfC backlog will remain and drafts will continue being misplaced; it will simply be a new place to amass the backlog or misplace the drafts in.—John Cline (talk) 00:34, 9 November 2013 (UTC)
John, unfortunately, the problems are very real. The very technical properties of a namespace as opposed to a talk page on which AfC submissions are currently placed, will open up the possibilities for new and more streamlined resources that would guarantee faster processing and more equity in the reviewing of AfC submissions. If anything, therefore, it can only significantly reduce backlogs. Kudpung กุดผึ้ง (talk) 01:40, 9 November 2013 (UTC)
  • Weak Oppose because the effect on user space is ambiguous. My oppose is weak only because some reasonable interpretations are that the use of user space for draft articles will still be permitted. Strongly oppose any loss of the ability to maintain draft articles in user space. (Also oppose any other restrictions on user space, such as the ability to maintain essays in user space.) Robert McClenon (talk) 01:33, 9 November 2013 (UTC)
  • Strong Oppose - I'd be very pissed off creating a draft only for it to be deleted, Using userspaces as drafts means no deletion & alot more time!, Per above If it isn't broke, don't fix it!. →Davey2010→→Talk to me!→ 01:44, 9 November 2013 (UTC)
    • The stuff you're objecting to isn't in the proposal anymore. After the first few objections to them, they were removed. equazcion → 02:18, 9 Nov 2013 (UTC)
  • Strongly Oppose --- this sounds vaguely like a good idea, except for all the consequences it will have. Even the support !votes above note this could cause (disastrous) changes to policy and practice. Whatever anyone says, this will clash with the freedom to have drafts and fragments in userspace organized or not according to individual editors' styles of working. Aside from that, the draftspace will quickly clutter up with a mass of unusable material, and both the AfC-type promotion discussions and the deletion discussions will become unmanageable. Chiswick Chap (talk) 09:47, 9 November 2013 (UTC)
    • The userspace drafting bits were removed from the proposal a while ago. I'm not sure what you mean about draft space cluttering up or making promotion/deletion discussions unmanageable -- they would work as they currently do, and all the same types of drafts (usable or not) will still exist, just in a centralized location. equazcion → 09:59, 9 Nov 2013 (UTC)
  • Oppose. Sounds like another low-quality venue just like Wikipedia:Article Incubator. If the draft is halfway decent, it belongs in mainspace. If one person has enthusiasm for a less than half baked idea, they can use userspace. If two people share an undeveloped idea, they can collaborate in userspace. The proposal, if accepted, can be read as implying that mainspace is not suitable for drafts, which is incompatible with the notion that no article is perfect, further editing is always welcomed. The negative of this idea complicating Wikipedia for newcomers, plus the exceedingly unlikelihood of experienced editors spending significant in a draft namespace, makes this a bad idea. --SmokeyJoe (talk) 13:50, 9 November 2013 (UTC)
    • I think you should look at it from the perspective of a new person. A first time author has very little idea what a "halfway decent" article looks like. Right now, they have two options: they can be bold, put it in mainspace, and if it's in any way not up to snuff it will get CSD'd or PROD'd, often in just minutes. If they are less sure, they have to go through the convoluted process at AfC; today, thousands of new article submissions end up stuck there, because reviewing and submitting drafts in the Wikipedia Talk namespace requires some insane workflows and ugly hacks. For the new user, what we should test (not assume will work, but seriously test) is providing them a safe space to develop their first articles, ask for review, and easily publish to mainspace when they feel ready. Right now, our tools are getting in the way for new users who aren't confident and need help. While folks like you and I, who've created lots of articles, won't really need a Draft space, this will be a huge boon for newcomers who are mostly having a discouraging experience writing articles. Steven Walling (WMF) • talk 22:43, 9 November 2013 (UTC)
  • I did look. I disagree with you. A first time author who has little idea of “halfway decent” has other options, and I recommend instead that they should read some articles, and edit some existing articles, so that they gain some idea of what halfway decent is. This is in accord with my comments at Wikipedia:Village_pump_(policy)#Restrict_Article_Creation_to_Autoconfirmed_Users. We are years into diminishing returns for new article writing, and it is not desirable to record half baked new article ideas from new authors who have less than barely engaged with the project.

    Once they know barely anything about Wikipedia, they will know that they can create their own user sub pages. I wish that we would auto-welcome new accounts, and advise them of the route to autoconfirmed, advise them of the benefits of userspace drafting, and advise them of Help:Move and discourage copy-pasting to mainspace.

    Userspace is a safe place. Draft space would be less safe. I don’t know why AfC puts drafts in Wikipedia talk space for registered users, I think it is a bad idea. --SmokeyJoe (talk) 05:37, 11 November 2013 (UTC)

  • Strong Oppose. Exactly per SmokeyJoe. The incubator failed, and this is essentially the same. As long as drafts are good enough to avoid deletion, I strongly believe drafts should go in mainspace, where they will attract more editors for collaborative work. There is no need to separate out "drafts" when the whole point of Wikipedia is that all articles are drafts in varying states of development. Also, to the extent that this is to address a problem at AFC, I think the AFC process is fundamentally broken because it rejects articles that would not have been deleted had they been posted to mainspace directly. If everything that could withstand deletion were automatically passed along, this massive backlog and all of the rejected articles that merely need improvement (and hence should be in mainspace for others to improve) wouldn't exist. Calliopejen1 (talk) 14:25, 9 November 2013 (UTC)
  • Strong Oppose. Wikipedia is cluttered enough as it is. Public drafts would be just another place for poorly written fragments to add to the clutter and add a policing burden onto the rest of the editors. Clutter, if it must occur should be confined to private user space. (See Clutterers Anonymous for a brief discussion of out of control cluttering.) New editors should learn how to write minimally acceptable articles before showing them in public.Trilobitealive (talk) 15:32, 9 November 2013 (UTC)
As one of the editors helping around at the IRC help channel and fairly familiar with AfCs and drafts, I would like to show one part of reality about the not-that-good articles that I've seen around as drafts. Everyday, dozens of new editors come trying to get their article across to the Mainspace, plenty of articles from which would never have the required sourcing to get there. But they don't get there, because AFC forces them to go through the draft stage. If they are directly created into the mainspace, they often go unnoticed in the mainspace for a long time, from where deletion of the nearly-there articles is tedious. For example, I recently nominated Andria_D’Souza for deletion after it was created directly rather than be drafted and reviewed first. So in that context, the clutter keeps on coming, whether to the drafts, or directly to the mainspace. Draftspace simply has a better way to deal with them. TheOriginalSoni (talk) 15:49, 9 November 2013 (UTC)
  • Strong Oppose. I can't see it solving anything and it will just add an extra layer of complication. —(RT) talk 16:14, 9 November 2013 (UTC)
  • Oppose More complication, and, while it might not, it is likely to get crammed with junk like AfC has. (Not criticising the present AfC workers, but in the past some godawful stuff got hung on to when it had as much chance of becoming an article as an abandoned snowball in the Sahara has of becoming a glacier.) I don't think a lot of stuff gets past the patrollers of new main space stuff. If anything it might be a better idea to put stuff that stands a reasonable chance into the existing user space, although there we have the problem that some new editors don't take any notice of user talk page messages telling them where their pride and joy is hiding. Then again, they might just not really care after all - or be like the ones that abandon stuff at AfC at the first hint that they've not done it right.... Peridon (talk) 17:49, 9 November 2013 (UTC)
You say it might be better to just use userspace drafts-- but when I see a draft in a userspace, I don't feel 'welcome' to edit it. Userspace means that that author is working on something and you shouldn't change it unless invited. That's where the "Collaborative Drafting" namespace comes in. It's an easy way for a new user to signal that they DO want drafts improved by others and don't 'own' the draft. --HectorMoffet (talk) 04:31, 10 November 2013 (UTC)
  • Oppose immediatey introducing a drafts system or a simple namespace, largely per Nsk92 (who sums up my concerns well). I'd be more likely to support it if this was not only a "drafts" feature but an actual software-based workflow for handling incoming users. support introducing such a workflow by way of the Growth team. Ironholds (talk) 12:27, 11 November 2013 (UTC)
  • Oppose. Creating a new namespace won't solve the backlog problem, but it will necessarily create a new layer of bureaucracy and policies regulating this new namespace. At the same time the impact on other namespaces, especially the user pages and user sandboxes, is unpredictable. Experience shows that, once started, a bureaucratic machine always takes the life of its own. The real solution here is to completely scrap the AfC system altogether and to require all new users to accumulate a certain number of edits before being able to create a new article in mainspace. This will also give new users an incentive to get substantively involved in the project and learn about its nuts and bolts, before creating a new article, and will help the new users break out of an SPA mode, in which many of them operate. Nsk92 (talk) 01:34, 11 November 2013 (UTC)
    • I think this could be a good incremental first step toward more software features that will make the article creation much more user-friendly. One easy feature that can be built off the Draft namespace is to detect an existing draft when someone clicks a redlink. Right now someone clicking a redlink has no idea whether someone else is working on a draft or not. I would much prefer an incremental approach toward more user-friendly workflows than a large change designed by committee. Gigs (talk) 16:37, 11 November 2013 (UTC)
  • Oppose While I prefer a draft namespace vs. overloading the user namespace I don't see how this actually solves a problem. AfC, the prior 'solution' to our general problem of new users and new articles, has failed nearly completely. Instead of serving new editors it serves new page patrollers and allows them to leisurely tell a new editor to pound sand vs. having to do so rapidly. That failure--the repurposing of AfC to meet interior community needs rather than the needs of new users, should be instructive. I don't see a need for repeating this writ large. Protonk (talk) 16:22, 11 November 2013 (UTC)
    • Category:Accepted AfC submissions currently has over 35,000 live articles. I don't think that is a "nearly complete failure" nor just a way of telling new editors to "pound sand". In fact it is close to 1% of our total article count. It isn't working as well is it might or should perhaps, but I think it is significantly better than nothing, even as it stands. DES (talk) 16:55, 11 November 2013 (UTC)
      • Don't confuse stocks and flows. AfC has been around for ~2 years so the number of live articles will doubtless be large. The backlog for submissions is 1,876 articles, expected to be processed at the current rate in 3 weeks. That is what editors looking to help see and that is what new editors see. A potentially 3 week delay on their submission (and I'd be willing to bet that declined submissions get processed faster than accepted submissions). I say it's a mechanism to help out NPP rather than new editors because that backlog can be processed at leisure vs. the NPP backlog which represents live content in the encyclopedia. Those benefits accrue to us, not new editors. Protonk (talk) 17:02, 11 November 2013 (UTC)
        • Disagree completely. AfC gives new editors a way to avoid the slap of instant CSD. Forcing us to make quick choices on their articles means that we don't have as much time to coach them through the process and on our rules. You'd lose that bet regarding declines being much faster than acceptance BTW. I generally work from the older end of the backlog and still wind up dealing with many obvious declines.
        • A decline is much more work than an accept, since that means you have to deal with explaining to the user what was wrong, and how they can fix it. Don't take this the wrong way, but you seem to be speaking from a position of ignorance, or at best, a theoretical conception of AfC that is out of line with what actually goes on. I invite you to help out with AfC for a while, if for nothing else, to learn where the real flaws are (it's not a perfect system). Gigs (talk) 17:31, 11 November 2013 (UTC)
  • Oppose I agree with Ironholds and Nsk92, but I don't see a real problem needing this solution. Sure there is a backlog of requests for low-notability subjects, most are easily dispensed with and just need manpower (like all Wikipedia projects)--the stale drafts often just need someone to delete them. This is a needless Byzantine structure for a simple, rather exaggerated problem. --ColonelHenry (talk) 16:38, 11 November 2013 (UTC)
    • If you were to assume that nearly all drafts are on non-notable topics and just need someone to delete them, then yes, there sure is no actual problem here. I can't quite fathom where you came up with that assumption though. equazcion → 16:47, 11 Nov 2013 (UTC)
    • @ColonelHenry. I agree that the main need is for additional volunteer time. I don't agree that most AfC submissions are "easily dispensed with", many require significant work to separate the wheat from the chaff while avoiding WP:BITE, and there is more wheat than you might think. Similarly, there is a larger residue of potentially decent articles among the stale drafts than a person who hasn't worked on the rescues project or otherwise spent some time seriously looking at them might think. It is the current structure, created as a hack to avoid the prohibition on IP editors creating new pages that is rather Byzantine, IMO. A draft namespace would not increase the number of volunteers by magic, but would allow a somewhat less convoluted workflow. DES (talk) 16:49, 11 November 2013 (UTC)
      • Preventing IP editors from creating new pages is a sensible option given the concerns over vanity/vandalism/bullshit articles. I would never change that because it saves a lot of headaches and time-wasting maintenance. But changing from one byzantine workflow to another is not a solution. I disagree on the issue of "easily dispensed with" (which just requires good judgment and the toolset to speedy delete to solve a big swath of the problem) vs. "significant wheat vs. chaff work" - usually the chaff is quite obvious and just needs someone with backbone to dispose of it.--ColonelHenry (talk) 17:07, 11 November 2013 (UTC)
        • There are few speedy deletion criteria that apply to stale/crap drafts outside of AfC. I recently raised that issue at WT:CSD urging people to send less of the obvious cases to MfD, and was rebuffed. Anyone who would unilaterally delete "big swaths" would surely draw heavy fire. Gigs (talk) 17:40, 11 November 2013 (UTC)
          • The setting preventing IPs from creating pages was installed as a temporary measure after the Siegenthaler Hoax, and it was never rediscussed nor obtained formal consensus, but it almost surely has such consensus by now. I, for one, have the tools to speedy delete, and editors who ar3 not themselves admins can and on occasion do tag AfC drafts for speedy deletion, and such tags are generally promptly attended to. But I find on the occasions that I do AfC reviewing, that there are many pages that can be developed into reasonable articels with some help, but would never pass AfD, and might well not even avoid speedy deletion, if simply dumped inmto mainspace. How much AfC reviewing have you done? I haven't checked, so maybe it is a lot. Just how do you think the Afc workflow in a future drafts namespace would be a "byzantine workflow"? I suspect it would work something like: a user would create a new draft, guided by the article wizard, perhaps an improved version. Other editors might also edit the draft to help improve it. Eventually the creator or another editor thinks the draft is ready for review, and marks it as such. A reviewer looks at it, commenting on any issues, and possibly editing to help fix them (I almost always make several edits to any AfC draft I review that isn't a quick decline or a speedy delete). The reviewer then either accepts, moving the article to mainspace, or declines with one or more reasons, allowing further refinement and re-submission. Is that such a "byzantine workflow"? It might perhaps be improved further, or new tools/scripts devised to automate the non-creative aspects. But "byzantine"? DES (talk) 18:20, 11 November 2013 (UTC)
            • It is absolutely byzantine. I help support editathons in the Boston area and for new editors wanting to create articles the indirection between the sandbox (which has a link to prefill an AFC submission in the default template) and the mainspace looms large. If it worked in a timely fashion or it was a venue for feedback (as it is purported to be) then that wouldn't be a problem. But it's not. From the perspective of a new user their article goes from the sandbox to a queue where it is handled sometime (what that time will be and what action will be taken is largely a mystery to them). For example, Richard Pearson Strong was created by an editor at an editathon I attended. It's demonstrably not ready for mainspace but it has sources (and the subject has other sources both available online and in university libraries) and the subject is likely notable (the first faculty member in a new department in arguably the most famous university in the world). Furthermore, the subject has been dead for ~60 years, so we're not going to run afoul of BLP. But the submission was declined in 20 minutes. I'll never see that editor again. Neither will Wikipedia. And what could have been a fairly innocuous article improved over time is instead a monument to our process. Protonk (talk) 18:37, 11 November 2013 (UTC)
              • That is not a byzantine workflow, that is a poor reviewer. First of all, a reviewer should normally be working from the back of the queue, so 20 minutes is an impossible time. Secondly, when I review a draft that isn't hopeless, I am apt to spend considerably more than 20 minutes on a single draft, either improving refs and writing, or at least giving detailed comments on what is needed. This points up the ongoing discussion here to establish some sort of minimum standards for AfC reviewers. I would also ask why, if the draft was "demonstrably not ready for mainspace" you encouraged the editor to click submit (if you did, as seems to be implied above) rather than suggesting the areas that needed improvement? How would you suggest the process be improved, with or without a new namespace? DES (talk) 18:55, 11 November 2013 (UTC)
                • That's a poor reviewer on top of a byzantine workflow, perhaps. The two are not exclusive. And no, I didn't tell her to click submit. There were 12 people at the editathon and not everyone got personally shepherded through the submission process (mostly because I thought that wasn't necessary). Most of the people who were more comfortable bypassed AfC entirely (and were better off for it, see here). If I wanted an article to be rejected quickly on the basis of a mislaid notability concern, she could've avoided AfC as well and had a similar experience in the mainspace. I'm not inclined to believe that greater standards for reviewers will do anything (as we could've simply imposed those standards on NPP and solved the problem!). As for a better solution, I'm of the opinion that an article on a notable which meets V/NPOV (and BLP where needed) can go through this process of review and commentary in the mainspace. That's not going to happen ever again, but that's certainly a better workflow. Protonk (talk) 19:09, 11 November 2013 (UTC)
                  • AfC just gets in the way of good faith work like editathons and so is best avoided. I have moved the R. P. Strong article to mainspace which is where it should have been created in the first place. If NPP and AfC reviewers can't recognise a promising topic like that when they see it then they should be barred from disrupting such work. Warden (talk) 00:56, 13 November 2013 (UTC)
    • ColonelHenry, you say you don't see a problem; I think this will help solve a big problem with the new user experience-- but let's agree that you don't think this would solve anything. Even still, can we agree to look at it as a purely technical matter. What is a better title for a draft: "Draft:Whatever" or "Wikipedia_talk:Articles for creation/Whatever"? What makes more sense from a software architecture perspective? To have a namespace for drafts, or to put drafts in the wikipedia_talk namespace? If we had started AFC under its own namespace, would we EVER decide to move drafts into the Wikipedia_Talk namespace??? Of course not! It was a clumsy hack that we have the chance to correct. Draft articles belong in a Drafts namespace, Project Discussion belongs in a Talk namespace-- they're two fundamentally different types of content, and we're needless complicating things by storing the Drafts namespace under Wikipedia talk:Articles for creation/ --HectorMoffet (talk) 21:16, 11 November 2013 (UTC)
But isn't that enough? If you do a search of Wikipedia_Talk, nearly all the search results come from draft articles which are overloading the Wikipedia_talk namespace. I call that a bug that needs to be fixed. --HectorMoffet (talk) 23:59, 12 November 2013 (UTC)
  • Oppose for two reasons. First, the AFC backlog is due to lack of reviewers, not problems inherent to the AFC system. Second, I see no explanation for how "all articles currently in these namespaces will be transferred to the Draft namespace" will be done without massively confusing hundreds of new editors. Howicus (Did I mess up?) 21:23, 12 November 2013 (UTC)
  • Oppose It's just another layer of bureaucracy, it will alienate lots of people, Wikipedia will become even further away from being "the encyclopedia anyone can edit" than it already is, it is just moving a problem to somewhere else instead of solving it. Richard75 (talk) 23:33, 12 November 2013 (UTC)
  • Oppose Adding one failure to another failure will result in a bigger failure, rather than success. The incubator and AfC should be closed down per WP:CREEP because they don't work. Articles should be created in mainspace as specified by our editing policy. Warden (talk) 00:19, 13 November 2013 (UTC)
    The problem with that is that far to many promising starts are swiftly deleted with no chance for a more friendly editor to assist in their development, and as a result, potential new editors leave never to return. I would strongly argue that AfC does work, albiet not as well as it could or should. Try creating a promising but sub-standard new article under an alternate username. See how long it lasts, and how helpful the messages you get are. DES (talk) 00:31, 13 November 2013 (UTC)
    Been there and done that. The solution is to reform the NPP so that the trigger-happy types are weeded out. We need to bear down on the editors who are causing the trouble, not the victims. Warden (talk) 01:02, 13 November 2013 (UTC)
    I remember seeing an organized round of that a couple of years back. One of the trigger-happy types said that he wished he had been warned about the experiment, so that he would know that it was important to be nice to the "new" people, just in case he was dealing with someone who wasn't actually "new". WhatamIdoing (talk) 01:55, 13 November 2013 (UTC)
    I think you're referring to Wikipedia:Newbie treatment at Criteria for speedy deletion and the resultant backlash. --HectorMoffet (talk) 10:55, 14 November 2013 (UTC)
  • Oppose. If they're in danger of being deleted from the main article space, new pages can be played with in the user's sandbox. You can't fix a bureaucratic backlog by adding another layer of bureaucracy. Kafziel Complaint Department: Please take a number 23:57, 13 November 2013 (UTC)
    • How are new editors supposed to know that though? At what point would they make the choice to use their sandbox? People don't go read all the documentation before they create pages, and they don't have to. So they're supposed to move their articles to userspace after they get nominated for speedy deletion? That's not going to happen, not when no one tells them they can do that. New editors make up the bulk of AfC submissions, and they don't what's in danger of being deleted. They need a safe space to make mistakes if they're not confident about article creation like more experienced people. Otherwise they're just going to get smacked down by New Page Patrol. Steven Walling (WMF) • talk 08:20, 14 November 2013 (UTC)
      • Lurk moar. If they're so new that they've never gotten a welcome message, or spoken to another editor, or read anything about how articles are created, then they probably shouldn't be creating articles. If someone wants to start a proposal to create a script that automatically welcomes new editors with information on editing and creating articles, I'll support that. That's a much simpler solution than creating a whole new namespace. Kafziel Complaint Department: Please take a number 14:48, 14 November 2013 (UTC)
Kafziel, setting aside the new user issue-- right now, if I had a draft that I want others to help me edit, where does it go? I know where private drafts go-- into user-space. But where should we put collaborative drafts, where I can write something and signal to all other users that it's fair game for editing? We don't have such a place yet, we're using Wikipedia_talk to do the job instead. --HectorMoffet (talk) 17:01, 14 November 2013 (UTC)
If it's being actively edited by multiple users, it can go in the article space. All of Wikipedia is a "collaborative draft". For example, look at the piece of crap that is the Ithikkara River article. After almost seven years, it is three sentences long and cites not a single reference. So what? It can still be in the article namespace. That's what the "stub" categories are for. I don't know what level of quality AfC editors are working toward, but clearly it's too high; any backlog on Wikipedia talk pages is created by the bureaucracy of AfC, and will not be solved by adding a new layer. Just write the damn things, throw them out there, and be done with it. Perhaps this situation needs its own flow chart. Kafziel Complaint Department: Please take a number 17:27, 14 November 2013 (UTC)

If it was created today, the only reason Ithikkara River wouldn't be speedy deleted is because A7 doesn't apply to geographical features. If a new user creates an article like that on a company or event, it will be gone within 2 hours. And anonymous users can't create new articles. Should NPP work better? Sure. But we shouldn't let perfect be the enemy of good here. Major structural reform of NPP/AFC is going to take a lot of work and a lot of time. This is a relatively simple technical fix to AFC. It's not a "new layer." It's basically just replacing the current hack of using "Wikipedia talk:Articles for creation/" subpages like a namespace for article drafts. Mr.Z-man 17:46, 14 November 2013 (UTC)

If someone wrote an article like that on a company or event, it should be deleted in two hours. And anonymous users shouldn't be allowed to create new articles. So those arguments don't really hold much water in my opinion. A stub can be extremely short, and shouldn't be speedied unless it makes absolutely no claim of notability. If they are being deleted, then that's a problem with a different bureaucracy (CSD) that was created to deal with another bureaucracy (AfD). Either way, I don't see how this would fix anything. Kafziel Complaint Department: Please take a number 18:47, 14 November 2013 (UTC)
So we should use mainspace for drafts, but only when they're about inherently notable topics? I don't understand your argument anymore. You wrote that AFC is setting too high a standard and that people should "Just write the damn things, throw them out there, and be done with it" but now articles on certain topics do need to meet a minimum quality standard immediately? Mr.Z-man 19:06, 14 November 2013 (UTC)
@Mr.Z-man:So we should use mainspace for drafts, but only when they're about inherently notable topics? Well... yeah. If a draft is about a non-notable topic, it is never going to survive in article space and working on a draft is a waste of time. You cannot make a non-notable subject notable. VQuakr (talk) 21:16, 14 November 2013 (UTC)
There is a difference between "notable" and inherently notable. Things like rivers simply have to exist to be notable. A notable topic is not necessarily inherently notable. And it's not really true that a non-notable topic will never become notable. You can't make it notable yourself (unless you run a media outlet), but it can happen. Justin Bieber wouldn't have been notable prior to 2009. In fact, the article was even speedy deleted 4 times for failing to assert notability in 2008-2009. Mr.Z-man 23:23, 14 November 2013 (UTC)
No, not inherently notable topics – there only has to be some kind of reasonable assertion of importance to avoid speedy deletion. It doesn't have to be ironclad. That's for AfD to decide. If it's worth anything, it will be saved. If it's not, good riddance. If it later becomes notable, great - write it again. It was only a few sentences. Now, I don't make the rules about CSD or BLP or any of that stuff, but yes, write the damn things and throw them out there. Be bold. I've never seen the Ithikkara River—hadn't even heard of it until five minutes before I created the page—but I looked it up, wrote a few lines, and put it out there. That's how Wikipedia is supposed to work. If someone's contribution is changed or deleted, so be it. If they can't handle that, they've come to the wrong place. If they care enough to find out why it was deleted, maybe they'll do better next time. Adding a new namespace will inevitably create a new bureaucracy of people who patrol that namespace, and then guidelines about standards for moving articles out of that namespace, and guidelines about standards for deleting articles from that namespace, etc. etc., and eventually a new namespace will have to be created for articles that aren't quite ready to be drafts. Where does it end? Kafziel Complaint Department: Please take a number 20:07, 14 November 2013 (UTC)
My point is that you used that as an example of how crappy articles can survive in mainspace and can go live immediately. But the only reason it survived was because it was about one of few kinds of topics where an assertion of existence is the same as an assertion of notability. Most topics have a higher bar than that. So it's kind of a cherry-picked example that makes creating an article sound easier than it is. But since you seem to have the view that if a user can't pick up our policies by the second edit and isn't discouraged by having their first contribution deleted with only an impersonal template notification, that we don't want them, I doubt you think editor retention is even a problem. Mr.Z-man 23:23, 14 November 2013 (UTC)

You decided to get hung up on the example, rather than looking at the crux of what I'm actually saying. Want a different example? How about this piece of crap that I wrote when I'd been editing for only a few weeks. It wasn't that hard. I didn't have to have a special namespace for it. I just wrote the damn thing and put it out there. I didn't quit Wikipedia when other people changed it. Whoop dee do. What I'm saying is that we should encourage good, bold editing by discouraging aggressive deletions and then we wouldn't need all this patronizing hand holding. We need less bureaucracy, not more. Kafziel Complaint Department: Please take a number 04:34, 15 November 2013 (UTC)

I completely agree that we need to be less aggressive. But people have been saying that for some time now and we've made approximately zero progress. I don't know that there have even been any concrete proposals to attempt to address it. Like I said, we shouldn't let the existence of a hypothetical perfect solution stop any sort of incremental improvement. Mr.Z-man 05:02, 15 November 2013 (UTC)
I don't see it as an incremental improvement, I see it as the first step in a downhill slide, highly prone to the same aggressive and abusive enforcement that is already rampant elsewhere. I want the articles to be free to succeed or fail on their own, out in the world. This proposal is more like shuffling them into Manzanar, supposedly for their own protection. I don't see that as a positive step, and neither will any new user. If you don't have the slightest concept of how to write an article, then you also won't see any difference between an article being deleted and an article put into draft limbo. Kafziel Complaint Department: Please take a number 15:13, 15 November 2013 (UTC)
Perfect example: Look at the page HectorMoffet randomly chose in his reply, below: Wikipedia_talk:Articles_for_creation/Cabinet_of_Ministers_of_Turkmenistan. "Submission declined"? Utter horseshit. That is a perfectly acceptable stub. Citing sources is not required for Wikipedia articles. Verifiability means someone can, if they make the effort, verify the information on their own. But you've got these self-appointed gatekeepers on AfC who are creating this backlog by enforcing their own little private subset of pseudo-rules. The same thing would happen in the draft namespace. And it would be worse, because AfC is just a WikiProject, with no real authority - I could move all 2,000+ articles into the article namespace, and there's no policy to stop me. Whoever wrote that Turkmenistan article could just make it an article and be done with it, if they knew better. A draft namespace (and the accompanying bureaucratic policies that would go along with it) would change all that, and turn all these self-appointed gatekeepers into self-important gatekeepers. I don't need to guess about whether it will happen; it has happened in absolutely every instance of every project and policy ever created on Wikipedia. Kafziel Complaint Department: Please take a number 15:57, 15 November 2013 (UTC)
"Citing sources is not required". Yes, it is. From WP:V: "All quotations, and any material whose verifiability has been challenged or is likely to be challenged, must include an inline citation that directly supports the material. Any material that needs a source but does not have one may be removed." Being "likely to be challenged" is a rather common condition, which I think applies to most contingent truths. (There is also WP:BLUE, which attempts to define the de minimis of this rule. But de minimis is quite minimal, nomen omen.) Keφr 09:25, 17 November 2013 (UTC)
I encourage you to read WP:LIKELY and WP:DEADLINE. WP:V requires WP:MINREF statements to be cited...but only before the deadline. It does not require these statements to be cited before an article can be posted to the mainspace. WhatamIdoing (talk) 23:13, 17 November 2013 (UTC)
  • Oppose. There is no problem here and there doesn't need to be a half-baked solution. Adding a new namespace is IMO even more confusing than the current AfC process. It could lead to a lot of clutter and abandoned articles, even more than userspace. I doubt a lot of people would take the time to patrol this new space enough to keep it relatively organized. KonveyorBelt 23:41, 14 November 2013 (UTC)
    Telling new users to create their article as "Draft:Title" is more confusing than telling them to create it at "Wikipedia talk:Articles for Creation/Title"? Mr.Z-man 05:02, 15 November 2013 (UTC)
Konveyor Belt, there are problems - one of poor reviewing of articles submitted to AfC and another of the backlog. Have you ever worked on that department? The 'draft' namaspace is primarily intended to replace the current use of an AfC talk page for submissions. This would significantly streamline the system and make it less confusing, and attract more users to the task. Kudpung กุดผึ้ง (talk) 05:31, 15 November 2013 (UTC)
But how would moving the venue decrease the backlog? I see no reason why someone would patrol a draft namespace and not Afc. Simply moving the place and not changing the process doesn't accomplish anything. KonveyorBelt 16:42, 15 November 2013 (UTC)
Well, moving AFC to a namespace would accomplish three tangible software improvements: (1) It would be easier to search Project_Talk, (2) It would be easier to search Drafts, and (3) Collaborative drafts could now have talk pages (just like articles or userspace drafts-- a feature sorely lacking in the current AFC setup). ---HectorMoffet (talk) 20:27, 15 November 2013 (UTC)
But would it decrease the backlog? KonveyorBelt 22:57, 15 November 2013 (UTC)
I'm agnostic. It's like debugging-- we've essentially got a data type mismatch error that's causing problems our search-subsystem and our discussion-subsystem. Fixing it might result in unanticipated benefits, but it will fix the two features where we know for a fact the bug is 'breaking' things. --HectorMoffet (talk) 05:02, 18 November 2013 (UTC)
It's necessary. Right now, there is no way to talk about drafts because the drafts are in talk space. For example, consider the arbitrarily chosen draft article Wikipedia_talk:Articles_for_creation/Cabinet_of_Ministers_of_Turkmenistan-- where do we go to talk about working together on that draft, if the draft is already on a talk page? --HectorMoffet (talk) 09:50, 15 November 2013 (UTC)
The solution is to stop talking about it. Stop all this navel gazing and work on the articles in the article space where they belong. I moved that article out of AfC without fixing anything at all - whaddaya know, now there's a talk page. Problem solved. One down, 2,110 to go. Kafziel Complaint Department: Please take a number 16:54, 15 November 2013 (UTC)
  • Strong oppose, my god, so many backlogs already WHY NOT CREATE A NEW ONE because practically nobody's dealing with the old ones. DS (talk) 12:33, 16 November 2013 (UTC)
    • It will actually reduce the number of backlogs (though probably not the amount of work). Moving AfC submissions and user space drafts into the new namespace is a one-time task, which can be partially done by a bot. Little work, and there are a few benefits worth considering. Keφr 09:25, 17 November 2013 (UTC)
  • Oppose. New users may indeed need some system for "submitting" articles, but this isn't it. Experienced users should not be bothered with this as all, and should continue to use userspace. — Aldaron • T/C 18:21, 18 November 2013 (UTC)
  • Oppose AFC has a problem. We all agree there. But why is that Wikipedia's problem? Another community project that has a backlog just looks for more members, and furthermore this solution as articulated is a timebomb.
    Ok so we resolve the 'problem' of AFC having a backlog (I put problem in inverted commas because AFC is a victim of its own success here) but we also create a two tier system for articles. So what happens when we get a topic that is being disputed on wikipedia. With mass deletions and counter deletions. We would NEVER !vote to delete at AFD but I see a lot of ppl here effectively suggesting the ability to demote articles to drafts. We are handing agenda driven single purpose accounts a new game to play.
    An optional draft category is not a bad idea at all. But this could be resolved by using templates on userspace pages. Opening up what will become another rules driven namespaces will neither help new users create pages nor reduce bureaucracy. We are kidding ourselves if we think this solution is going to help editor retention or simplification of site processes--Cailil talk 12:47, 19 November 2013 (UTC)

What next?

Consensus seems clear to move forward, while respecting userspace drafts. Can we close the discussion regarding the if, and get on with discussing the how? What needs to happen next for implementation? GenQuest "Talk to Me" 15:41, 18 November 2013 (UTC)

What page are you looking at? I don't see anything remotely resembling consensus. Kafziel Complaint Department: Please take a number 15:54, 18 November 2013 (UTC)
By numbers there are currently 80 supports and 33 opposes. That is ignoring any qualifiers shuch as "strong", "weak" or "conditional". As to the weight of arguments, I am involved and shouldn't try to asses those. DES (talk) 16:37, 18 November 2013 (UTC)
Well since the weight of the arguments is literally the only thing that matters, it's kind of important. Kafziel Complaint Department: Please take a number 16:40, 18 November 2013 (UTC)
Note: a good number of the "opposes" were stated prior to the user draft restriction update; for that reason, a lot of the first ones might be able to be considered more "neutral" now. Steel1943 (talk) 16:56, 18 November 2013 (UTC)
Um... no. It is not up to you to decide what other people think. I suggest that you actually go and ask the early opposers if their positions have changed now that userspace drafts are (kind of) being respected, rather than decide that they should be considered neutral. Sven Manguard Wha? 19:06, 18 November 2013 (UTC)
If a comment states that opposition to X (an aspect of a proposal) is the main reason for opposing the proposal, and X is later removed from the proposal, the closer may well apply reduced weight to those comments. DES (talk) 21:16, 18 November 2013 (UTC)
@Kafziel, the weight of arguments is indeed important, I never said otherwise. I merely said that I am not in a position to asses that. However, numbers are not of no import. If there are two approximately equally strong but opposed arguments on a matter, and 90 people support A while 10 support B, I would expect the closer to declare consensus in favor of A. In this matter, the question is one of judgement. There aren't any overriding polices or even guidelines that say we must create a new namespace, nor any that say that we must not. Some people think it will help the project, others that it will do no good or even harm the project. That is the kind of disagreement when numbers start to matter more than they might in, say, an AfD where some people are saying that a marginal or even clearly unacceptable source (say a self-published one) should be used to establish notability. There, clear weight of policy has the deciding hand. Not so much, here. DES (talk) 21:16, 18 November 2013 (UTC)
On the contrary, the draft namespace allows articles to be moved into a second-class, non-public namespace controlled by self-appointed regulators, making it no longer "the encyclopedia that anyone can edit". Currently, AFC is just a Wikiproject that any registered user is free to ignore at will, but creating a new namespace would officially make this "the encyclopedia anyone can request edits to". That goes against the whole point of Wikipedia. Kafziel Complaint Department: Please take a number 21:42, 18 November 2013 (UTC)
Not so, Kafziel, at least as I understand the proposal. Any page can be moved out of draft at any time by anyone, there is no requirement that any "regulators" approve. Nor does the proposal include any requirement that anyone start a new article in the draft namespace. People may be encouraged or advised to do so, as they now are advised to use AfC, but a user, including a new user, will be free to ignore it completely. DES (talk) 13:27, 19 November 2013 (UTC)
Which has worked out swimmingly for AFC and its backlog of 2,000+ articles. Kafziel Complaint Department: Please take a number 18:41, 19 November 2013 (UTC)
@Sven Manguard: since I'm not going to be the one closing this RFC, that is not my call to make. Also, I do not understand why you are talking to me as though it is my decision, or as though I am trying to command the RFC closer on what to do; thus, that was the reason I said "might be" as opposed to "are" in my previous statement. I agree with your statement that editors' stances might be the same, even with the "User space drafts" revision, but it would be difficult to determine that based on seeing that quite a few of the answers specifically refer to the "User space drafts" point without mentioning any other points. Steel1943 (talk) 22:01, 18 November 2013 (UTC)
The same could be said for "support" users who might have changed their minds. So it's pointless to say either way. Kafziel Complaint Department: Please take a number 22:08, 18 November 2013 (UTC)
@Kafziel: I agree, as per my edit conflict below. Steel1943 (talk) 22:17, 18 November 2013 (UTC)
(edit conflict)On the same token, some of both sides of the voting might want to change their vote based on the "User space drafts" revision. Changing the criteria of a proposal after editors have already voiced their thoughts can always cause difficulty for determining consensus. Usually, in cases like this one, a whole new proposal is created: I'm actually a bit surprised that a new proposal wasn't created for this, given that the outcome can create a huge change in the structure of Wikipedia in general. Steel1943 (talk) 22:15, 18 November 2013 (UTC)
A new proposal - and a re-vote, inviting back all commenting editors - might be a good idea. Whoever drafts the new proposal should have a thorough read of all the comments and try to see what possible concerns can be assuaged. Or perhaps first a discussion on some of the sticking points. Obviously, no one is going to convince the "We just don't need this at all!" crowd, but since they are in the minority maybe we can find a way forward that will cause the least objection. BOZ (talk) 20:49, 19 November 2013 (UTC)
If consensus is to essentially request a new proposal, I might be up to the task, time permitting and given the fact that I wanted to write this proposal myself at some point (but TheOriginalSoni beat me to it.) Also, if I recall, I remember reading somewhere on here that another user has a different draft for this "Draft proposal" floating around somewhere; maybe that one could be built upon, or maybe repost this one without any of the details that were removed from the original proposal during the course if the discussion. Steel1943 (talk) 21:36, 19 November 2013 (UTC)
A re-vote is an entirely unnecessary step I think. Nuances like the userspace draft issue are why we give discretion to closing admins in determining consensus, as opposed to just counting votes. Putting people through too many repetitious RFCs is extremely taxing and prone to reduce participation. A second duplicative RFC also would not add any helpful information for us at the Wikimedia Foundation, when it comes to creating a new namespace. I would like to us to ask a technically competent admin to close the RFC at their leisure. Steven Walling (WMF) • talk 21:48, 19 November 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Draft namespace implementation

Tom Morris, TheOriginalSoni, Just to update those interested, there's some drama going on at Bugzilla regarding this implementation. I've linked a couple of key points in those discussions above.

The first bug is the original as submitted by Steven Walling. He did not submit a request for a new namespace, but for a MediaWiki extension with some unspecified changes to the draft creation and handling process. I objected, saying the proposal above and its closure quite clearly indicate there are to be no such changes, other than a change to the location of drafts.

MZMcBride then created the second bug, to request implementation of what most users seem to feel actually represents this proposal. Steven Walling appears to have the support of at least one WMF developer in his (what I would say "singular") vision in Superm401 (Matthew Flaschen on Bugzilla).

So, despite the consensus demonstrated above, it appears we may not be getting merely what this proposal was supposed to give us, nor would we be getting whatever it is quite so promptly: these (so far two) WMF people seem to think there's software development required that should hold up the creation of the namespace. Since this is rapidly beginning to look like another WMF vs. community situation, I'm not sure there's much to be done about it, but I wanted to let everyone know what's going on. Cheers. equazcion → 10:49, 26 Nov 2013 (UTC)

  • Hi Equazcion and thanks for the ping. I had been marginally following this discussion on Bugzilla, and I didn't understand some of the technical bits, so I rather stayed away.
As far I know of the proposal, the most important provision was to have a Draft namespace, and whilst I am not completely aware of what a MediaWiki extension is, if it gets the main crux of the proposal correctly (Having a new namespace) I'd welcome it, provided it is done in a reasonable amount of time. I personally believe in a reasonable amount of leeway for the people to work on what they're trying to implement, so as long as it gets us what we want, I welcome it.
P.S. If I do not understand some parts of the discussion, or missed anything, please let me know.
Regards,
TheOriginalSoni (talk) 12:57, 26 November 2013 (UTC)
An extension is basically a change to the MediaWiki software. While the Draft namespace alone can be done with a more simple configuration change, and the accompanying changes to documentation, templates, scripts, and bots can be done by the Wikipedia community, Steven Walling and Matthew Flaschen think there should be accompanying software development that was not discussed in the proposal. The possible changes are vague at this point, but one thing that was mentioned was a change to the permissions applied to drafts -- which are again vague at this point, but I would assume regard who can create and edit drafts, and who will be able to make drafts into mainspace articles.
I personally wouldn't necessarily be opposed to some of the things Steven has alluded to, but they are all quite new and are being regarded as things that must be developed first before the draft namespace is created (when they technically are not even related, and are in my opinion entirely separate proposals). This is all occurring in the implementation of this proposal, despite the fact that this proposal and closure explicitly excludes further changes to the article creation process, aside from the location where drafts are stored. equazcion → 13:20, 26 Nov 2013 (UTC)
  • Equazcion From the description above, I would be open to the Extension, but possibly track the conversation more carefully. My view is that the enwiki asked for a namespace, because it was the only wiki so far which would require it and which specifically asked for it. If the developers think something like this would be better implemented by an extension and made available to other wikis, I dont see why that option can't be possible. The actual implementation of the extension, and the relevant discussion for it could be made at meta (Once again I am not very well-versed with changes that occur across wikis, but I assume it will be discussed at meta); but as far as it meets our (enwiki) requirements, and doesn't take too long, I welcome it. Of course, if the meta community thinks that such an extension is ill-advised for any Wiki except ours, that really requires the developers to opt for only an enwiki namespace, not a Mediawiki extension.
As for the rest of the points (permissions to draftspace etc), having the draftspace open to all is perhaps one of the strongest, if not explicitly detailed out, requirements of this particular proposal, and those in implementation should take a note of the same. We also ought to be monitoring the new mediawiki extension proposal from a distance just to make sure it doesnt conflict with some of the other points in the enwiki proposal above. TheOriginalSoni (talk) 13:40, 26 November 2013 (UTC)
Creating a draft namespace, even across other language wikis and projects, doesn't require an extension. The developers and other WMF personnel know this, and are not discussing an extension because they feel it's the best way to merely implement the new namespace. The only reason to discuss an extension is to implement changes outside the scope of this proposal, such as implementing new permission restrictions. The implementation is pretty much already conflicting with the proposal, which is why I brought it up. equazcion → 14:17, 26 Nov 2013 (UTC)
Actually, Equazcion, TheOriginalSoni has a point. The proposal for the Draft namespace includes the requirement that IP editors be able to create pages in this namespace. It is currently not possible in MediaWiki to give IPs the ability to create pages in one subject namespace (i.e. "Draft") without giving them the ability to create pages in any subject namespace (e.g. the main article namespace). As to whether the best solution to this is an extension or a change to the page-creation permissions handling in core, or whether the proposed extension would be going beyond what the community actually wants (or would want were they to have thought of it), I have no opinion. BJorsch (WMF) (talk) 15:26, 26 November 2013 (UTC)
BJorsch: Saying it's "currently not possible" is wrong, though it may be a bit ugly to implement. We should probably flip the logic such that we once again allow anyone to create pages in any namespace and only (reluctantly) restrict the article namespace from new page creations by anonymous users. There's no reason to restrict anons from creating Wikipedia pages or Category pages or Help pages. --MZMcBride (talk) 15:57, 26 November 2013 (UTC)
BJorsch, a hook on userCan should be sufficient right? Legoktm (talk) 16:26, 26 November 2013 (UTC)
  • (ec x2) Considering the potential for abuse for that, I have my reservations about opening all pages to anons. It might become a logistical nightmare to deal with vandalism on these lesser patrolled regions of the Wikipedia. In any case, this is a discussion for another proposal, and we should be having it there (Once it is proposed to open these pages for anons).
As for the current scenario, one of the things I'll like to know is which implementation is is hacky and which is easier to implement (In terms of both time and energy). Those two are pretty strong indicators of whether we should try doing it one particular way, or explore the possibilities, in my opinion. Also, whether the Draft namespace would be required for any wikis other than ours, which might require an extension, as compared to an enwiki fix. TheOriginalSoni (talk) 16:33, 26 November 2013 (UTC)
@Legoktm: TitleQuickPermissions seems more likely. I'd rather see that done in a proper extension though, rather than a hook function shoved in the configuration files. And it's not entirely clear whether the error messages would come out right or would complain about lacking 'createpage'. BJorsch (WMF) (talk) 16:43, 26 November 2013 (UTC)
Sure, just checking that it is possible to do without fixing the createpage mess (which someone should do anyways...). There are plenty of closures already in CommonSettings.php so I wouldn't be opposed to adding another one...unless you want to create a new extension called "DontDeleteEnWikisMainPage" ;) Legoktm (talk) 16:51, 26 November 2013 (UTC)
Would we really want the Draft namespace to be a "shitty hack" ;) BJorsch (WMF) (talk) 17:05, 26 November 2013 (UTC)
  • (ec) Hi,
Implementation of any idea takes time, and requires discussions. Considering that we had an adequate amount of time for discussion of pros and cons of the proposals, bunching all the editors who supported the idea as "Steven Walling and pals" is pretty unfair as a description. We're merely trying to move forward with a proposal that has already been accepted. It's simply about "how" that moving forward happens. TheOriginalSoni (talk) 16:33, 26 November 2013 (UTC)
Yeah, and "how" that moving forward happens is through a bunch of undiscussed, underhanded decisions and a looming avalanche of bureaucracy. As predicted. You say we had an adequate amount of time for discussion, but the reality would seem to disagree with you. Kafziel Complaint Department: Please take a number 17:17, 26 November 2013 (UTC)
  • Comment: Hi all, I just now saw this ping because it was made to my personal account, not my WMF account. The configuration change proposed by MZMcBride would not fulfill the requirements of the RFC, such as allowing IPs to create drafts. As Brad hints at above, there are clearly more technical details to be worked out before this is ready. Recently, I let TheOriginalSoni know that I'd make sure there was progress on getting the new namespace out the door, and that's still the case. But our next steps are not to rush out a namespace before the basic details have been figured out and tested. It's only been a week since the proposal was closed, so I don't see a reason to be charging blindly forward with something that hasn't been tested out (we have test wikis for this purpose) and which doesn't seem to meet the basic requirements of the RFC. Steven Walling (WMF) • talk 18:11, 26 November 2013 (UTC)
    • Aside from allowing page creation by IPs, which I admittedly didn't realize wasn't currently allowed, there are other things being proposed regarding this apparent extension that are not required to technically implement the consensus shown above. Many of these are being put forth as "questions" regarding the "details" of this, but regardless of the phrasing, are actually new proposals. They could be implemented without a Drafts namespace, or after one is already created. Among them are custom landing pages, reviewing tools, and publishing buttons. I feel these are being tacked on after the fact, and it is not "rushing" things to say that they are unnecessary complications to what is essentially a pretty basic proposal. Maybe the article creation process needs new tools and maybe there are further changes to be made. But those are not what the consensus here determined to be necessary, and they are not required in order to implement it. equazcion → 18:20, 26 Nov 2013 (UTC)
      • The fact that there's any disagreement about what the basic requirements actually are is a sign that we need to work them out before we rush headlong in to something that may not meet expectations. As for the rest... So you don't want to figure out what it says when you search for a page that doesn't exist? Or whether you can create a draft of a page that already exists? Or how we suggest to new editors that they can create a draft? I think these things are at least worth discussing, even if we end up feeling like some or all of them are not blockers to getting the first version of the namespace out. If there are things that we want to consider testing later, this needs to be clear up front, so people aren't confused or annoyed if stuff changes. People tend to assume here that what we release first is how a feature will look going forward. Even if we change nothing in the future, a new namespace's functionality needs to be tested and verified before we just dump it on the wiki and hope it meets expectations. Steven Walling (WMF) • talk 18:28, 26 November 2013 (UTC)
Just because someone suggests something new doesn't mean there's now more to "clear up" before we move forward. It's pretty clear already: You want to implement some new things that were not part of this proposal, so you need to propose them separately. I hope that's clear enough. This reminds me of article editing, where one or two people disagree with consensus and don't want to let things move forward because they insist there is still more to discuss -- they're often allowed to slap on a {{pov}} tag as a consolation prize, because "after all, there is a dispute here", even though there's actually just one or two people not getting it. To address some of your examples:
  • I didn't object to waiting or to testing the new namespace, so let's dispense with that straw man argument. I object to waiting if we're waiting for new software features to be developed that are not necessary for the creation of this namespace.
  • Search results will suggest AFC or a red link as the do currently. It is not required that we figure out some change to this before moving forward.
  • For now we suggest creation of drafts as we always have: through AFC. The possibility of changing this does not need to be determined before creating the namespace.
  • The question of duplicates in draft space doesn't need to be determined before creating the namespace. As far as I'm aware, duplicates could be created through AFC, and if the new namespace makes it easier to deal with them in an automated way, we can add that feature afterwards just as well.
I think that's all of them, at least of the "details" you're sticking to now. I make room for the possibility that there are others who would agree with you, Steven, but from where I'm standing, it seems like you want to use the consensus above to implement a more substantial change you had envisioned, when you should've suggested that they be added to the proposal beforehand. You waited instead and you should now propose them separately. equazcion → 19:02, 26 Nov 2013 (UTC)
You might disagree with the idea that the examples I gave are relevant to the Draft namespace, but as I said above, the current patch does not even meet all the basic requirements mentioned directly in the RFC. It's really a moot point as to whether the things I brought up are blockers, since we haven't even settled on a sound technical strategy for allowing for things like IPs creating drafts. Also, releasing new site-wide features without testing them is a recipe for trouble (as anyone who's used early incarnations of VisualEditor will tell you). It's simply not ready, and there's no reason to ram a half-baked change through, with only a week since the RFC passed. Steven Walling (WMF) • talk 20:06, 26 November 2013 (UTC)
I have to concur with Equazcion on this. What is required is quite simple: a 'Draft:' namespace that can be created by all users, registered, confirmed, or IP and one that is not indexed. I'm not personally concerned with the required software solution for arriving at that. What I do see now is that the Foundation has seen that the community has a consensus for something that is a good idea, and they now want to stall it to see what else they can do with it. That however, risks taking a very long time: a) because the WMF doesn't actually know what they want to use it for yet, and b) when they do, we'll all be waiting a year for it. There is further risk that we will be offered a top down solution that might not be what we wanted. It's happened before. I'm rather confused, because one staff member has clearly stated that AfC is not within the Foundation's remit and is a local solution to arrived at by the en.Wiki community - and that's exactly what the community wants. We're always pleased when the Foundation can devote funds and/or time to realising the community's technical requirements, but at the end of the day, it would have to be what the community knows best what it wants. If the WMF sees a possible cross-Wiki rollout, that can come later. For more background, see User talk:Steven (WMF)/Archive 4#AfC which was left wanting a reply. See also User talk:Technical 13#Draft namespace. Kudpung กุดผึ้ง (talk) 20:57, 26 November 2013 (UTC)
  • This is so depressing. Everyone wants to see the new page creation (via AfC, drafts, wizard) fixed, and I agree that something desperately needs to be done here, and I don't think anyone disagrees with that. However, I see the whole package like a car broken down on the side of the road. The question is how do we get it running again to get it to the garage for a proper fix. Creating a new namespace specifically to assist new editors in creating pages is only part of the solution. Right now, it seems that most of the community just wants a new namespace that replaces "Wikipedia(_talk):Articles_for_creation/foo" with "Draft(_talk):Foo". Kind of the way that a namespace alias works. I don't see what productive effect that will have other than shortening the URL by 26 characters. If a ns alias is all that the community wants, I'm sure the WMF can do that for now while they research a proper fix that will include allowing IPs to edit in the new namespace, a userright or some other method that can be used by the reviewer script to reduce the number of inexperienced/system gaming people abusing AfC, landing pages, a better user interface for new editors to make it easy to start their drafts (or request articles), etc... I feel like I could rant on here for hours about all of the possible implications and issues that may need to be addressed, not even scratch the surface of the actual list of things that need consideration, and be ignored as TL;DR. If anyone is interested (and I don't expect anyone is but would be elated if there was "one"), feel free to email me or find me on IRC and we can brainstorm and discuss all of this as extensively as you like. I kind of feel this whole namespace request is being rushed and pushed on the WMF and wasn't well thought out from a technical aspect, but I digress... Good night all and happy editing. Technical 13 (talk) 02:42, 27 November 2013 (UTC)
(edit conflict) We're talking about implementation of a proposal that already passed. If you don't think implementing the proposal that passed will actually solve anything, that's a different story -- but this attempt to solve that by passing off additional measures as technical requirements for this proposal is wrong. This proposal was intentionally rather simple and limited to one very specific measure, and should be implemented as such, since that's all people were !voting for here and that's all there is consensus for. If there are individuals, even within the WMF, who feel that further measures are required beyond what this proposal suggests, I think we'd all be fine with discussing those separately. equazcion → 03:07, 27 Nov 2013 (UTC)
I'd also just like to point out that Steven Walling originally referred to these (the things that he saw as requiring an extension) as "related enhancements", before it was pointed out (by me) that this proposal didn't concern them. He then switched to terms like "requirements", "details", and "fundamentals" following that. You can take that for what it's worth. equazcion → 04:35, 27 Nov 2013 (UTC)
  • My view, and what I thought I supported in tthe RfC, was a new namespacve that would allow IP users to create pages, would be noindexed automatically, and would allow any autoconfirmed user to move pages to main aricle space, or anywhere else. This would aid AfC in that it would permit separation of reviw comments onto proper talk pages, would avoid the problems that come with removing comments when a draft is posted to mainspace, and would avoid searches of the Wikipedia talk namespace being confused by draft articles, and vice versa. I campaigned on the basis that there would be NO new restrictions on who could move pages, and no new userrights involved, had such restrictions been part of the proposal, i might have opposed. It seems to me that those who are proposing that this must be implemented with far more infrastructure than was ever requested or desired, are effectively sabotaging the result of the RfC. No doubt with the best of intentions, but that will be the effect. (By the way, it is NOT the case that "Everyone wants to see the new page creation (via AfC, drafts, wizard) fixed" -- a fair number of people who participated in the RfF wanted AfC abolished, not fixed. This IMO plays into their hands.) DES (talk) 02:55, 27 November 2013 (UTC)
    I think roughly that DES has gotten it about right. The community has requested a new namespace. To achieve the very minimal intentions laid out in the RfC, the namespace should be implemented in such a way as to allow new page creation by IPs directly in Draft:. The AfC folk can start transitioning to the namespace. If the Foundation seeks to reform the process of using the Draft namespace, the best solution there is for them to detail their proposals on a talk page so that the community can have a look at them in detail rather than try and piggy-back them on the consensus from the RfC. In general, RfCs over the last few years have taken the form of seeking approval for the general concept from the community, then discussing specific measures in mini-RfCs after the fact. (See Pending Changes RfCs for instance.) So let's deal with this in a minimal but evolving way: implement the consensus now, then we can have discussions about tweaking it to make it better. —Tom Morris (talk) 14:05, 27 November 2013 (UTC)
  • I think you're overlooking Wikipedia:WikiProject Articles for creation/RfC for AfC reviewer permission criteria in which the community seems to approve (I'm not sure why the RfC hasn't closed since it is over 40 days old) a AfC reviewer permission criteria. I realize these are separate RfCs, but if people think that the WMF is going to treat them as such and spend much more time developing them individually, I don't foresee that happening. They are going to take all parts of this, An new namespace, a new reviewer permission (some way to restrict usage of the script), the ability for IPs (anons) to edit only in the new namespace (which is not currently technically possible), and roll it all into one Extension. They are also going to try and roll as many "enhancements" as they can into the initial release because they are not going to want to spend years and years waiting on every little stroll poll and request for this and that. How about we stop badgering them about it, let them quit wasting time discussing how they are going to do it and thinking they need to answer to us for every little thing and let them do their research and put together a prototype we can try out. Thanks! Technical 13 (talk) 18:52, 27 November 2013 (UTC)
    • I don't necessarily think we need to do all these things prior to creating the Draft namespace, but I think we're in agreement that if we're not careful, we're going to end up simply moving the backlog from one place to another. In the long term, we need to experiment with different approaches to reviewing drafts. We aren't going to come up with the right solution straight away, I think, and need to be open to trying different tactics. What I am concerned about, and which I think blocks the creation of the new namespace right this very moment, is the lack of clarity about all the requirements really necessary to make a functioning namespace. Steven Walling (WMF) • talk 20:57, 27 November 2013 (UTC)
      • I've been following the bug discussion and it seems like the items suggested as requirements were refuted. I could be wrong. Could you list the items you still see as requirements blocking the creation of the namespace? equazcion → 21:14, 27 Nov 2013 (UTC)
      • Looks like this question was handed off to Superm401, and the foreseen requirements are now listed here: mw:Draft namespace. Seems to be a list of questions whose answers were pretty much already determined; no actual "blocks" in the traditional software development sense of the word. If this lets them maintain their dignity then so be it. equazcion → 23:57, 27 Nov 2013 (UTC)

Edit history of a selected area

Latest comment: 10 years ago5 comments4 people in discussion

It would be helpful to be able to bring up the edit history for a specific section, or better yet, selected area. The edit history would include only entries that resulted in changes to that area. For example, if I selected this text I am typing here now, and chose to view the history for it, it would bring up only the entries where this text was modified. If this is possible, it might (or might not) be easier to implement for text selected in the editor (i.e. source code) instead of the public page. This feature could be helpful in many circumstances: e.g. quickly tracking down specific changes, problematic or not, for the purposes of reverting, linking to, commenting on, etc., without having to potentially wade through a huge edit history for the entire page just to find a particular area that was changed. --Xagg (talk) 17:17, 27 November 2013 (UTC)

This would be difficult to implement. It would take a lot of server resources to search for this text in the history and provide a list of all edits done to it (think of articles that have thousands of edits). How is it supposed to search for this text? Using targeted sections won't work because people can click edit at the top of the page and move down to a section and one is able to "dupe" an edit summary field to falsely indicate they clicked "edit" on a certain section. Also, as the text changes, the software would have to continually change what specific text it is looking for (i.e. searching for "tracking down specific changes" might change wording in past revisions, so it would have to continually alter its search parameters as it finds new changes to that phrase).
Maybe a good idea in theory, not so much in practicality, imo. Someone could correct me. Killiondude (talk) 17:56, 27 November 2013 (UTC)
Xagg Perhaps Wikiblame would be helpful for whatever you're trying to do? Sven Manguard Wha? 18:09, 27 November 2013 (UTC)
Also, sometimes people change the organization in articles, moving or changing or even removing section headers without necessarily deleting the text. —Anne Delong (talk) 22:56, 28 November 2013 (UTC)
I had a feeling it would be difficult to implement. Killiondude and Anne Delong, thanks for confirming and explaining exactly why that is. Sven Manguard, thanks for the tool, may give it a look if something comes up; my request was not for any specific case though but just a general suggestion.--Xagg (talk) 02:22, 9 December 2013 (UTC)

Timeline for Articles

Latest comment: 10 years ago3 comments3 people in discussion

Proposal - A timeline tab for every page displaying events of an article in chronological order. This "timeline" may be created through having a program extract meaningful dates from the original article's text, or through user-editing, or both. An example of such a feature is this: http://timeline-chrono.rhcloud.com/

Rationale - It would be extremely useful to see the content of wikipedia articles in a chronological scale. Much of history is centered around dates, so having a date-centered perspective of most, if not all articles, would be extremely beneficial to users. — Preceding unsigned comment added by Agnusmaximus (talk • contribs)

There is {{ArticleHistory}}, a talk-page template that dates when events like GA, FA, TFA, DYK, and other major points of review in the article's history. These are meant to show date and the oldid of the version in question. --MASEM (t) 01:08, 28 November 2013 (UTC)
Based on the result of http://timeline-chrono.rhcloud.com/, the proposal is unrelated to page histories. It is about identifying years or dates in the current article text and use this to present text excerpts on a timeline. The algorithm for http://timeline-chrono.rhcloud.com/ appears to roughly be: For each sentence containing a number from 1000 to 2100, assume it's a year and write the sentence next to the year on a timeline. Ignore all other sentences. I tried it on a math article with numbers that weren't years. The result was meaningless. I think machine-generated timelines will be too random, and it isn't worth editor time to make them better. PrimeHunter (talk) 01:41, 28 November 2013 (UTC)
Given we strive for verifiability and precision of encyclopedia, I doubt we'll adopt a tool for individual articles which gives only algorithmic estimates. As for timelines, we already use such (Category:Timelines), but they are limited to article where such timelines help understand the prose. That said, parsing the entire encyclopedia or certain topics and building a estimated overview might be cool (for example, to see which periods are poorly covered), although I doubt we'll directly integrate such a system. —  HELLKNOWZ  ▎TALK 21:55, 28 November 2013 (UTC)

"Today in history"

Latest comment: 10 years ago3 comments2 people in discussion

Apologies if this has been suggested before - at a quick scan of the archive and the perennial proposals I can't find it (which surprises me a little)... would it be possible or worthwhile to add a link in the navigation menu to the article on the day's date, so that, say, along with "Featured content", "Current events" and "Random article", there's a "Today's date" link which would link to the article for the relevant date in the year (today, for instance, it would link to November 28). I think it would be a useful addition - anyone else have any thoughts? Grutness...wha? 06:54, 28 November 2013 (UTC)

Main Page#On_this_day... has the link. I don't think it's important enough for the navigation menu. You can try adding it for yourself with the below in Special:MyPage/common.js. PrimeHunter (talk) 11:55, 28 November 2013 (UTC)
var d = new Date();
var month=new Array();
month[0]="January"; month[1]="February"; month[2]="March"; month[3]="April";
month[4]="May"; month[5]="June"; month[6]="July"; month[7]="August";
month[8]="September"; month[9]="October"; month[10]="November"; month[11]="December";
mw.util.addPortletLink(
  'p-navigation',
  mw.util.wikiGetlink(month[d.getMonth()] + ' ' + d.getDate()),
  'Today\'s date',
  'n-today',
  'Article about ' + month[d.getMonth()] + ' ' + d.getDate(),
  null,
  '#n-sitesupport'
);
Cheers, that works nicely! Grutness...wha? 23:03, 28 November 2013 (UTC)
Latest comment: 10 years ago4 comments4 people in discussion

Combine the two, and form something like Wikipedia:Featured media candidates. This process would effectively revive the process for recognizing sounds on Wikipedia, and the one hierarchy created would ensure the process for recognizing sounds would not become inactive again. The requirements for featured sounds would remain the same, taken from Wikipedia:Featured sound criteria, and the requirements for featured pictures would likewise remain the same. Both requirements would remain separated from one another. The two pages displaying featured media would remain the same, so featured images would still be displayed at Wikipedia:Featured pictures and featured sounds would move from the portal space to Wikipedia:Featured sounds. To me, this seems like a relatively simple way to revive the featured sound candidates process on Wikipedia. Thoughts? Seattle (talk) 20:54, 28 November 2013 (UTC)

Sounds and pictures are two completely different things when it comes to evaluating their (technical) quality. MER-C 07:40, 29 November 2013 (UTC)
This is, by now, a perennial failed proposal. Neither the FP nor the FS people ever believed it was possible, nor did they have any desire for it. If you're interested in reviving Featured Sounds, I would be happy to spend some time speaking with you (I was a Featured Sounds director before it folded) about all of the things that need doing before FS can go public again (beginning with developing a much clearer set of standards, re-evaluating every current FS and delisting a ton of them, and getting a body of commentators that are both able to do evaluations and are willing to work in the historically highly troubled area). I personally would advise that you leave it alone; there are many more constructive things to do in the area of audio (and video) clippings than worry about getting them Featured. Getting them in articles, for starters. Sven Manguard Wha? 17:49, 30 November 2013 (UTC)
@Sven Manguard: I for one would appreciate any notes you have or could write-up, being put online so that others may benefit in the future.
@Seattle: Even Commons doesn't have an active featured sound dept. I'd recommend starting there, if the "Featured" aspect is what you want to pursue - so that all of our wikis can benefit. Otherwise, I'd echo Sven's suggestion, to work on other aspects of improving our multimedia usage. –Quiddity (talk) 20:05, 30 November 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_107&oldid=1214545863"
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy