Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Kafziel (talk | contribs) at 15:57, 15 November 2013 (→‎Oppose: example). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


« Archives, 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

The Wikipedia Adventure, alpha-testers needed

Hi folks, I've been working for the past 7 months on an interactive guided tour for new editors called The Wikipedia Adventure, as part of a WMF Individual Engagement Grant. The game is an experiment in teaching our aspiring future editors in an educational but playful way.

  • This week I need some alpha-testers to kick the tires and basically try to break it. I'm interested in general impressions and suggestions of course, but I'm really looking for gnarly, unexpected browser issues, layout problems, workflow bugs, and other sundry errors that would prevent people from playing through and having a positive experience.
  • If you're able to spend 1-3 hours doing some quality assurance work this week, you would have: a) my sincere gratitude b), a sparkly TWA barnstar, c) special thanks in the game credits, and d) left your mark on Wikipedia's outreach puzzle and new editor engagement efforts
  • Please note that the game automatically sends edits to your own userspace and it lets you know when that will happen. If you want, you can register a new testing account just for the game, but it won't work properly unless you're logged-in by step 8 of mission 1 when it lets you register on the fly.

If you're interested, please add your name below and have at it. You can post feedback to WP:TWA/Feedback. Thanks and cheers! Ocaasi t | c 20:51, 16 October 2013 (UTC)[reply]

Try out The Wikipedia Adventure

I'm interested and on the bug-hunt. Will report back this week

  1. Jackmcbarn (will be using my alt, Jackmcbarn no permissions)
  2. K.Nevelsteen
  3. GenQuest "Talk to Me" 22:33, 21 October 2013 (UTC) But, it threw out when it went to the "editing a new user page" section.[reply]
  1. Ellin Beltz I tried it and got kicked out when it told me to create or edit my user page, there was no way back to the Adventure! Ellin Beltz (talk) 16:57, 27 October 2013 (UTC)[reply]
  2. Deadlego

Proposal for a newbie flag

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)[reply]

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)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
  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)[reply]
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)[reply]
  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)[reply]
See also bugzilla:11800. Legoktm (talk) 20:36, 4 November 2013 (UTC)[reply]
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)[reply]
I have another motto: competence can be learned, competence can be taught. --NaBUru38 (talk) 22:25, 4 November 2013 (UTC)[reply]

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)[reply]

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)[reply]
  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)[reply]
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)[reply]
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)[reply]
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)[reply]
  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)[reply]
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)[reply]

wikidata: commons & other sister wikis

Hy! "inviting community discussion to show Commons links on the left", as per Wikipedia_talk:Wikidata#commons. also travel, ctionary, etc i'd like, but most importantly commons. right on top of lingo-s. and default open.
[off: talking about the left, where can i customise to include a searchbox there as it were?] --Aaa3-other | Talk | Contribs 19:36, 31 October 2013 (UTC)[reply]

In many cases a Wiktionary link would make more sense as the top entry. Praemonitus (talk) 01:59, 4 November 2013 (UTC)[reply]
I support adding Commons links to the right bar in every article. --NaBUru38 (talk) 22:26, 4 November 2013 (UTC)[reply]
Take a deep breath, relax, and try writing your proposal again. Use punctuation, capitals, and full sentences. Complete your ideas, and explain just what it is you want. Perhaps, then, we'll try to consider whatever it is you are proposing here. Thank you. GenQuest "Talk to Me" 06:47, 5 November 2013 (UTC)[reply]
There's no need to be rude about it GenQuest. Sven Manguard Wha? 06:57, 5 November 2013 (UTC)[reply]
You're right. Must have been a bad night. I apologize, User:Aaa3-other. Self flagellation now commences...

Conflict of Interest templating bot

Per a VPR COI Template discussion, six weeks ago a trial of 500 insertions of the Conflict of Interest template has been made. The bot is coded up and ready to go. Now's the time to decide if the template ought to be applied more widely. I come seeking consensus: ought this bot task be undertaken more widely? Josh Parris 06:06, 6 November 2013 (UTC)[reply]

