Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Jump to content

Wikipedia talk:Drafts/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5→Archive 10

Placeholder on mainspace

Lessons learned from the incubator, Part 2, placeholders on mainspace

In one case, I was working on an article in the incubator whose notability remained unclear.  Someone created an article in mainspace that was then nominated for deletion.  Although undiscussed at the AfD, the closing admin decided to delete the incubated article.  A corollary is that the editor who created the mainspace article had no immediate way to know that work on the topic was ongoing in a collaborative editing environment.  In another case, I completed improvements to an article and when I tried to promote it to mainspace found that there was an old blacklisting assigned to the page.  In each of these two cases, had a placeholder been added to mainspace before I started to work, my time would not have been wasted.  Unscintillating (talk) 03:04, 9 February 2014 (UTC)

Proposal for a placeholder on mainspace

Create a Drafts Template or Drafts Portal that is placed on mainspace pages as a placeholder.  Unscintillating (talk) 03:04, 9 February 2014 (UTC)

Moving a draft to the main space would require that the place-holder page first be deleted. This would take up a small amount of administrators' time, and would be a temptation to copy-paste, leading to problems with the page history. The author who made an article in main-space when a draft had been started may not have done a search before writing. The Wikipedia:Simple guide to creating your first article asks "Please ensure the article doesn't already exist under an alternate title." Wikipedia:Your first article asks "Also search Wikipedia first in case an article already exists on the subject, perhaps under a different title." Drafts should turn up in the search results.
Perhaps it would be helpful to make create protection more noticeable, such as by showing a padlock icon. You can see that a page is create-protected by noticing the absence of a "Create" tab, by going to the "Page information" link or by searching Special:Log/protect. —rybec 04:31, 9 February 2014 (UTC)
A redirect with a new "R ..." template, Template:R to Draft, along with some no-index/no-follow magic to feed to search engines should do the trick, while preserving normal editor's ability to move the draft to mainspace. Bots that fix double-redirects would have to be changed to not "fix" such redirects. It would also "break" desired WP:REDLINKs by turning them blue, but that problem would exist if there were any type of placeholder in mainspace. davidwr/(talk)/(contribs) 04:42, 9 February 2014 (UTC)
Such redirect could be placed at the talk page. This way the redlink to the article would remain. Diego (talk) 19:40, 9 February 2014 (UTC)

Alternate proposal: Modify article-space EditNotice

Modify Template:Editnotices/Namespace/Main so it will display whenever someone edits an article where the same title exists in Drafts:. davidwr/(talk)/(contribs) 03:33, 9 February 2014 (UTC)

Categories on Drafts

I think we could take another look at the prohibition against having "live" categories on Draft articles. Having categories on drafts will enable navigation around Draft-space and make searching for drafts in a particular subject area possible. If such categories include the word "Draft" they won't be confused with similar mainspace categories. Roger (Dodger67) (talk) 16:16, 5 February 2014 (UTC)

The problem with "class=Draft" is that the WikiProject Council has flatly refused to even consider implementing it as one of the default set of "class=????" parameters. They say each project is individually welcome to do so. They refuse to acknowledge the simple fact that this is something that Draft-space needs to have done so that it makes sense of even having a Draft space at all. We all know that having it as an optional parameter that Projects must actively choose to implement means that you can count the ones that will actually do so, on one hand. It is needed for Draft-space to function properly - it's utility for Projects is secondary but the WikiProject Council only cares what it means to individual Projects. Their dog-in-a-manger attitude is frustrating - it almost verges on intentional hostility towards Drafts. Roger (Dodger67) (talk) 19:44, 10 February 2014 (UTC)

Requested Moves and overwriting targets with edit histories - OPTION: Move problematic target page to DRAFTspace

As we have been discussing moving CSD and PROD candidates to DRAFT namespace, it occurs to me that there's another case also to consider. WP:RM sometimes has requests to move one page atop a destination with its own non-trivial edit history. In keeping with the other proposals on this page, I think that the Administrator who processes such a Request should have the option at their discretion to move the target-to-be-deleted into DRAFTspace, and be explicitly detailed into the instructions for processing requested moves.

This came up when I was thinking about how to handle the case at Talk:Decoupling (disambiguation) which ended up with a PROD refusal. -- 70.24.244.161 (talk) 23:55, 12 February 2014 (UTC)

Survey (Requested Moves and overwriting targets with edit histories)

Feel free to state your position on the renaming proposal by beginning a new line in this section with *'''Support''' or *'''Oppose''', then sign your comment with ~~~~. Since polling is not a substitute for discussion, please explain your reasons, taking into account Wikipedia's policy on article titles.

Discussion (Requested Moves and overwriting targets with edit histories)

Any additional comments:
  • Declining the requested move until discussion happens and it's clear what will wind up where long-term should typically be preferred over "move to anywhere other than final destination." The only exceptions I can think of are "it's clearly A Bad Thing to be left where it is" and/or "Something else needs to be moved to where the to-be-moved page currently is." Another possible exception is when the person making the move would have the right to do a "db-user" request, and is requesting a move to Draft space instead. davidwr/(talk)/(contribs) 17:32, 13 February 2014 (UTC)

Feedback wanted on new designs

Tracked in Phabricator
Task T62973

Jumping off the above topic and older ones about this topic, I wanted to share some early mockups by Pginer, the designer on the project. The goal: to provide extra indicators to people reading drafts that they are not yet encyclopedia articles.

We're basically proposing three changes, first and foremost:

  1. Highlighting the word "draft" more prominently, either by replacing the plain "Draft:" with a highlighted version or by adding a extra indicator below the title.
  2. Making the page title a lighter shade of grey, instead of the true black of regular page titles
  3. Changing the site subtitle element, which currently reads "From Wikipedia, the free encyclopedia", to be something that emphasizes that a draft is a work in progress. Ideally we could also use this as a call to edit or comment on a draft. (Personally I really like this idea.)

We could also optionally include:

  1. Action buttons to edit or publish a draft.
  2. An indicator of how old the draft is, e.g. "Created 2 months ago" etc.
  3. Indicators on edit mode too (see page 2 of the PDF)

These are all quite simple changes for us to implement, on the Foundation software engineering side. I think the big advantage to implementing a change in this style is that it will automatically apply to all draft pages. That means we won't need to go around and add a template to all drafts (or write a bot to do so). It also means the markup of the page will be slightly more simple, which is an advantage for new/anonymous editors who find wikitext intimidating or confusing at times. We could still then use the template for when a draft happens to get lots of prominent traffic (such as if it's linked to from a popular AFD, or from an external website like Reddit or a news story).

  • Option A
    Option A
  • Option B
    Option B

Please comment about the advantages or disadvantages of these various design options. This is just our first complete pass on this design problem. :) Steven Walling (WMF) • talk 23:31, 18 January 2014 (UTC) Ping @TheOriginalSoni, Northamerica1000, HectorMoffet, This, that and the other, Scott Martin, and Davidwr: since you all commented on ways to emphasize draft status above.

