Draft namespace

The purpose of the Draft namespace will be to support Wikipedia article creation without requiring users to publish in the main content namespace immediately (it will have no impact on whether user namespace subpages may be used for the same purpose). See also T59315. English Wikipedia requested this namespace (T59569), so was the first Wikimedia project to have the new namespace.

Minimum requirements

 * User experience
 * 1) Page titles are pre-pended with "Draft:" or the localized equivalent in your language.
 * 2) There is an accompanying "Draft talk:" page for each Draft page, to facilitate discussion.
 * 3) Any user, anonymous or registered, will be able to create drafts.
 * 4) Any user, anonymous or registered, will be able to search for drafts. However, drafts will not be shown in the default search results, so users will have to choose to include them in their search filters.
 * 5) For now, only autoconfirmed users will be able to publish drafts, by moving them in to the main content namespace. This abides by the default requirement that users moving pages be autoconfirmed.
 * 6) VisualEditor will be enabled for those users who have opted-in


 * Technical requirements
 * 1) The namespace will, for now, be defined in wmf-config. Even if special publication behavior goes in core later, we will probably have to provide a way to specify which namespaces it affects, so using a site admin namespace rather than a core namespace is probably okay (we could still add an optional core namespace, later).
 * 2) Required behavior (e.g. hooks) will be implemented in an extension or wmf-config initially. If the latter, could be moved to an extension easily later.
 * 3) The namespace will have a robots policy that includes the following: it will be NOINDEX, to hide it from search engines, and NOFOLLOW, since regular pages are too, and scrutiny for spam may not be as high for drafts. (This also means disabling the associated magic words that can enable indexing etc., using wgExemptFromUserRobotsControl)
 * 4) Should not be a content namespace.  Such pages show up as content in Special:Statistics.  To count there, it should be moved to the main namespace first.

After the above is implemented, it will be tested on at least Beta Labs to confirm that behavior, before deploying to the first production wiki (probably English Wikipedia).

Future enhancements and experimental ideas



 * Open questions


 * 1) How should we suggest to users that they can create a draft, or edit one that already exists?
 * 2) Should we disallow or discourage creation of drafts if an article already exists? What about for redirects?
 * 3) How do people want to be able to search for Drafts? Should we add it as an option on Search? (The thread above is probably the relevant place to talk about this one.)
 * 4) Should we create a feed of drafts, e.g. Special:Drafts?
 * 5) Could we reuse the framework of Page Curation's review tools to create a draft review tool?
 * 6) How should categories work on drafts? Do we want them to show up in article categories? Should we remove draft categories from the category page listings, so that we can use article categories on drafts without them showing up?
 * 7) How can we help new editors understand what they need to do before a draft is ready to publish?
 * 8) Should we encourage editors (particularly new page patrollers) to move some articles back to draft status rather than nominate them for deletion? If so, how?
 * 9) Should we use content from Wikidata to suggest first contents for a draft? What is the best way to implement this?

Notifications
During the draft creation process there are several events that users may be interested in. We may consider the following notifications:
 * User participation:
 * Contributing to the draft: "SomeUser edited the draft X". Frequency can be limited to one notification between draft visit.
 * Participating in conversations: Starting ( "SomeUser started a conversation on the draft 'X' ") or replying to conversations where the current user participated (SomeUser replied to a conversation on the draft "X"). Flow may provide support for those out-of-the-box.
 * Completing some tasks: "SomeUser marked 'Add references' as resolved for draft 'X'". We may want to combine this with "user edited X" to avoid duplication since a correlation may be frequent.
 * Publish workflow:
 * Publishing the draft: "SomeUser published the article 'X' based on a draft you started."
 * Discarding the draft: "SomeUser discarded the draft 'X' you started."
 * Unpublishing the article: "SomeUser unpublished the article 'X'. You can keep improving the draft until it is ready for publishing or ask other editors to help you."
 * Inactivity:
 * Draft without recent activity (e.g., a draft created more than 4 months ago, has no edits in the last month): "A draft 'X' has been inactive for a long time. You can contribute to make it ready to be published or ask more editors for help". We can limit this notification to the draft creator. If the draft has pending tasks, the message can indicate so to make the user aware of what to improve.
 * User without recent activity (e.g., a user that participated in a draft has not contributed to it in 4 months): "You contributed to this draft more than four months ago. Anything new to add to the draft 'X' before it is ready for publishing?" We can limit this to the editors of drafts they did not create. We may consider limiting the reception of these notifications to a maximum of one per week to avoid receiving too many reminders of your pending drafts.
 * Invitation to join drafts:
 * Welcome editors that edited a similar articles/drafts: "A new draft has been started for 'X' that may be about your topics of interest. Could you help to make it ready for publishing?" Editors interested on similar topics can be obtained in different ways:
 * If the draft X appears in article Y as a red link, some editors of Y can be welcomed to review X.
 * Editors of articles the draft is including links to.
 * Direct invitation: "SomeUser invited you to help edit the draft 'X'".

In order to avoid overwhelming users with too many notifications we may consider:
 * Use different notification granularity depending on the user involvement with the draft. This can be based in factors such as draft creator (the user that started the draft can receive more detailed notifications than other editors), watched status for the draft, contribution amount or frequency from the user to the draft.
 * Limiting notification frequency for some types of notifications.
 * Bundling notifications of the same or similar events.

In addition, since notifications are only delivered to logged-in users, we may want to ask anonymous users that create drafts to log-in or create an account to track the progress of their draft.