Hrm.. I can't think of a good way to measure the trial really. I have found the template to be effective in some cases on articles I contribute to, but they don't always actually click the link. Also, we would need to look at data over at least three months in order to get an annual click-through rate. However, I think User:Addshore was the one that added a tracker to the clicky? and may be able to help us find out if folks are clicking on the link. CorporateM (Talk) 15:26, 6 November 2013 (UTC)[reply]
I cant remember this exactly, I also cant remember ot see me adding any tracker anywhere :/ Am I missing something? ·addshore· talk to me! 13:18, 9 November 2013 (UTC)[reply]
I was the one who created the tracker. @CorporateM and Josh Parris: At least two requested edits were made by clicking on links in the bot added notice, see Special:WhatLinksHere/User:Theo's_Little_Bot/coi_tracker/bot. You can find the requested edits on the linked talkpages doing a cmd/ctrl-F for "The above requested edit was made by clicking on a link in an automatically added". Theopolisme (talk) 15:24, 11 November 2013 (UTC)[reply]
Seems to me that the next step is to put a COI edit notice on the same 500 pages, with a different tracking link, so that the two mechanisms can be compared. That's what the original RfC contemplated, and with a 0.4% hit rate, the edit notice template doesn't seem super effective. Josh Parris 21:12, 11 November 2013 (UTC)[reply]

Proposed new Draft namespace

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)[reply]

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
        • 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)[reply]
          • 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)[reply]
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)[reply]
  • I just want to ensure that the new namespace would be natively transcludable and invokable. VanIsaacWS Vexcontribs 23:51, 7 November 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
    • 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)[reply]
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)[reply]
  • 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)[reply]
    • @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)[reply]
      • 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)[reply]
  • 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)[reply]
  • (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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

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)[reply]

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)[reply]
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)[reply]

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 3,024 pending submissions that need reviewing. Hasteur (talk) 21:31, 14 November 2013 (UTC)[reply]

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)[reply]

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)[reply]

Technical Feasiblity and Implementation

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)[reply]

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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
  • 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)[reply]
    • 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)[reply]

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)[reply]

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)[reply]

"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)[reply]
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)[reply]

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)[reply]

Support

  • Support - As proposer. TheOriginalSoni (talk) 19:05, 7 November 2013 (UTC)[reply]
  • Strong support - with one reservation that I have replied to in BD2412's comment above. Kudpung กุดผึ้ง (talk) 20:03, 7 November 2013 (UTC)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
      • 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)[reply]
  • 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)[reply]
    Amending !vote as the problematic part of the policy has been rescinded. --LukeSurl t c 12:58, 8 November 2013 (UTC)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Conditional support, so long as nominally active editors are permitted to keep drafts in userspace. bd2412 T 04:09, 8 November 2013 (UTC)[reply]
    What's wrong with inactive editors having drafts? Legoktm (talk) 05:52, 8 November 2013 (UTC)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support I sounds like an amalgamation from existing spaces. More clarity is always welcome. The Banner talk 15:25, 8 November 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support I found it hard to understand there was a draft area available.Saltybone (talk) 01:48, 9 November 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support in principle, provided this does not affect current policy allowing userspace drafts to remain. —sroc 💬 09:33, 9 November 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • Support As others have said, would hopefully address some of the issues with AfC. Neljack (talk) 08:50, 10 November 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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 | [[User_talk:S

qB_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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Suppot - Great way to organize drafts will be easier to search for one as well. ///EuroCarGT 00:31, 11 November 2013 (UTC)[reply]
  • Support only if userspace drafts are still permitted, as per the modified proposal --Aude (talk) 00:46, 11 November 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support - This will improve the project by increasing participation by and retention of new editors. Jojalozzo 02:02, 12 November 2013 (UTC)[reply]
  • Support - Seems like a sensible way to move all the draft work into one place. -- King of ♥ ♦ ♣ ♠ 03:20, 12 November 2013 (UTC)[reply]
  • 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)[reply]
  • Support as long as userspace drafts are still allowed (and they are). AutomaticStrikeout (₵) 17:58, 12 November 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support - This namespace is a good idea and should be implemented in some form.   — C M B J   01:41, 14 November 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support combining the many ways to submit articles will simplify the process. Dan653 (talk) 22:26, 14 November 2013 (UTC)[reply]
  • 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)[reply]
  • Support It would seriously improve search functionality.--v/r - TP 23:33, 14 November 2013 (UTC)[reply]
  • 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)[reply]
  • "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)[reply]
  • "Support" as per GrapedApe. Babakathy (talk) 12:54, 15 November 2013 (UTC)[reply]

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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
(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)[reply]
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)[reply]
  • Oppose Seems too much a solution for a problem which is not self-evident. Collect (talk) 12:35, 8 November 2013 (UTC)[reply]
  • 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)[reply]
    • 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)[reply]
  • Oppose. Solution in search of a problem. Ruslik_Zero 19:34, 8 November 2013 (UTC)[reply]
    • @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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
  • 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)[reply]

  • 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)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
        • 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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
        • 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)[reply]
          • 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)[reply]
            • 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)[reply]
              • 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)[reply]
                • 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)[reply]
                  • 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)[reply]
    • 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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