I like the idea of the extra indicator below the title although, I would change "created 2 months ago" to "last edited 2 months ago", as I feel showing if the draft has been abandoned or not is more important than the age of the draft. I'm fine with all other proposed changes.--TriiipleThreat (talk) 00:07, 19 January 2014 (UTC)
  • I don't think I like either of these designs. The big problem with putting a little yellow "Draft" button next to an article with Draft: removed from it is that someone who is sent the HTTP link and goes there is >70% likely to just assume that it is a Wikipedia article and "Draft" is some general assessment of status. We have had so many articles festooned with huge banners expressing various problems and grievances with the content that this is nothing compared to that. Having "Draft:" before the title is at least something new and hard to miss. But I also think we can have a byline like the one on the right, but I'd prefer to have something like "Article proposed for use in Wikipedia. Help reviewing or discussing its content." After all, every article is a work in progress and always will be; I want to try and make it clear that "This article is not yet part of Wikipedia." (an even stronger version for the first sentence that I might even prefer) Also, I'm not fond of the "orange bar that floats during scrolling". Keep in mind that (a) I'm usually browsing with Javascript off (b) because I like it that way (for example, I don't like going to hit on my contributions when I log into Commons and getting uploads instead because the button jumped around, I don't like playing with collapse/hide except in rare instances, and I don't like the lag that the extra scripts impose) I can't really criticize that aspect without seeing it, but ... I just about know I'm not going to be happy with it. For one thing, I don't want a smaller window to read. I like to skim large amounts of text at one time and literally I can see where the text gets interesting before I read it. Wnt (talk) 15:51, 19 January 2014 (UTC)
  • Issues with this design -
  • Greyish title makes it less visible, not more.
  • I personally am not a big fan of Orange or the shade used but I'm willing to try it.
  • Option B does not make it intuitive that the word "Draft" is not a title, than something like our Quality ratings. Option A misses out the prominence. Option C (page 2 of the pdf) is less worse than either of the two, in terms of just the header.
  • Current wordings are ambiguous. We should stick with something the community has decided upon. At the very least we require the following - "This is not a Wikipedia article: This is a draft, a work in progress which may or may not be ready for inclusion in the mainspace. "
  • As mentioned above, replace "Created 2 months ago" with "Last edit 2 months ago"
  • The entire design should ultimately be easily editable by the community if and when required. A possible way to do that would be to have a (full protected) page listing all the changeable attributes of the design (like the notice and site subtitle element) and basing the notice on that page. I am taken to understand that PageNotice (from gerrit:105434) would make that implementation a lot easier.
  • The design change must necessarily be holding up (or atleast not breaking down) for all users, regardless of the browser or whether JavaScript is enabled.
Other than that, this is a step in the right direction though I'll prefer it comes much earlier
Cheers,
TheOriginalSoni (talk) 03:42, 20 January 2014 (UTC)
  • I think these designs are too subtle. Wikipedia is not known for its subtlety, especially with respect to article maintenance tags - see Wnt's comment above. We've "cried wolf" to some extent, by calling out relatively minor content and style issues with in-your-face banner boxes, so I think we need to do something even harder to miss for drafts. Two really useful changes could be:
    • A different background color, say, a very pale yellow-orange shade. This would, more than anything, distinguish drafts from "real" articles by catching the viewer's attention straight away. "Hmm, this article is a different colour. What's up here? Why does it look different?..."
    • A gerrit:105434-implemented box, à la article maintenance tags, at the top of every draft, with a distinctive color scheme and image/icon. This would answer the reader's question "why does it look different?" by explaining the status of the article, and including a date of last edit and call-to-action.
  • I do like the idea of altering the site tagline, but I don't see the value of changing the color of the page title, especially if the background color of the page is to be changed. Hope this helps. — This, that and the other (talk) 07:52, 20 January 2014 (UTC)

To echo others--

  • We need the letters "Draft:" to appear in title. Option B doesn't make this clear enough that Draft is part of the title, not a quality assessment.
  • I don't think "time since created" is that important of a measure to be displayed so prominently on a draft.
  • Stronger language as per WNT; Everything's a work in progress, but "This draft is not yet part of Wikipedia." is more definitive.
  • This, that and the other has an excellent point-- these are all very subtle, while the change to Draftspace is a very dramatic change. A draft article should LOOK different, in its entirety, not just in its title. We don't want any chance someone will mistake a draft for an article. --HectorMoffet (talk) 08:51, 20 January 2014 (UTC)

I would like to see the Wikipedia globe logo changed in Draft space to a version with more missing jigsaw pieces, towards the bottom. I think this would instantly show in a visual way that this is not the regular Wikipedia. Diego (talk) 17:10, 20 January 2014 (UTC)

Even better, put a new logo with a guy on a ladder "installing" a piece into a "frame" that has only a couple of pieces in it, and put that logo on the same line as the article title. Any artists out there? davidwr/(talk)/(contribs) 18:22, 20 January 2014 (UTC)
  • Thanks for the feedback, this is really useful to iterate on the designs. I wanted to provide a little more of background on some design decisions so that we can think on better alternatives:
    • Draft status indicator. I tried to avoid this to look like a banner to prevent Banner blindness, but I agree that we need to test this well with in practice to make sure it is not possible to miss.
    • Greyish title. The idea was to communicate that the content is not "solid" or permanent yet (e.g., like an unsaved document) compared to an article. If we style the "Draft:" part as the rest of the title, then it goes against the goals of making clear that this is a draft. We should consider this issue.
    • Wording for the site subtitle. I would try to keep it short to avoid being missed. Something along the lines of "Not yet part of Wikipedia" as proposed looks good to me. Longer alternatives may deliver a more precise message, but it may be delivered to less users.
    • "Created X months ago". This message was intended to show where we can indicate some relevant status info related to the draft. I agree that other info such as availability of a published version, or last edited should take precedence, and be displayed instead of the creation date when such info s available.
    • Subtle background colour. That was considered for one of the designs but it was too subtle to notice (needs adjustment to be noticeable but not distracting). This may work as a complement to other main indicators.
    • Making edit options more prominent. I thought it makes sense to communicate that drafts purpose is to be edited, and may help to differentiate the layout enough to be noticed.

Pginer (talk) 20:07, 20 January 2014 (UTC)

    • Just hopping in to say that Point 2 wasn't intuitive, and so went the wrong way towards focusing attention on the draft. Also, you might want to consider highlighting the entire title in a different way than just try and change the draft part. As said above, we want it to be clear that it's part of the title so people do not assume it is in mainspace. TheOriginalSoni (talk) 20:08, 21 January 2014 (UTC)
  • Steven Walling (WMF), this kind of delay is precisely what the enWiki community dislikes. What could have been a relatively simple process that was quickly implemented is now-looking like one that may not even be implemented quick enough. Can we please just make a generic way to add a pagenotice to all pages in a namespace? Until the WMF comes up with a better looking alternative, we would be more than happy to include a Pagenotice on the Draft articles as a useful function for now. TheOriginalSoni (talk) 22:45, 18 February 2014 (UTC)
    • Hey. I'm sorry if there's a delay, but I don't think there's an arbitrary reason to be in a rush? Drafts are quite small right now, and still NOINDEXed. They're not being viewed and edited en masse by readers/anonymous editors who are clearly misguided, so we're heading off a future problem rather than stemming the tide on a current issue. Since we want drafts to be able to scale to the level of AFC and beyond, but not keep some of the problems of the AFC workflow, we need to do this right and think about the solution that will work in the long run. In the meantime: Pau has been working on another iteration on this, based on feedback from the community on this thread. I'll make sure we post that this week. As for using namespace-wide page notices... the feedback from the developer community (not just my team of staff) was that it's the wrong approach from a technical and design perspective. Steven Walling (WMF) • talk 23:00, 18 February 2014 (UTC)

Survey, Guideline for CSDD

A previous suggestion is for CSDD as a companion for CSD. 

A similar re-branding can occur regarding CSD. We would need to create some criteria for speedy draft designation, CSDD if you will; which criteria could define mainspace examples that would be clearly appropriate to move directly into the draft namespace.—John Cline (talk) 13:34, 23 December 2013 (UTC)

This meshes with a previous suggestion I have made for a speedy incubate.  The reception has been good, but nothing ever came of it.

Two example criteria:

  1. WP:CRYSTAL articles for future events.  It is often urgent to remove these from mainspace as promotional, and these are well-suited to draftspace; because if there is verifiable material, there will be more material when the event occurs.
  2. Breaking news stories.  Notability is in flux.  Serene Branson is a classic example.  Editors worked on an article, argued extensively at AfD, and bickered at DRV; but a CSDD would have allowed some time to pass before trying to assess notability.  Allowing two weeks to pass to allow the weekly news magazines time to weigh in has been suggested.  IMO, it is urgent in these cases to get such articles out of mainspace without stopping development.

Unscintillating (talk) 00:34, 10 February 2014 (UTC)

Support creation of a CSDD guideline

  1. Support  Unscintillating (talk) 00:36, 10 February 2014 (UTC)
  2. .

Oppose creation of a CSDD guideline

  1. .
  2. .

Discussion of creation of a CSDD guideline

Suppressing categories, etc.

It looks like regular categories aren't used on drafts, so I use <nowiki> to suppress those as I would in a userspace draft. How about WikiProject tags on the talk page, though? My first instinct was to suppress them as well, but WikiProjects may find it useful to see which drafts pertain to their areas of interest. Has there been previous discussion on how to handle these issues? --BDD (talk) 19:54, 11 February 2014 (UTC)

One of the main arguments for the creation of Draft-space is the ability to have WikiProject templates (and proper Talk pages) so please don't suppress them, in fact they should be added with vigour! BTW the proper way to "suppress" article categories on drafts is to put a colon in the link in front of "Category" like this - [[:Category:Draft articles]] There is a discussion further up this page about Categories on Drafts. -- Roger (Dodger67) (talk) 22:57, 11 February 2014 (UTC)
  • I'm not aware that there is a display difference between:
      [:Category:Living people]</br>
and
      <nowiki>[Category:Living people]</nowiki>
One takes six characters to code, and the other takes 17.  Unscintillating (talk) 01:49, 12 February 2014 (UTC)
Personally, I prefer the <nowiki> approach for its simplicity. Especially if there are many categories, it can actually be fewer characters anyway. I suppose there's a benefit to the colon approach in that you could check the what links here from a category and see applicable drafts. Right now that doesn't sound super useful, but it may be worth adopting. --BDD (talk) 19:01, 13 February 2014 (UTC)
The issue with either approach is that it increases complexity of markup for new users to understand. They're supposed to format categories on drafts one way, but a different way when they apply them to any other page? We can potentially suppress categories from appearing in listings on the main Draft namespace pages, but allow them on Talk pages. Let me just ask the developers on my team. Steven Walling (WMF) • talk 00:13, 14 February 2014 (UTC)
Thanks, that would be great. --BDD (talk) 00:52, 14 February 2014 (UTC)

I'd like to propose a different solution:

  • We explicitly acknowledge that normal categories should not be used in Draft: space articles. This allows for automated methods (bots etc.) for any of the methods above.
  • We declare a subclass of category that starts [[Category:Draft Articles ...]] for use only in the Draft space This allows for [[Category:Draft Articles started November 2014]], [[Category:Draft Articles being edited by the Guild of Copy Editors]], etc, etc. which can be removed automatically from article space articles.

Does that sound productive? Stuartyeates (talk) 01:02, 14 February 2014 (UTC)

Proposal: Require mainspace categories to be embedded in a new template, Template:DraftCategories when they are used outside of mainspace. This template will take the 1= parameter and turn all instances of
[[Category:
into
[[:Category:
if the file is not in mainspace. For flexibility, it will also create a similar template, Template:DraftNonFreeFile, which turn all instances in the 1= parameter of
[[File:
into
[[:File:
For the sake of programming consistency, these should probably be a single template with multiple nicknames.
We will still have to deal with issues like templates that put pages into categories and how to handle non-free files in infoboxes. davidwr/(talk)/(contribs) 22:21, 14 February 2014 (UTC)
Support development of this proposal. One advantage of using the leading colon suppression method is that the existing AfC tool strips it out correctly when Accepting a draft into Mainspace. That feature can be kept when AfC tools are adapted for Draft-space. Roger (Dodger67) (talk) 08:32, 23 February 2014 (UTC)

Should AfC and Article Incubator both be moved to Drafts, and is there a need to distinguish them?

There are now three options for "draft" articles: the Draft namespace, WP:Article incubator for semi-deleted articles, and WP:Articles for Creation for partially constructed articles. I don't think we need all these; and I do think a separate namespace is a nice clean idea that will make it pretty obvious to all editors where to find draft articles. Question: is there any particular need to distinguish an AfC from an incubated article, except for a link to the relevant deletion discussion on the talk page using the standard template? Wnt (talk) 21:35, 18 December 2013 (UTC)

  • Responses
    AfC to Drafts: Yes, once the AFCH tool can support the draft namespace without having to use a beta/dev version of the tool
    Incubator to Drafts: Yes, post haste
    Distinguish: I would say no. AfC drafts will have an AfC submission banner on them to help us find the ones that are in the AFC pipeline. I would like to see a transparent template that is applied to all Draft pages which indicates when the page landed in the draft namespace as a category(i.e. Category:Draft Namespace Assumption/07 January 2014) so that we can track down Drafts that have been forgotten by their creators/contributors and to start a clock on potentially removing the draft under the argument that we're not a web hosting service and that the content can be retrieved at any time via a REFUND request. We really don't want to have another massive dark vault of pages that sits around and never shows improvement only to have the wiki community at large throw their hands up and authorize annother CSD rationale to deal with Drafts that no editor is expressing interest in improving. Hasteur (talk) 13:43, 7 January 2014 (UTC)
  • Why not? I've never understood the rationale of deleting drafts under a time limit. Removing drafts based on the quality and suitability of the content, sure; if the page is a personal recollection of stuff that could never be adopted in articles, propose it for deletion any time and kill it dead. But if the content could reasonably belong in the encyclopedia, just because no editor expressed an interest in improving it now doesn't mean that no one will find it interesting later, some months from now or two hundred years in the future. Wikipedia's nature as free content makes it intended to last forever, and an abandoned draft could very well provide whatever hints a scholar from a future civilization needs to kickstart a research project about our knowledge on an obscure topic. So why make iterative improvement harder by removing viable content from sight, when that content is not featured as a Wikipedia article? Diego (talk) 14:04, 7 January 2014 (UTC)
  • While space is cheap, we don't need to be the host for every single thought that ever occurred. Following your future scholar example, a scholar is more likely to spend time working on a research project if the page is in main space (as we know that academia is guardedly hostile to us). They're not likely to use a draft that never mustered enough interest or attention to make the transition to main space. Most of these drafts will have a single editor that focuses on it for a short while, looses attention and then abandons it. If a new editor comes along and discovers that there was a previous attempt at creating a article, they can request the text back as a starting place to continue the effort with nearly zero effort. The purpose is to build an encyclopedia, not provide indefinite storage of text. Hasteur (talk) 14:55, 7 January 2014 (UTC)
If the purpose is to build an encyclopedia, the mechanism is iterative improvement; any deletion of valid content hurts that purpose. So I ask again, what is the purported benefit of making it more difficult to recover the content by introducing a human in the loop? This artificial barrier impedes the readers from assesing by themselves whether the content is relevant on the spot, and introduces a delay which can go from hours to days (thus making assessment of a large collection of drafts much harder). There should be a very good motivation to support hindering readership in that way, but I've never seen it articulated. Diego (talk) 15:54, 7 January 2014 (UTC)
We're not supposed to be the great compendium of human thought. The delay of requesting a refund is at most a few hours, therefore per WP:DEADLINE we can afford to give that much of a delay. Readers at large (not ones interested in improving the draft) aren't going to be in the draft namespace, they'll be reading the regular wikipedia articles. I think the primary users of the draft space are people who want to create articles those who improve articles. Hasteur (talk) 18:26, 7 January 2014 (UTC)
Making people wait for review sucks and should be avoided if we can. No one like the long backlog that AFC has now. Steven Walling (WMF) • talk 19:36, 7 January 2014 (UTC)

WP:Abandoned drafts

All pages with titles beginning with Wikipedia:WikiProject Abandoned Drafts/

Now that DRAFT is live, shouldn't these all be moved into DRAFTspace? (the draft pages, not the project pages) -- 70.50.148.248 (talk) 05:43, 1 February 2014 (UTC)
Agree Great idea, we should do this. --Rezonansowy (talk • contribs) 17:58, 1 February 2014 (UTC)
 Done Soni (talk) (Previously TheOriginalSoni) 01:23, 14 March 2014 (UTC)

Notice to group regarding Template:AIAssessment; use it in the Draft namespace?

I recently posted a discussion to delete {{AIAssessment}}; the discussion can be found here. This template was previously used to assess drafts in the Wikipedia:Article Incubator namespace. I proposed deletion of it (due to the Article Incubator now being retired), but the template's creator brings up a good point: could this template somehow be utilized for pages in the "Draft:" namespace? Or, for example, is consensus to use method established in Wikipedia:Articles for creation for approving article creation from the "Draft:" namespace? (Either way, input on the TfD discussion would be greatly appreciated.) Steel1943 (talk) 13:59, 14 March 2014 (UTC)

@Unscintillating: I provided this notification here as a courtesy to the template creator (who commented on the page directly after my nomination.) Steel1943 (talk) 14:11, 15 March 2014 (UTC)
  • I take your point that you are here as a courtesy to the template creator.  But now that you are here, the concept amounts to "use it or lose it".  I don't agree that draftspace is impelled to convene an emergency caucus to make a determination.  If you didn't like the possibility of the template being used, I think you could have put an "historical" template on it, without having a direct impact on draftspace going forward.  Unscintillating (talk) 14:48, 15 March 2014 (UTC)

Draftspace and NFCC

I have received a preliminary ruling from Masem that the draftspace is not articlespace for NFCC images.  The rule at WP:AI was that such images had to be removed when added to the incubator.  As I understand the process, this means that they will be deleted in ten days.  This creates multiple problems, so I wonder if there are any other options.  I looked at the AFC mainpage, but I don't see the issue mentioned.  Unscintillating (talk) 23:05, 15 March 2014 (UTC)

  • The rule is correct. As I recall from AFC, we do not allow NFCC images to be permitted to drafts until they are accepted (i.e. they are in Article-space). It would be sensible for draftspace to follow the same guidelines and maybe just keep the image's link preserved in the talk page so the image could be undeleted when the draft reaches articlespace again. Soni (talk) (Previously TheOriginalSoni) 09:53, 16 March 2014 (UTC)
  • The rule is a good one. Non-free content is only allowed on mainspace articles. If you preserved the links until the article as moved into the mainspace, any editor could go request for undeletion at WP:REFUND. As the image would then be in compliance, any administrator could undelete unless there were other concerns that need to be handled. -- TLSuda (talk) 13:17, 16 March 2014 (UTC)

Moving a mainspace article to Draft

I just moved Adaline (film) to Draft:Adaline (film) and the main space page has a redirect to the Draft. I don't think that is something we want to happen. The question is, what should happen automatically when it gets moved? Should the page be deleted? - Favre1fan93 (talk) 22:07, 18 February 2014 (UTC)

You can have the redirect speedy deleted.--TriiipleThreat (talk) 22:34, 18 February 2014 (UTC)
I understand that's an option, but I just feel that the default should not automatically make a redirect to the Draft article. - Favre1fan93 (talk) 22:45, 18 February 2014 (UTC)
Is there a way to suppress the default automatic creation of a redirect when the target is Draft-space? Roger (Dodger67) (talk) 08:28, 23 February 2014 (UTC)
Yes, but only admins have that tool.  Template:db-r2 or template:db-g6 is the way to go.  I've added a section to the Project page on Incubation that documents the procedure.  Maybe we should discuss a request to the developers, as this may be easy to implement.  The admins do a good job, but they are not likely to complain if this job is taken away.  Unscintillating (talk) 18:23, 23 February 2014 (UTC)
Thanks for the info Unscintillating. Like I said, if we can cut out a step in this process by having it not create the redirect automatically, that might make it easier for everyone. - Favre1fan93 (talk) 19:15, 23 February 2014 (UTC)

Draftlock

  • Ok, here is a new synthesis of this section along with #Proposal for a placeholder on mainspace above.  I suggest that this is a draft proposal to submit to the implementors.  This proposal introduces a draftlock concept.
A move from articlespace to draftspace does this
  1. Move the article, with an entry in the edit history documenting the move.
  2. Delete the cross-space redirect.
  3. Add a Draftlock to the articlespace deletion log, which is a variation of a salt.  With a draftlock, only a move back from draftspace is allowed to create an article.  But there is an exception for the creation of redirects, as listed in the Notes below.
  4. An articlespace title with a Draftlock can be salted, i.e., salting is not changed.  This is specifically useful to prevent restoration of a future-event topic.
  5. If the talk page doesn't exist, create it.  It can say "Talk page created during the move of <article x> to draftspace."
  6. Move the talk page to draftspace, with an entry in the edit history documenting the move.
  7. Leave the cross-space redirect in place, and draftlock it.
A move from draftspace to articlespace does this
  1. Clear the draftlock on the main article.
  2. Move the article, with an entry in the edit history.
  3. Delete the remaining redirect.
  4. Clear the draftlock on the main talk page.
  5. Move the talk page, with an entry in the edit history.
  6. Delete the remaining redirect.
Notes
  1. For an articlespace title that is draftlocked, redirections can be created with the draftlock still in place. 
  2. For a draftlocked redirect (both the article and the talk page), the draftlock will prevent the edit if someone attempts an edit that removes the redirect.  The draftlock will remain in place if the redirect is deleted.  The edit history for the redirect appears in the draftspace edit history.
  3. Articles and talk pages in draftspace with an articlespace draftlock in place cannot be deleted.  They must be moved back to mainspace for deletion.  As per the WP:AI, this is already standard practice.  Relatedly, the only way to remove a draftlock is with a move back from draftspace.
  4. Articles with a draftlock cannot be renamed.  They must be moved back to articlespace to be renamed.

Unscintillating (talk) 01:07, 14 March 2014 (UTC)

Oppose: This requires the buy in from WMF to develop a new type of moving and a new type of protection that can be overriden. As evidenced by the fights just to get the draft namespace, WMF is overwhelmingly opposed to making any core system changes. Our current solution of leaving a redirect to a related article (possibly with a {{R from move}} style template below to indicate that a article was here, but has been pulled to Draftspace for significant improvement). Further these types of locks will make a mad land rush for namespace addresses on everything that could be reasonably (or unreasonably) created. I have no objections to the redirect for articles we yank to draftspace, but object to the reservation of destination if a draft article exists for that name. Hasteur (talk) 12:42, 17 March 2014 (UTC)

Drafts never an orphan

"{{Orphan|date=March 2014}} removed. This draft will not be an orphan when it is moved to article space." This is what I said for Draft Kimberly Wright Cassidy.

Do other editors agree that draft articles are never orphans, and perhaps other tags are not appropriate in draft articles, either?--DThomsen8 (talk) 12:40, 21 March 2014 (UTC)

  • The article is now at Draft:Kimberly Wright Cassidy.  Unscintillating (talk) 01:48, 22 March 2014 (UTC)
  • One of the bottom lines at a volunteer organization is the people doing the work, so I don't think that main article contributors in draftspace are compelled to accept tags.  There is a counterweight here that tags in theory improve an article.  Another viewpoint is that draftspace is for collaborative editing, so if a main article contributor doesn't like the type of collaborative help he/she is getting then a consideration is to move the article to userspace.  What do you think?  Unscintillating (talk) 01:48, 22 March 2014 (UTC)
I made a mistake and created the article in mainspace instead of draft space, and another editor moved it to draft space. The draft article is in the draft namespace as I expect it to be used as part of the [Wikipedia:Meetup/SevenSisters/March2014SevenSisters]] Editathon at Bryn Mawr College next Tuesday.
The tag {{linkrot|date=March 2014}} is the only one I would apply myself, as it provides the Reflinks tool, which can be used to polish up what otherwise would be bare URLs. --DThomsen8 (talk) 20:38, 22 March 2014 (UTC)

Classification of drafts

From what I can gather, drafts arise from AFC or outside of AFC from a new creation, transfer from userspace or transfer from mainspace. In the first case, the draft should contain {{AFC submission}} and in the second case {{Draft article}}. Those that are in neither (e.g. Draft:Gogyōka) could be listed in a database report for maintenance or have {{Draft article}} bot-added. We could have database reports of 'stale' drafts and such.

However I haven't found a definite consensus on the idea of placing workpages, article sandboxes and similar pages in draft namespace, which are occasionally created in talk space (examples: Talk:Thelema/Rabelais, Talk:Solar energy/Sandbox) with the same disadvantages, especially if we intend in the future to use another discussion system.

As a note for further development, any kind of hardcoded association between a mainspace article and its corresponding draft article should consider that they don't necessarily have the same subject - see Thor 3 and Draft:Thor 3 for example. Cenarium (talk) 00:32, 23 March 2014 (UTC)
workpages and anything in user sandboxes should remain as they are now, so user draft articles do not get changed or published. Draftspace articles can and do get published in mainspace, regardless of the wishes of the creator. --DThomsen8 (talk) 16:57, 29 March 2014 (UTC)
If an editor of a userspace-draft or a collaborator speaking for a "workpage"-tagged collaboration explicitly requests a move to the Draft: page or if he uses a template like {{afc submission}} (aka {{subst:submit}}), this should override any restrictions mentioned in this discussion. davidwr/(talk)/(contribs) 21:08, 29 March 2014 (UTC)
In the case of WP:AFC submissions, current technical limitations on the AFC Helper Script gadget mean that AFC submissions are frequently still moved to Wikipedia talk:Articles for creation/Pagename instead of Draft:Pagename. Any rules we develop regarding what should and should not be in Draft: should have a general allowance for ignoring the rules if there is a good technical reason supported by either established practice (as is the case with the AFC Helper Script) or and obvious/non-controversial need (which, by definition, I can't give an example of). In other words, include the explicit exemption rather than forcing editors to invoke WP:Ignore all rules. davidwr/(talk)/(contribs) 21:08, 29 March 2014 (UTC)
@Cenarium: I have never seen a case where the use of the new {{draft article}} template in a mainspace page was taken as an automatic reason to move it to Draft: or Wikipedia talk:Articles for creation/. It has been past (and likely current) practice to sparingly and judiciously move a "not ready for prime time" newly-created page from mainspace to Wikipedia talk:Articles for creation/ as an alternative to deletion when deletion would be the almost-certain outcome and the newly-created article could reasonably be improved with effort and/or a likely-non-notable topic will become notable soon but not soon enough to avoid falling at AFD. I'm not sure whether this practice should be encouraged with similar mainspace pages that just happen to have {{draft article}} on them or not.
This should probably be discussed as a formal proposal:
Should newly-created mainspace pages that were marked as a "draft" by a primary editor and which are likely to be deleted at AFD or through a speedy-deletion request be moved to Draft: as a preferred alternative to initiating a deletion process, with the understanding that any time-critical issues (e.g. copyright violations) are immediately dealt with and there is a good reason to believe that all remaining issues that would lead to deletion can be resolved while it is in the Draft: namespace?"
davidwr/(talk)/(contribs) 21:28, 29 March 2014 (UTC)

{main cat only}

I have created {{main cat only}} (or {{article cat only}}). It is intended to be a next option to prevent categorisation of non-articles. It might be interesting & easy for draft editors. One issue is mentioned for co-thinking at village pump. Enjoy this:

{{main cat only|Missions to the Moon|A, {{PAGENAME}}|note=category added by [[Template:infobox building]]}}

-DePiep (talk) 14:18, 13 March 2014 (UTC)

  • Let's see if I understand.  When preparing an article for draftspace, [[Category:Living people]], can be changed to:
{{main cat only|Category:Living people}}

and then does not need to be modified during future moves between articlespace and draftspace?  Unscintillating (talk) 23:30, 15 March 2014 (UTC)

That is right. The 'does not need to be modified' is the main feature. Together with automated settings & options.
But I've had to set this up otherwise (using {{main other}}). I wanted to feedback to the editor a message on the page saying "this page will be added to Category:X when this page is in mainspace" (instead of nothing at all in Draft space).
Probably will have it deleted. -DePiep (talk) 09:03, 9 April 2014 (UTC)

LastSubstantiveEditDate

Lessons learned from the incubator, Part 1

A hot topic at the incubator was an operational definition for "stale draft".  Since there is no deadline at Wikipedia, some editors were satisfied that regular editors were getting access to some of the material that had been removed from mainspace, material that was otherwise only visible to admins.  At MfD, there was a case within the past few months in which a Userspace article that was seven years old was kept.  However, IMO the incubator and thereby draftspace is a place for communal editing, not an archive or a library.  At the incubator, a consensus briefly developed that one year was the appropriate amount of time for an article to exist without substantive edits before volunteers intervened.  One lesson learned is that software cannot identify the difference between housekeeping edits and substantive edits, and whatever period of time is selected, a new mechanism is needed to determine the date of the last substantive edit.  Unscintillating (talk) 22:10, 8 February 2014 (UTC)

Would this imply that a draft should *not* be edited by volunteers in the first year or so? I don't think there's a need for that. It makes sense that a draft in user space may be owned by its creator, but the Draft namespace belongs to the community. Articles are not owned, so I don't see why drafts in project space should be. This is how we handle essays, for example; essays in WP space are open to anyone. If the author doesn't want this, the page is moved to their user space. Diego (talk) 22:49, 8 February 2014 (UTC)
  • Communal editing may take years to develop an article. Triggers for communal tasks (based on specific time lapses (other than closing active discussions) are usually rejected, as they interfere with the process to write articles. Diego (talk) 19:36, 9 February 2014 (UTC)
  • Draft space is not the incubator - it doesn't make sense to compare the two as if they were. Articles only arrived to the incubator from deletion discussions, but draft articles can be created directly or moved from the main space without discussion, through a WP:BLAR. Diego (talk) 23:14, 9 February 2014 (UTC)

A first proposal to implement an operational definition for LastSubstantiveEditDate

There is a way to do this with the Defaultsort parameter, that would sort all articles in all categories by age.  It has the disadvantage that it takes over an existing function for a novel purpose, and must be reverted when promoting an article to mainspace.  It has the advantage that it can be done with the existing software.

It uses the yyyy-mm-dd date format which is inherently machine sortable.  For example, an editor could review the edit history of Draft:Fort Pierce Central High School and then make this addition:

{{DEFAULTSORT:2014-01-22 Fort Pierce Central High School}}

Likewise, Draft:Example could have this addition:

{{DEFAULTSORT:2014-02-03 Example}}

"Fort Pierce Central High School" would now appear before "Example" in Category:Draft articles as follows:

 • 2014-01-22 Fort Pierce Central High School
 • 2014-02-03 Example

Unscintillating (talk) 22:10, 8 February 2014 (UTC)

Discussion (A first proposal to implement an operational definition for LastSubstantiveEditDate)

If we can find a better way than this, use it. Overloading DEFAULTSORT is just asking for trouble. davidwr/(talk)/(contribs) 22:30, 8 February 2014 (UTC)

A second proposal to implement an operational definition for LastSubstantiveEditDate

Second proposal, part A

Add an optional parameter called LastSubstantiveEditDate to Template:Draft article.  This is by itself useful in manually maintaining a list of article ages.  This can be implemented with a bold edit.  Unscintillating (talk) 22:10, 8 February 2014 (UTC)

Second proposal, part B

Automate the parameter using new software, which involves the developers.  If the parameter is unpopulated, software looks in the edit history and assumes that the most recent edit is a substantive edit.  The developers provide a display with draft articles sorted by the new parameter.  Unscintillating (talk) 22:10, 8 February 2014 (UTC)

Discussion (A second proposal to implement an operational definition for LastSubstantiveEditDate)

For the sake of simplicity, unless marked otherwise, all bot- and minor- edits should be considered non-substantial and all non-minor, non-bot edits should be considered substantial. This will avoid the problem of "oh, I forgot to mark the edit as substantial." If minor edits are likely to be substantial, change the above to "bot=presumed non-substantial, non-bot=presumed substantial" unless marked otherwise. davidwr/(talk)/(contribs) 22:28, 8 February 2014 (UTC)

A third proposal to implement an operational definition for LastSubstantiveEditDate

Create new categories, one for each month.  For example

Category:LastSubstantiveEditDate 2013 (12) December
Category:LastSubstantiveEditDate 2014 (01) January
Category:LastSubstantiveEditDate 2014 (02) February,

Unscintillating (talk) 22:10, 8 February 2014 (UTC)

  • Comment: if we want drafts not edited after a certain period to be called out in some way, there is probably no reason to rely on parser functions and categories. These are pretty hackish, from a technical standpoint. On the backend, we can quite easily distinguish between drafts that have been edited by others, by the original author, time between edits, minor vs. non-minor edits, and size of edits. Automatically placing such articles in a queue of some kind (and not just a category) is not that difficult. I think the best thing the community can decide right now is what kind of drafts we want to consider stale. Once we know that, we can shape the technical definition based on community needs, and then arrive at a decent working approximation. Steven Walling (WMF) • talk 23:17, 8 February 2014 (UTC)
    • Counter comment Getting Drafts enrolled in some sort of "Draft created" category system so we know when the draft arived here allows houskeeping editors to look through the submissions on the whole and consider which ones are making progress and which ones aren't. As the operator of the G13-nominating/qualifying bot, scanning through the members of the category and seeing when the page was last updated (at all) makes it easy to figure out what's going on. I am uncomfortable with the fuzzy line criterion as to if the draft is eligible. What qualifies a stubstantive edit? If one person takes a hard line that fixing a parameter constitutes a substantive edit then you're going to have very few drafts ever land in the eligible state. If an editor takes the viewpoint that anything under a complete sentence change is not substatntive, you'll have vast swathes landing in the garbage heap every day. Hasteur (talk) 22:42, 18 February 2014 (UTC)

A fourth proposal to implement an operational definition for LastSubstantiveEditDate

Combining two of the above comments yields a fourth proposal: Add a new "Housekeeping" checkbox which is a companion to the minor edit checkbox.  This allows software to know the difference between a housekeeping edit and a substantive edit.  This has a training overhead in teaching editors how to use the checkbox.  Would it only apply to Draftspace?  Unscintillating (talk) 15:05, 9 February 2014 (UTC)

Discussion (A fourth proposal to implement an operational definition for LastSubstantiveEditDate)

  • I'm not personally seeing that this is a way to go for now because it requires training of all editors, whereas the previous proposals only need the wikignomes to be trained.  As proposed, there is no manual process to correct the LastSubstantiveEditDate.  Unscintillating (talk) 15:05, 9 February 2014 (UTC)

G13 one year limit

I am moving the following comment from my talk page:

I am confused by this edit. The CSD policy does not discuss a one year limit for G13 or any other context. Where did that come from? If it is on another policy page then it should probably be noted at WP:CSD as well. SpinningSpark 14:48, 7 April 2014 (UTC)
The above discussion left this page as opining that there is no deadline at Wikipedia.  Your edit wants a six month deadline, which as I understand it is the norm for AfC.  This is not AfC.  I have already stated above that previous experience is that one year is the appropriate amount of time for an article to exist without substantive edits before volunteers intervene.  Unscintillating (talk) 00:29, 8 April 2014 (UTC)
Unscintillating, that may be your opinion, and it may eventually turn out to be the consensus, but it is not currently what the CSD policy says. I am very surprised that you reverted my simple correction of fact to the page. I am doubly surprised after the fuss you have made at the WP:42 talk page over the accuracy of that page. It is simply wrong to change a correct statement of policy into an incorrect one because you disagree with the policy. SpinningSpark 08:06, 8 April 2014 (UTC)
First of all, your edit was not reverted.  I think I've figured out what you are identifying as a policy, it is an edit on 2014-03-01 to WP:Criteria for speedy deletion, where the edit comment is, "A bunch of minor fixes and using anchors in the section header is undesirable. (uninformative edit conflict warning. I apologize for whatever I'm overwriting.))".  Is this what you are talking about?  I suggest that you encourage discussion.  Unscintillating (talk) 00:08, 10 April 2014 (UTC)
Reverted or changed what's the difference? I made a change that accurately reflects what the policy says. You changed it to something that does not accurately reflect what the policy says. The edit history is not the policy. What it actually says on the policy page is the policy. The CSD page is a policy page. There may be a discussion to be had over that edit but that should happen with respect to the policy page. Trying to maintain this page saying something different is not the answser. If you think the policy is wrong it is really for you to start a discussion on it, not me. SpinningSpark 01:14, 10 April 2014 (UTC)

Spinningspark, the CSD mention of Draft space does not have any consensus behind it, it was introduced as part of "a bunch of minor fixes" and not discussed, so I have reverted it. AFAIK there has never been a consensus on how of if Draft pages should be deleted under time limits, so information and policy pages shouldn't imply that there's one. Diego (talk) 06:16, 10 April 2014 (UTC)

Diego Moya It has been the understanding that CSD:G13 is applicable in any namespace as long as there is a {{AFC submission}} template attached to it. In practical terms this means any draft version (not submitted for review), pending version (submitted for review but hasn't recieved a review yet), or declined version (submitted and recieved a rejection). I did attempt to push a "After X time of being unedited and not covered by other CSD a draft page may be CSD nominated for summary deletion on the grounds of not being improved" but was firmly opposed. I would prefer to see the CSD rule codified to indicate that if the page is under the cloak of AFC then the G13 rule applies. But as to where the 1 year rule came about I would wager it was based on a doubling of the G13 rule's length. AFC and my bot will continue to process AFC submissions that are in the draft namespace as the rules are still applicable. If a consensus emerges to extend the "stale deletions" to pages in the draft namespace that are not under AFC's banner, then we can do that to. I'm keeping my hands clean because there is an end run that I could see what would nullify the entire debate but WP:BEANS would prevent me from suggesting it. Hasteur (talk) 16:17, 10 April 2014 (UTC)
That's all well and good, but the CSD policy as written was being applied to *all* drafts, and there are drafts that have not been created through Articles for Creation (such as, for example, those that were created at Articles for Deletion). Applying the G13 rule to those drafts is obviously outside its scope (and I hope your bot is clever enough to avoid doing that), that's why the above misunderstanding happened. Diego (talk) 16:36, 10 April 2014 (UTC)
@Diego Moya: The only way my bot starts notifying and working the pages is by scanning through Category:AfC submissions by date and it's sub-children to look for submissions that are ripe for notifying that the page is eligible and enrolling the page in a list of "Potentially delete by bot process in 30 days". If the AFC submission banner is not present it takes someone adding the submissions by date category by hand to sneak the page into the category membership. Now if people are CSDing by hand under the G13 rule when there's no AFC banner then the Admin who reviews the deletion should be slapped around with a wet trout for not exercising the review function that they are supposed to. Initially the G13 cleaning was passing through ~500 nominations a day (because of the long backlog) but we're down to ~60ish a day so admins have plenty of time to review the nominations to verify that they are appropriate. Hasteur (talk) 16:58, 10 April 2014 (UTC)

Venue to hold deletion discussions for Drafts

In a nutshell (and straight to the point, and because there is currently not a deletion forum established for pages in the "Draft:" namespace), I propose that Wikipedia:Miscellany for deletion (WP:MFD) be used as the venue to nominate drafts for deletion. Per WP:MFD, pages in the "Wikipedia:" namespace can be nominated there for deletion, which would include pages in the Wikipedia:Articles for creation namespace that the "Draft:" namespace has essentially taken over. Support or oppose? Steel1943 (talk) 06:12, 16 April 2014 (UTC)

  • 57 related examples  See Wikipedia talk:Article Incubator/2013 June mass MfD for transclusions of 57 such discussions.  These were all sent to MfD by one editor who then stopped editing Wikipedia.  I volunteered to work on these articles if the nominator would withdraw the nominations, but by then the editor was gone.  Most of these MfDs were ignored for weeks.  Why these MfDs were not procedurally closed in a timely manner is a question that I've not seen discussed.  After about four weeks, a few administrators jumped on board with the idea to use these abandoned discussions to claim the authority to delete.  I asked one of the admins if there was any background discussion between these closing admins that is not on the record, that led to these deletions, but I did not get an answer.  In the end it was my request at WP:AN/Requests for closure seven weeks into the process that finished getting these closed, and even one article that had been rewritten was deleted.  Many of the deletions were soft deletions, and one admin has said that his are soft deletions even though they are marked as hard deletions.  Unscintillating (talk) 17:47, 19 April 2014 (UTC)
  • Wikipedia:Miscellany for deletion/Wikipedia:Article Incubator/William "Billy" Smith is another example of an MfD discussion.  Again, no one wanted to participate.  But this case is different because the article had already been through a pilot-project discussion called the Greenhouse that attracted attention through community-wide invites.  The Greenhouse was an alternative venue whose discussions took place on the talk page of the article.  One of the basic problems with the Greenhouse process was that when articles are deleted, the talk page is normally also deleted.  The closing admin made an exception here, at Wikipedia talk:Article Incubator/William "Billy" Smith, so it is still available for your review.  Unscintillating (talk) 17:47, 19 April 2014 (UTC)
  • Oppose  The history from WP:AI IMO strongly says not to do this.  The basic problem there was that articles in the AI were already deleted from mainspace.  Where are the guidelines to delete a deleted article?  The result at MfD is anarchy.  Is there a deadline at Wikipedia, is there a deadline at userspace, is there a deadline in draftspace?  If there is no deadline in draftspace, should we have an archive of articles that no one wants to sponsor?  How do we organize the corpus of non-articles so that editors can do research, but Wikipedia mirrors cannot "see" the non-articles?  Unscintillating (talk) 17:47, 19 April 2014 (UTC)
  • Proposal is moot as MFD is exactly the place for deletion discussions for all namespaces that do not have specialized deletion discussions. This includes Draft:. Now, the relevant question is what criteria should be used in such discussions. On one end, the criteria could be "keep anything that isn't speediable unless WP:Ignore all rules applies." On the other extreme could be "evaluate all drafts as if they were articles." Clearly neither extreme is desirable. In any case, this discussion should be closed as "moot" and the discussion of "what criteria to use in a deletion discussion" should be in a new discussion. davidwr/(talk)/(contribs) 05:29, 20 April 2014 (UTC)

Venue to hold promotion discussions for Drafts

There is another venue that is missing, and that is one to promote the article to mainspace.  At the AI, editors marked an article "status = eval", and this added the article to a Category for the same.  Consider a current case, Wikipedia:Articles for deletion/Acayucan bus crash, where I've recommended a speedy incubate for two weeks.  Suppose an admin made a Bold speedy incubate, and salted the mainspace article for two weeks.  (1) What would be the process to return the article to mainspace before the two weeks had run?  (2) What would be the process to return the article to mainspace after the two weeks had run?  Unscintillating (talk) 17:47, 19 April 2014 (UTC)

  • Here is another example Draft:Reed Alexander.  I think this is ready to go back to mainspace, but I don't feel bold enough to move it myself.  I have no process to use.  Would a reverse prod work?  Unscintillating (talk) 17:47, 19 April 2014 (UTC)
  • To borrow from WP:AFC, I would recommend using the draft article's talk page (since the old-school AFC submissions does have a separate "talk" page for technical reasons, they use a special section at the top of the draft article). When the page is promoted, the draft-stage discussions should be removed, archived, or handled in some other organized, consistent manner. Due to sharing a page with the draft article, the AFC process included removing the discussions when the article was moved into the main encyclopedia. They remain visible in the edit history. davidwr/(talk)/(contribs) 05:34, 20 April 2014 (UTC)

Request for Comment: Template:Draftspace graduate and Category:Draftspace graduates

Template:Draftspace graduate appears as: {{Draftspace graduate}} Template:Draftspace graduate is a version of [1] edited by @ThaddeusB:

The template puts articles in Category:Draftspace graduates. Unscintillating (talk) 22:29, 20 April 2014 (UTC)

Would we put this on article talk pages?
If we want, we could potentially build in a list of all published drafts in the future. Steven Walling (WMF) • talk 19:12, 25 April 2014 (UTC)
It's also a beautiful way to make novice editors aware of the existence of draftspace and AfC. Diego (talk) 20:05, 7 May 2014 (UTC)

Should Articles for Creation move to Drafts?

Several discussions and an RFC about this, at Wikipedia talk:WikiProject Articles for creation. Steven Walling (WMF) • talk 16:55, 7 May 2014 (UTC)

For the record, the above statement and section header is not accurate. There are 2 questions to whit. 1. Change the destination of the AFC output from the Article wizard to create the new pages with the prefix of "Draft:" instead of "Wikipedia talk:Articles for creation/" 2. Should a bot be allowed to move all "pending" AFC submissions to the Draft namespace?. The first question is an outgrowth of the second due to people being concerned about the original AFC continue to accumulate pages. Hasteur (talk) 18:25, 9 May 2014 (UTC)
Articles for Creation has already decided to relocate to the Draft namespace back in November, but making the actual movement to the goal is what these proposals are for. Hasteur (talk) 18:26, 9 May 2014 (UTC)

Dispute about which is the stable version of disputed text.

  • 2013-12-06,‎ Project page created
  • 2013-12-08, [2], first version of stable version of disputed text, 2 months passed before it was changed
  • 2014-02-08, [3], similar text, 2 months and 20 days passed before it was changed
  • 2014-04-28, [4], first version of disputed text
  • 2014-05-17, [5], with edit comment, "Reverting edit based on false wording used by previous editor - not "stable text", but "editor's POV"
This edit history documents that the "stable text" was just that, and that the words "POV" and "false wording" are part of WP:What Wikipedia is not.  Unscintillating (talk) 20:50, 17 May 2014 (UTC)

Steel1943 asked me at 2014-05-17T23:45:04 to "please attempt to resolve on talk page".

Above I have posted diffs to show that the issue of deletion discussions has existed from the start of the Project Page.  A new round of talk page discussion began on 2014-04-16, and the following is a history sequence.  What you will see in the diffs below is that Steel1943 has posted his bold edit of 2014-04-28 seven times.  The last three edits blocked restoration of the consensus version of the text, which is the current dispute.

Note that this discussion is still open, and is referenced in the diffs below.
  • 2014-04-28T18:17:34 Steel1943 (talk | contribs) . . (5,654 bytes) (+16) . . (Deleting a draft: Boldly updated section to include a current XFD forum to be able to nominate drafts for deletion: Wikipedia:Miscellany for deletion)
  • 2014-05-10T19:45:58 Unscintillating (talk | contribs) . . (5,775 bytes) (+80) . . (Deleting a draft: as discussed on the talk page, MfD has a long history as a failed process for incubated articles. Trying a bold fix.)
  • 2014-05-11T00:35:54 Steel1943 (talk | contribs) . . (5,695 bytes) (-80) . . (Deleting a draft: removed bold edit regarding having to form deletion consensus on the draft's talk page - deters from the purpose of WP:MFD by setting a requirement for deletion consensus to be formed in two different places)
  • 2014-05-11T03:36:01 Unscintillating (talk | contribs) . . (5,840 bytes) (+145). . (MfD hasn't worked, see talk page discussion)
  • 2014-05-13T01:15:01 Steel1943 (talk | contribs) . . (5,695 bytes) (-145) . . (Undid revision 608002915 by Unscintillating (talk) Again, forces editors to use multiple forums for deletion, talk pages get deleted per WP:CSD#G8 after host page deleted WP:A)
  • 2014-05-17T12:50:26 Unscintillating (talk | contribs) . . (5,908 bytes) (+148) . . (Undid revision 608308237 by Steel1943 (talk) ok, so change the word deletion, but most of all please stop restoring a known bad idea)
  • 2014-05-17T12:55:56 Steel1943 (talk | contribs) . . (5,760 bytes) (-148) . . (Undid revision 608955114 by Unscintillating (talk) Again, reverting bold changes where no consensus has been formed for this specifically for the "Draft" namespace)
Note that relative to previous objections, there are no remaining technical objections.  This meant that the bold edit summary discussion had not resulted in consensus.
  • 2014-05-17T13:43:00 Unscintillating (talk | contribs) . . (5,732 bytes) (-28) . . (Undid revision 608955576 by Steel1943 Restoring stable text from 2014-04-21T08:26:24)
This is my first actual revert of the edit of 2014-04-28, as previous edits were text that retained the addition of MfD.  It seems possible that Steel1943 has been unaware that this is not something that I wrote.
  • 2014-05-17T13:45:01 Steel1943 (talk | contribs) . . (5,760 bytes) (+28) . . (Undid revision 608959986 by Unscintillating (talk) Reverting edit based on false wording used by previous editor - not "stable text", but "editor's POV")
IMO, this was problematic.  You can see that I tried to raise the issue as posted above at 2014-05-17T20:50.
  • 2014-05-17T19:57:40 Unscintillating (talk | contribs) . . (5,732 bytes) (-28) . . (Undid revision 608960185 by Steel1943 (talk) restoring stable version of disputed text)
  • 2014-05-17T20:56:42 Steel1943 (talk | contribs) . . (5,760 bytes) (+28) . . (Undid revision 609001195 by Unscintillating (talk) Again, reverting controversial bold edit - already attempt WP:BRD proc. on talkpage, prev editor has yet to participate - RFC)
The other editor seems unaware that this is not a bold edit and is not controversial, IMO misconstrues the relationship of this revert and the RfC, and perhaps has failed to notice the talk page discussion posted at 20:50.
  • 2014-05-17T22:24:18 Unscintillating (talk | contribs) . . (5,732 bytes) (-28) . . (Undid revision 609009474 by Steel1943 as carefully documented on the talk page prior to the last revert, this is the stable version of the text)
Attempting to leave no possible doubt that this is a careful edit, a stable version of text, and that such is documented on the talk page.
  • 2014-05-17T23:45:04 Steel1943 (talk | contribs) . . (5,760 bytes) (+28) . . (Undid revision 609018231 by Unscintillating (talk) No, this is a "no-consensus-based" version of what you believe to be correct - please attempt to resolve on talk page)
Note that the request of "please attempt to resolve on talk page", was followed ten minutes later by a 3RR report, diff.

The conclusion here is that Steel1943 needs to explain why his/her bold edit should be retained, instead of the consensus version of text that existed for over 2.5 months before the bold edit.  Unscintillating (talk) 19:44, 18 May 2014 (UTC)

@Unscintillating: Your edit was the bold edit, and you know it. It doesn't matter to me anymore though: I dropped the stick after the outcome of the 3RR report. I recommend you do the same, drop the WP:POINTy attitude, and just await the result of the RFC. Have a good day. Steel1943 (talk) 23:36, 18 May 2014 (UTC)
@Steel1943: So now you are telling me what I know?  How is this going to resolve this dispute?  I don't know what you are talking about in your references to the stick and the point.  Please clarify that you understand that I did not write "In the future, a consensus may develop on how to delete drafts."  Unscintillating (talk) 00:22, 19 May 2014 (UTC)

AFC process in Draft space (RFC)

There is a RFC underway at WT:AFC regarding where various AFC templates should be (Draft page or Draft talk page) with respect to a draft that is submitted for AFC review. As the outcome of this RFC will affect AFC submissions in Draft space, please feel free to read and comment on the proposal on the talk page. Hasteur (talk) 14:18, 19 May 2014 (UTC)

Process for deleting drafts

It's been a while since this discussion had some participation, so I'm closing it as (roughly) no consensus for major change. Some thoughts for those who want to move forward: As a regular on WP:REFUND I see a lot of requests to restore deleted drafts (usually deleted due to inactivity) and I'm slowly coming to the conclusion that drafts need some sort of mechanism to be removed semi-permanently. I suggest opening a discussion on WT:CSD about changing the wording of G13 to include drafts which are unlikely to be accepted or have been declined multiple times. I know that we worry about deleting drafts without process but as a practical matter MfD and AfD are not good places for draft deletion discussions and most drafts which would be speedily deleted are basically junk anyway. Just a suggestion, but it may be worth exploring. Protonk (talk) 15:41, 10 September 2014 (UTC)

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

Due to some disputes on this page, I think it's about time to start a discussion about a consensus-supported policy for the deletion of drafts in the "Draft:" namespace. I have thought of a few options that could be possible for drafts, and I will present these three options below. If anyone has any other ideas for this discussion, fell free to present them. Steel1943 (talk) 13:21, 17 May 2014 (UTC)

Option 1: Use MfD process for draft deletion

  1. The MfD process would honestly be the best option for deleting drafts. The process is not flawed, the votes that editors post would be retained on a subpage of MfD to allow editors to see the discussion that led to the draft's deletion, and it allows ample time for any involved editors to provide input. Steel1943 (talk) 13:16, 17 May 2014 (UTC)

Discussion for Option 1

  • Well, this is the obvious choice. I don't see why we'd treat draftspace drafts any differently from userspace drafts, with the caveat that G13 applies to drafts submitted to AfC. Gigs (talk) 18:29, 30 May 2014 (UTC)
For the same reason we don't treat user space essays in the same way than project space essays, maybe? User space drafts belong to one user, but Draft space belongs to the community. User drafts are owned in a way that those in Draft space are not; what makes sense for the first (waiting for the draft creator to stop working, requesting permission to make changes...) is not sensible for a common space. Diego (talk) 20:34, 30 May 2014 (UTC)
But user space essays and project space essays are both subject to deletion at MfD. The criteria are somewhat different, in that much greater flexibility is allowed for user space essays, but we use the same process. DGG ( talk ) 18:45, 2 June 2014 (UTC)

Option 2: Use MfD process only after consensus formed on draft's talk page

Discussion for Option 2

  • A major flaw that I see with this option is that after the draft is deleted, the talk page of the draft would be eligible for deletion via speedy deletion criterion G8, preventing non-administrators from seeing the initial discussion that led to the second discussion of the deletion of the draft. Steel1943 (talk) 13:18, 17 May 2014 (UTC)
  • Where have we done a "Pre-trial" in deletion discussions before? If we secure consensus that it should be deleted at the Draft Talk, then delete it and short circuit the burecracy of going through a MFD. But that in itself causes a problem when the talk page gets deleted because it depends on a deleted mainpage. Hasteur (talk) 00:40, 19 May 2014 (UTC)
  • Why have two discussions about the same subject? As noted above, it's best not to have too much important discussion on the talk page of a draft that isn't likely on the path to becoming an article. —Anne Delong (talk) 21:48, 29 May 2014 (UTC)

Option 3: Create a new "Drafts for deletion" process

Discussion for Option 3

  • Do we really need yet another Deletion process? Until we can show that MFD is being overrun by Draft deletions (which wouldn't already be covered by the CSD:G series) I don't see a need for DFD. Hasteur (talk) 01:34, 18 May 2014 (UTC)
  • Agree with Hasteur. In addition, I don't think any XfD process is going to be able to have sufficient participation to handle any signficant number of drafts effectively. MfD and increasinly AfD are already understaffed. I believe we need a few slightly sharper tools to deal with the moderate to serious issues of copyright and promotionality, and I don't think we need anything else to address non-problems (such as non-notable drafts) more quickly than G13. --j⚛e deckertalk 15:29, 27 May 2014 (UTC)
  • Oppose another XfD board is excessive, and may not attract informed community members to review the nominations. — xaosflux Talk 23:02, 29 May 2014 (UTC)
  • OpposeThe one thing we should not do with draft space is multiply processes; it's meant as a simplification.. MfD has worked perfectly well for userspace drafts in the past, DGG ( talk ) 15:07, 30 May 2014 (UTC)
  • Oppose Another XfD process will only complicate things. We should try to find a way to incorporate management of Draft deletion submissions within the framework we already have. Please see my comment in the General Discussion below.  Philg88 ♦talk 20:46, 30 May 2014 (UTC)

Option 4: Use AFD

Discussion for Option 4

  • As the content of Draft: space pages are potential Articles, the reviewers that frequent AFD will be more versed in article space standards. — xaosflux Talk 23:00, 29 May 2014 (UTC)
  • Oppose There's a huge difference between the standards used for Articlespace and other namespaces. To say that all Draft namespace needs to conform to the same rules as Articlespace should be only implemented after we've completely evacuated the Draft Namespace because the namespace's garuntees are null and void. Hasteur (talk) 00:27, 30 May 2014 (UTC)
  • Support Please see my comments in the General Discussion below.  Philg88 ♦talk 20:48, 30 May 2014 (UTC)

General discussion for deletion options

Aren't we putting the cart before the horse? The first thing that should be discussed is why people in the community think that some drafts should be deleted, in case some of them should. Only after we assess common practice and their arguments, a guideline can be written to reflect that common understanding. How can we decide between those three seemingly interchangeable options when there's no criteria for which any one should be preferred over the others? Diego (talk) 21:33, 18 May 2014 (UTC)

I think there are one or two situations that are common and don't quite ... work right for drafts vs. some G# CSD criteria. For the most part, I feel we should be more hesitant to delete drafts than equivalent articles, I see no need to A7 an article draft, I'm more than happy to see it go stale and wait another six months for G13 to eventually address it. The exception? I'd treat attacks against people, partial copyvios, and promotional articles less narrowly than the equivalent G-critieria would strictly allow when applying them to an inactive Draft. With an understanding that G10/11/12 can be read less narrowly on Drafts that aren't being actively worked on, and G13 "as is" for nearly any other problem, I don't believe we'd get any value from an MfD/DfD process. And not having to have another discussion process would be awesome. --j⚛e deckertalk 05:37, 27 May 2014 (UTC)
I despise the idea of "inactive Draft"; it doesn't make more sense than "inactive article". The concept could have made sense for drafts in user space, which were supposed to be worked on by a single editor, but it does not for the new Draft space where the content belongs to the community. A Draft there is serving the same purpose as a stub article: working as a placeholder of verifiable content that can be used to improve upon it with enough time.
Just like there's no benefit in deleting drafts stubs merely because they haven't been improved in some time, there's no reason to delete stale drafts unless their content is otherwise problematic. Every time you delete valid information, the wiki process has to start again from the beginning, which hinders any possibility of slow but steady growth. Diego (talk) 09:55, 27 May 2014 (UTC)
What your analysis ignores is that when we had drafts last forever, and looked at what was there, we discovered an enormous amount of problematic content--severely promotional and/or copyvio. A surprisingly low number of BLP concerns, but *lots* and *lots* of G11/G12s, and even more things that just misses the narrow interpretation of those criteria, things which, until G13, could never be deleted short of an MfD, and that pretty much never happened.
We had, and I do not believe I exaggerate, thousands of copyvios sitting for years that were left unaddressed because they didn't meet the strict CSD criteria.
Similarly, it is evident that we have SEO experts effectively gaming our system by producing drafts and not submitting them, or leaving them declined, without dealing with promotionally problems, just pick any sample of 50 or so G13 refunds and see how many of them are ever touched, and you will see what I mean. Go and look at the actual content being affected here. It will change your view.
G13 exists as settled consensus, and if you want to start an RfC to revoke it, please start one, but please don't derail.
Instead, if we could turn back to the change I proposed, which was allowing G11 and G12 to be read somewhat less narrowly for drafts, with some sort of limit so that we don't bite the heck out of editors who are actively working to fix the issues. It is possible, in fact, that with better control over promotionally and copyright in the draft space, I would feel less need for an expiration date on the rest. And, as a bonus, we'd need no new big process, one which would surely end up understaffed, as MfD and increasingly AfD already are. --j⚛e deckertalk 15:16, 27 May 2014 (UTC)
Excuse me, but that doesn't make much sense. For a start, drafts that have been created from AfD have already been reviewed to not contain Copyvio (otherwise they would have been deleted, not changed into drafts); and drafts created through AFC *can* be deleted by G13 if they become inactive (I don't think of those rejections as drafts but as "failed AFC submissions", as those have not been adopted by the community in the same way as drats have been). I'm not arguing here to change that, but I'm speaking about the all of other drafts in Draft space that were not created through AFC and for which no policy have ever existed. And as for SEO optimization, the whole Draft space is placed under noindex, so how is that a problem at all? Diego (talk) 16:14, 27 May 2014 (UTC)
P.S. I think the morale is that we should clearly differentiate in Draft space between "rejected AFCs" and "incubated articles"; as they are created through different processes, the same policies need not be valid for both. For the first class, it may make sense to review them after a while, at which point the reviewer can decide whether to mark them for speedy deletion with G13, or definitely adopt them as incubated; at which point it wouldn't make sense to delete them on a time basis, as they have been vetted by the editor reviewing them. Diego (talk) 16:39, 27 May 2014 (UTC)
Nah, you're missing some reality here, but I can undestand the confusion.
First, most declined drafts are, in practice, rarely checked for copyvios. As a practical matter, if reviewers find a reason to decline, it's very common for them not to look for others. Most fail critieria are easier to spot than copyvios.
Second, many detected copyvios are not eligible for CSD. That is in fact, part of my point here. If there's any non-problematic material, G12 in theory should not apply. In practice, we already play a little fast and loose there, but still, many copyvios don't get deleted or even blanked even when detected. This is unfortunate if it's left to fester.
I'd hoped noindex would help too, but it hasn't. Not sure why, but I suspect the answer is that the mirrors ignore it, and the mirrors have SEO value. [6]. (More in a second, hold on.) --j⚛e deckertalk 16:57, 27 May 2014 (UTC)
I'm entirely okay with giving explicity incubated articles more room, and this already happens to some extent. My concern is rejected and never-submitted drafts. --j⚛e deckertalk 17:01, 27 May 2014 (UTC)
If people is not going to review the content of drafts, how will G11 and G12 help? It would take the same amount of work to check whether those apply to the draft or not. Diego (talk) 17:30, 27 May 2014 (UTC)
"many detected copyvios are not eligible for CSD". My suggestion is to widen the way these can be used on rejected, non-incubated Drafts. If you'd like, I can explain in more detail. --j⚛e deckertalk 17:37, 27 May 2014 (UTC)
Please, do. I'm trying to understand what kind of problems are commonly found that prompt people to ask for their removal, to find ways in which they could be corrected without deleting the whole page. Do you also have examples G13 refunds that you mentioned above? Diego (talk) 17:57, 27 May 2014 (UTC)
Sure, in this comment I'll try and explain what I'm thinking with G11/G12. I'll answer separately w.r.t. G13 refunds. It's really common for us to get long (20+ paragraph) entries on corporations, products, or creatives at AfC, and a substantial fraction of those will turn out to include lots of promotional text, and/or sections of the article which are cut and pasted from the subject's web presence or press releases, often from different specific sources for different parts of the article. Many such articles are not strictly deletable under either G criterion. There *might* be some salvageable material within the article. So I'm a reviewer, I see this ... am I going to check every single paragraph to see if it's really a copyvio? Nah. With 2300 people waiting for a review, I'm not, and neither are other reviewers, and a full WP:CCI investigation of every paragraph, plus the reporting time, plus the time for someone to revdel what a careful investigation of every single paragraph determines to contain an infringement is more work than the community is willing to do. Anyway, maybe I'm wrong. But I do feel frustrated and flooded by promotional crap at AfC, and I think that not only AfC, but the entire encyclopedia and its community are suffering from it. --j⚛e deckertalk 18:33, 27 May 2014 (UTC)
At it's core, the "powers that be" carry on as though we should all be happy to toil away at this for free. My experience, and I think I can safely say that of many others, is that volunteers who have other things to do with their lives (to include paying work) tend to get burned out and used up pretty quickly. The decline in interest in participating in Wikipedia the past 3-4 years parallels the shift in content towards mirroring the short-term memory and COI/promotional tone found just about everywhere else on the web. When you realize the magnitude of the real work still ahead, it becomes easy to justify shortcuts and the easy way out instead. The short version is that Wikipedia has allowed itself to become too much of a dumping ground for whatever happens to be trending today, which is a bullshit approach towards what is supposed to be an encyclopedia. I'm more interested in expanding coverage of important historical topics, but I see two pervasive "three monkeys" beliefs which are antithetical to "collaboration". The first is "Nobody cares, but if YOU feel so strongly, knock yourself out". The second is "Any sources I can't Google are bullshit" (or, alternately, "You won't be able to get an FA with offline sources"). I was enthusiastic when I saw the creation of the draft namespace, as I thought it may possibly encourage the development of articles on notable topics which fall on the wrong side of the "popularity contest" mentality so pervasive in article space, in a way which AFC has failed to do so. Maybe I'm wrong there. RadioKAOS / Talk to me, Billy / Transmissions 03:18, 20 July 2014 (UTC)
Regarding my cynicism of G13 refunds, I took an 8-article sample of the G13 refund requests at WP:REFUND in June of last year, the list I made is User:Joe_Decker/RefundsToWatch. You can see their deletion histories, none of them is still in mainspace, though. --j⚛e deckertalk 18:44, 27 May 2014 (UTC)
By the way, I would be happy to temporarily undelete/userfy/email those 8 articles to you, or any pre-blanking draft, if it would help. I haven't looked at them in a long time, and it is a very small sample, but I suspect it's moderately representative. --j⚛e deckertalk 18:47, 27 May 2014 (UTC)

Thanks for elaborating. I would need to see the removed articles to be sure, but for what you describe, there's reason why those drafts couldn't simply be systematically blanked or stubified to a mere single-sentence definition (neither option requiring any investigation), instead of asking an administrator to hard-delete it. I can't see any significant drawbacks to blanking over deleting, and there are lots of advantages in keeping the content hidden under history: first in terms of improved accountability, as any editor could review the removed content and see if it was properly deleted; but also because an editor interested in the topic could use the history as a starting point for research, studying the removed content as a starting point to guide searches and bootstrapping the process, even if none of the content would ultimately be usable for an article. Diego (talk) 21:15, 27 May 2014 (UTC)

Consistent blanking would address most of my concerns. There are a couple ways that could possibly be gamed, but blanking is likely good enough. --j⚛e deckertalk 21:23, 27 May 2014 (UTC)
Do you think we could write a summary of these conclusions and add them to the WP:Drafts information page as recommendations? I can do that tomorrow if you think it's a good idea. Diego (talk) 21:28, 27 May 2014 (UTC)
Sure, although I won't be able to contribute much today, perhaps tomorrow though. --j⚛e deckertalk 21:58, 27 May 2014 (UTC)
  • The role of draft space as I see it is to have a "safe" space where content is not deleted for the same reasons deletions occur in mainspace. Essentially draft writers are exchanging the visibility of mainspace for the security of Draft. Lack of evidenced notability is a reason to decline a draft, not to delete it as we encourage users to improve drafts at their own pace. While there are many hopeless cases in Draft (dealing these hopeless cases are is actually quite an easy part of AfC reviewers' jobs), but unless they are actively harmful to the encylopedia they can remain and eventually disappear via db-g13. These criteria better fit within MfD's scope rather than AfD. --LukeSurl t c 23:33, 29 May 2014 (UTC)
  • Putting all main space and draft article related deletion discussions in the same place seems eminently sensible. AfD has the advantage of the deletion sorting project, which means multiple interested editors should in theory be informed of the proposed deletion and can "save" the target article, if that is indeed possible. MfD does not have that capability. However, there should be a mechanism to safeguard the guarantees offered by the draft space in terms of policy leniency. This could take the form that a draft space article may only be tagged for AfD if it meets certain time based(?) criteria. Off the top of my head these could be where there have been notability, verifiability or other apposite hatnote tags on the draft for a certain period of time without further input from the creator or other editors. AfC templated articles in the draft space would be exempt from AfD submission and stale submissions will as before be picked up under CSD db-13.  Philg88 ♦talk 08:41, 30 May 2014 (UTC)
    Could we make that "source based" instead of "time based"? I oppose time limits (except in hte case for minimum times between repeated discussions), as they're directly against the WP:PRESERVE and WP:IMPERFECT policies for long-term improvement through the wiki process. A rule to decide that drafts were unredeemable based on their (poor) level and quality of sources, instead of time without improvement, would still allow for cleanup without facing the risk of losing potentially viable content. Diego (talk) 09:57, 30 May 2014 (UTC)
    P.S. Oh, and I think I agree that empowering and training DELSORT editors on the criteria to handle both deletions and movements from Article to Draft space is a good idea. Diego (talk) 09:59, 30 May 2014 (UTC)
    • Some sort of generally lenient time limit is what allows these drafts to exist in their imperfect state. Your suggestion to apply source-based criteria or some form of notability to drafts would result in much quicker deletion, in general. I could probably go nominate half the AfC backlog for deletion right now if we went with some kind of source-based criteria. Gigs (talk) 18:38, 30 May 2014 (UTC)
      • Source based criteria could work, although the problem of shooting a non-qualifying draft article on sight needs to be addressed – the creator should be given the chance to substitute alternative sources, which is why I suggested time (< db-g13) + an appropriate article tag.  Philg88 ♦talk 20:32, 30 May 2014 (UTC)
        • Obviously the criteria for references in draft space should be that of WP:PRESERVE, not that of WP:GNG. A minimum grace period for allowing the draft to develop should be held - but yes, deleting the AfC backlog beyond that minimum time makes sense for those with no sources at all; but deleting drafts with verifiable, non-policy-breaking content should not happen no matter how much time passes - just like with content in talk pages, which get archived, not deleted. Diego (talk) 20:39, 30 May 2014 (UTC)
          • There's a reason we don't do that, it would allow the alternate space to completely nullify notability. It is a more pressing issue with userspace drafts, since those are in Google, and can get enough search rank to substitute for a real article. Even through drafts are not indexed in search engines, it could still be an issue if we let drafts unsuitable for mainspace live there forever. A lot of people who want to abuse Wikipedia for promotion or whatever other reason would probably settle for a Draft space article, if it were guaranteed to be there forever, so they could link to it from their site and misrepresent it as a real article. Gigs (talk) 21:27, 2 June 2014 (UTC)
            • There's no guarantee that those drafts will be there forever - they can be blanked, trimmed or stubbed at any time. The idea that anyone would want to see their content promoted as a "Wikipedia draft" seems wild speculation, and not very likely IMO. Diego (talk) 22:33, 2 June 2014 (UTC)
              • It happens all the time. People create pages on their garage band or their non-notable resume, knowing up front it'll never make main space, or eventually realizing it, so they settle for us hosting it as a draft or a user page. User pages are even in search engines and can get quite high search rank with a few well-placed incoming links. In Draft: space it won't be in search engines, but the word "Draft" in title won't stop them from pretending it's a real article and presenting it that way to the world. An unsavvy reader won't realize it's not a real article. I've seen userspace drafts attract vandalism, good faith improvements from multiple random IPs (sometimes even when it's a duplicate of an existing mainspace article), etc. This isn't a theory I made up, it happens all the time every day, and you don't even have to search very hard to find some examples of non-mainspace articles being presented as, used as, or confused for mainspace articles. I recently nominated for deletion an ancient copy of Barack Obama I found in user space that was getting 80 hits per hour. Gigs (talk) 16:48, 18 June 2014 (UTC)
                • Yep. It's wide open to abuse. No doubt some suitably inclined people point to their product/service "article" and quoth "See, it must be good! It's on Wikipedia ..."  Philg88 ♦talk 17:04, 18 June 2014 (UTC)
(edit conflict) OK - but in that case, there is a reason to delete the draft - WP:NOTWEBHOST, which is codified under speedy deletion criterion WP:U5. My concern is that this shouldn't apply to the kind of valid content that should be WP:PRESERVEd per the edit policy; we shouldn't treat both cases in the same way. Note that U5 itself distinguishes "plausible drafts" as outside its scope. Diego (talk) 17:08, 18 June 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Drafts/Archive_3&oldid=1144270900"