User:Joe Roe/Requests for publication

Sandboxing some ideas for (radical) changes to AfC.

Why do we need an AfC-like process?

The core purpose of AfC is to provide a way of creating new articles for editors who can't do so directly, because of technical restrictions (anonymous editors, unconfirmed editors) or community consensus (paid editors), or for editors that do not feel confident to create without a review process.

Over time, it has taken elements of a peer review process, where reviewers work with new editors to bring submissions up to a certain (undefined) standard before they are accepted. This is certainly valuable, but doesn't necessarily have anything to do with the basic task of moving articles for those who can't.

The focus of this proposal is how to achieve AfC's original, core purpose more effectively. It is suggested that its peer review element is better pursued separately, either as a new and independent project, or through existing processes such as WP:TEA, WP:ADOPT, WP:PR, WikiProjects, etc.

An alternative: requests for publication (RfP)

Proposal for an AfC replacement process.

Principles

• WP:BOLD: "The Wiki Way is to publish instantly, but make it easy to undo." Almost all of our normal editing processes are built on the principle of making changes and seeing how others react, not seeking permission beforehand. Creating articles should not be an exception.
• WP:CONSENSUS: In all other areas of the project, questions of whether or not to include material are decided by the community of editors according to the principle of consensus. Situations where single editors determine the fate of a draft should be avoided. New editors should be encouraged to participate in our decision-making process as equals.
• WP:PRESERVE: Anything that meets our core content policies and could become an encyclopaedia article belongs in Wikipedia, regardless of whether it current is an acceptable article. Moreover, viable material should be preserved in article space, because draftspace is (deliberately) obscured from public access and is regarded as temporary.

Process

1. Editors who are technically unable to create articles directly in mainspace are directed to draftspace by the Article Wizard.
2. At any time, editors can request that their draft is "published" (moved to mainspace) using a template similar (but more concise than) the current AfC template
   1. If the creator of the article is autoconfirmed, the template will display a message telling them that they may publish it themselves, and displays a button to move it to mainspace.

      → Reviewed by NPP^*

3. Another editor reviews drafts submitted for publication, and:
   1. If it meets the minimum standards for inclusion, moves to mainspace

      → Reviewed by NPP^*

   2. If it doesn't meet the minimum standards for inclusion, but the problems are surmountable, leaves a comment on the draft's talk page

      ← Draft remains in the review queue, return to 3.

   3. If it doesn't meet the minimum standards for inclusion, and the problems are insurmountable:
      1. Tag as CSD if eligible (using a special newbie-friendly talk page notice)

         → An admin reviews and deletes

         ← An admin reviews and declines, return to 3.3

      2. Send to MfD or DfD (Drafts for Discussion)

         → Community decides whether to publish or delete

4. Drafts that remain in the RfP queue for a long time are automatically sent to MfD/DfD

   → Community decides whether to publish or delete

^* NPPatrollers would be encouraged to move or return marginal new articles to draft instead of immediately deleting. However, this should only happen once. If the article creator, or anyone else, disputes the draftification, it should be taken to AfD or DfD as appropriate.

Comparison to AfC

RfP differs from AfC in the following key aspects:

• No declines: In theory, a "decline" at AfC is supposed to communicate "I don't want to move this to mainspace at this time." In practice, it gives the impression that the reviewer is in charge of deciding which articles are accepted. It simultaneously presents creators of viable drafts with extra obstacles that established editors do not have to face, and puts drafts on unsuitable subjects into lengthy, frustrating and futile cycles of submit-and-decline. By removing the ability to decline, RfP presents a more accurate view of the structure (or lack thereof) in Wikipedia's community to new editors, and encourages the community to reach a definitive decision about drafts instead of leaving them in limbo.
• No privileged position for reviewers. The role of a "reviewer" in RfP is that of a functionary who publishes articles on request, much like administrators perform tasks according to the community's consensus. Creators of new articles are given more of a sense that they are equal participants in the project, and have the option of bypassing RfP altogether. Final decisions are reached through discussion and consensus, not a combination of unilateral reviews and attrition.
• Speed: Time-sink "loops" like AfC's submit-and-decline cycle are avoided. The process is designed so that the draft moves quickly to either deletion or mainspace. Reviewers can still decide that the draft is not yet "ready", but doing so does not remove it from the queue, encouraging both creators and reviewers to work towards getting the page out of draftspace.
• Language: in guidelines, templated messages, etc., the process will be presented in keeping with the principles above, e.g. draft creators will "request that another editor publishes your draft", not "submit your draft for review".