There is a difference between "notable" and inhernetly 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
    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)[reply]
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)[reply]
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)[reply]

Make SidebarTranslate into a gadget

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)[reply]
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)[reply]
Don't care where they propose it, count me as a Support. Peridon (talk) 18:48, 8 November 2013 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • Support - I've used this for a few months, and adore it. –Quiddity (talk) 20:55, 9 November 2013 (UTC)[reply]
  • 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)[reply]
    • 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)[reply]
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)
  • Support I had no idea this script existed until I saw the proposal, but I would love to have it as a gadget. Novusuna talk 22:09, 10 November 2013 (UTC)[reply]
  • Support - This is much easier than running it through Google Translate; I have a script that does this for me in 1 click, but everyone should have access to this functionality in 2013. ChrisGualtieri (talk) 01:06, 11 November 2013 (UTC)[reply]
  • Support with caveat - This is a great idea but the code should be examined by a couple tech-savvy advisors to ensure that it doesn't cause problems for people editing or viewing Wikipedia on any of the diverse platforms out there. This shouldn't be too cumbersome of a request. - tucoxn\talk 09:35, 11 November 2013 (UTC)[reply]

Noticeboard for protected talk pages

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)[reply]

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)[reply]

Wikipedia:Reward board guidelines tightening

Wikipedia:Reward board was kept at a recent MfD. I raised a couple of ideas to discuss on the talk page at Wikipedia_talk:Reward_board#As_we_are_going_to_keep_this.2C_do_we_need_to_tighten_the_criteria_a_bit.3F - if anyone has any other ideas now is a good time to stick them in. Cas Liber (talk · contribs) 22:06, 9 November 2013 (UTC)[reply]

Proposed amendment to WP:NOT, re: Product release information

There is currently a discussion to amend WP:NOT, a key Wikipedia policy, to extend the prohibition of quoting product prices in articles without sufficient encyclopedic relevance (WP:NOTCATALOG), to also apply to information about how a product is released (i.e. where it is released, what stores it is available from) under the same caveat. You are welcomed to join the discussion. ViperSnake151  Talk  01:34, 10 November 2013 (UTC)[reply]

The Wikipedia Adventure: Beta-test Invites

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)[reply]

"Editor Desk"

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 (UTC)[reply]

Enforce American or British spelling

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)[reply]

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)[reply]
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)[reply]
I prefer Oxford spelling myself—the only convention that is hated equally by Americans and Britons :) Kaldari (talk) 07:35, 13 November 2013 (UTC)[reply]
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)[reply]
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)[reply]
Lojban to the rescue! --Stephan Schulz (talk) 15:14, 14 November 2013 (UTC)[reply]
Sorry, Lojban is far too ambiguous and imprecise. It's Ithkuil or nothing! VanIsaacWS Vexcontribs 16:24, 14 November 2013 (UTC)[reply]
And how would you deal with quoted text from another variation of English? Josh Parris 06:04, 15 November 2013 (UTC)[reply]

Proposal to move the Orphan tags to the talk page

Reposted from Wikipedia talk:WikiProject Orphanage for wider visibility

Hi. I'll make this short and quick. I'm still struggling to see how useful the {{Orphan}} tag is. It's big, it's ugly, and it concerns a very very minor problem that most of the times does not really have a solution. Some articles are simply about subjects that have not been mentioned in any other Wikipedia articles. As the VERY large backlog in Wikipedia:WikiProject Orphanage makes quite clear. Forcing editors to link them or add them even in places where they are only vaguely relevant is not good practice. Neither does it concern any of the readers, but it's them who have to see the tag first thing on the page. If it was a problem on sources, I would understand, as readers should know about it. But not being linked enough is not that serious of a problem to merit defacing an article.

I propose that the tag itself be moved to the talk page to minimize its impact on the article's readability.

Note that I do not know how this can be accomplished (probably by a bot?) Neither do I really have the time to make this a formal proposal, but I'm simply fed up at seeing it all the time for otherwise perfectly fine articles. What does everyone else think?-- OBSIDIAN†SOUL 01:41, 14 November 2013 (UTC)[reply]

  • I can't imagine in what way a template that is formatted exactly the same as every other content notice and is barely two lines of text tall could possibly be construed as both "big" and "ugly". I would argue that the article page is the only place where it will do any good. If the original creator or other contributing editors had thought of incoming links that had been appropriate, they probably would have already done it. It's the drive-by reader, who searches and finds the orphan page, ostensibly after having been reading a related article, who should see that this needs to be done. Which means that the talk page is wholly insufficient to the task of the notice. VanIsaacWS Vexcontribs 02:38, 14 November 2013 (UTC)[reply]
It is formatted exactly in the same way, but not for the same problems. Not enough references, improper language, possible COI, those are templates that have the right to be noticed by the reader and should be screamed out prior to reading the article as a warning on the possibility that the content they were about to read may not be that reliable or in a bad shape.
But orphans? Really? It's not like those articles have problematic content or are completely inaccessible. Virtually all readers arrive on articles through search engines, not by clicking on a wikilink somewhere. And some articles again, simply can't be wikilinked elsewhere. What exactly is wrong with that? There's far more problems in shoehorning a distantly related article into another article simply because the tag tells you you need to link it. I've seen this happen when small out-of-the-way highly specialized articles get linked to high level articles by their creators where it isn't even mentioned and only vaguely relevant just because the tag tells them to.
As for regular readers, I highly doubt they would even know or care what it is for. And again, from the backlog (more than 120,000 of our articles have this tag, dating back from 2007 as a result of the rise of automated tools and drive-by tagging), they don't or (probably in most cases) can't fix it. They're basically going to stay there for eternity.
Give me one good reason why the reader has to know that the article they're reading is an orphan. And why they have to know it so urgently that it has to be the size of a bus with a big yellow threatening sign on it.
Because yes, it does affect readability. As an article writer, this kind of thing is extremely annoying. If not the talk page, how about something like the stub warning then? The one at the bottom of stub articles. At least those are placed after the text and is suitably small enough to not be defacing.
I am not the first person to complain about this. See Template talk:Orphan, and this has been proposed at least once before AFAIK (though there weren't enough editor input IMO) in Wikipedia:Templates for discussion/Log/2013 January 5#Template:Orphan placement discussion.-- OBSIDIAN†SOUL 03:18, 14 November 2013 (UTC)[reply]
And if you had actually read through all of those previous discussions, you would have seen numerous links to Wikipedia:Perennial proposals#Move maintenance tags to talk pages, which explains exactly why this is a bad idea. VanIsaacWS Vexcontribs 04:28, 14 November 2013 (UTC)[reply]
A compromise would be to move the tag to the bottom near the "no categories" tag. The categories and the linking are often being done at the same time when the article is first created, and this would separate it from the content problems being pointed out by the tags at the top of the page. —Anne Delong (talk) 04:36, 14 November 2013 (UTC)[reply]
I would be happy with having maintenance tags autocollapsed by default, with just a simple bar saying "Orphan article", "Article for Deletion candidate", etc, then having the standard "show" button to allow you to get the details. Obviously, it would require a far greater consensus than we can establish in this conversation, but it has the advantage of not requiring a bot run to alter 125 thousand articles, and the reprogramming of tools like AWB, and all the (dozens? hundreds?) tools and bots that do article tagging. VanIsaacWS Vexcontribs 08:52, 14 November 2013 (UTC)[reply]
Oh. This is one of the perennials? Why am I not surprised at that. That alone betrays that there really is a problem, don't you think? But yes, Anne Delong's idea is much much better in terms of what we have now. Autocollapse would be better too. Anything but that madly conspicuous "Notice me! This page has a teeny tiny problem that you need to know in the most obnoxious way possible (November, 2013)". It's just missing marquee and it could be a Vegas sign. -- OBSIDIAN†SOUL 12:46, 14 November 2013 (UTC)[reply]
While the "orphan" tag points out a minor problem, some of the other tags point out major ones, such as advertising and no references. I don't think these should be collapsed. About moving the orphan tag to the bottom: I don't think it would be important that this was absolutely consistent. Without necessarily changing all of the other bots or scripts, a new bot that ran perhaps once per week or even once per month could check for articles that had had an orphan tag placed since the last time it was run and move the tags to the bottom. If a few were missed or if some were moved by other bots it would still be an improvement. The old tags would gradually melt away as links were added, and at some point a run-once bot could catch any that were left from years ago. Just talking off the top of my head here.... —Anne Delong (talk) 14:08, 14 November 2013 (UTC)[reply]
Yes. As stated above, I actually have no problems with unreferenced, COI, POV, etc. tags. It's perfectly reasonable that the reader should know about those, as it affects the actual content of the article. Orphans however, have actually nothing to do with the content, and it's a very minor problem that in the natural evolution of articles, eventually does go away. Those which don't are highly unlikely to ever be linked ever, and the orphan tag on them becomes permanent and unreasonable.-- OBSIDIAN†SOUL 21:22, 14 November 2013 (UTC)[reply]
Support. Move orphan away. No need to scream at every visitor over every little thing. Rmhermen (talk) 17:24, 14 November 2013 (UTC)[reply]
Support if de-orphaning was attempted and/or for all BLPs, businesses, and organizations (the orphans least likely to be de-orphaned in my experience). The reason that the tags "have to be" present on the page is because we're hoping that "readers" will turn into "editors" by trying to solve the problem. But if it's not (apparently) possible to solve the problem, then IMO we can safely place the tag elsewhere (or even remove it, but then some busy person might replace it later). WhatamIdoing (talk) 18:44, 14 November 2013 (UTC)[reply]
Support Orphan tags have always annoyed me as being very low value and distracting. We could have a gadget for those people that want to know about it, but at least 99% of readers will not care. Whether de-orphaning is attempted or not does not matter, there is no requirement for an article to be linked from elsewhere. Graeme Bartlett (talk) 20:33, 14 November 2013 (UTC)[reply]
Support I would create a separate category or class of "minor maintenance tags" which would be treated differently, and restructure the template code to change their display, making it less obtrusive, or else use a bot to move them to the talk page. DES (talk) 21:54, 14 November 2013 (UTC)[reply]
Support per Graeme Bartlett. Kudpung กุดผึ้ง (talk) 06:24, 15 November 2013 (UTC)[reply]

Semi-protect all pages in the Wikipedia namespace

As the headline suggests, I propose that all pages beginning with "Wikipedia" followed by a colon be permanently semi-protected from editing. (This proposal would not include noticeboards and pages such as this one; this proposal would only pertain to policy pages such as notability guidelines) Why? Because: 1. There is no reason for new and unregistered users to edit such pages as they probably won't understand them well enough to do so constructively, 2. There are, however, major reasons for them to want to vandalize these pages, for example to remove themselves from the list of banned users or to complain about how evil and heartless administrators were to them and their contributions on WP:Administrators, and 3. Many of them are already semi-protected indefinitely, including the two I just mentioned, so it wouldn't be a particularly drastic change. I realize I am not the first to propose this idea, but I am confident that it is nevertheless a good one, and wanted to see if other editors agreed. Jinkinson talk to me 05:26, 15 November 2013 (UTC)[reply]

Registration is not a requirement. There actually are some unregistered users who are regular users and are plenty familiar with policies and procedures, but have just chosen not to register for whatever reason. Mr.Z-man 05:45, 15 November 2013 (UTC)[reply]
  • There are plenty of unregistered users who are regular contributors to Wikipedia space. Except for just a few places where they are not permitted to vote '(uch as RfA, for example), their comments are as welcome as those of any registered users. To impose a restriction such as this would also engender an enormous bureaucratic overload at WP:ERQ. Kudpung กุดผึ้ง (talk) 06:20, 15 November 2013 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=581784946"