User:Sdkb/Vision for a better Article Wizard

The current (2021) Article Wizard is not very good. It requires users to go through a bunch of technical steps that aren't needed and just introduce potential for error, and it doesn't actually help them draft a good article. On this page, I'm laying out a vision of a better Article Wizard. It would ideally be combined with a better VisualEditor that warns you when you do something like using peacock prose, adding an external link to the middle of the body, or adding content without a reference (see mw:Edit check). It's currently just a rough outline featuring a bunch of non-functional steps, not an actual design, and it would take lots of developer help to realize. If you would be interested in working with me on a grant for it, please reach out.

The vision

1. • Warns if article or draft already exists
   • Guides user through an undeletion request if it's been previously deleted (if deletion rationale appears to still apply, provides explanation)
   • Assists with disambiguation if needed (including adding a hatnote), e.g. if creating Jane Smith (underwater basket weaver) when Jane Smith already exists
   • Existing articles with a similar title are displayed somewhere (sidebar? suggested results in search?), and if the editor indicates that one is the intended topic, gives option to create a redirect to it
   • If there is a probable match on Wikidata, attempts to connect. If article exists in another language, points to the translation tool.

     The why: We want to avoid creating duplicate entries on a topic, instead leveraging existing work/data.

2. Select article topic: Biography Organization Event Place Creative work List Other
   • Additional layer(s) refine topic further. For instance, options under "biography" could include "athlete", "academic", "artist", "politician", etc., and options under "creative work" could include "book", "film", "song", etc. The topic tree is editable by the community and can be expanded over time.

     The why: This information will allow us to customize the rest of the wizard to tailor it to the topic. Having the topic tree be editable by the community will help it grow organically and adapt to future changes.

3. What is your relationship to [article]? Financial connection Non-financial connection None
   • Automatically adds a COI disclosure to editor's userpage and draft's talkpage if there is a COI, and warns them not to edit directly

     The why: WP:COI is an important guideline. We want to make it easy to adhere to to help preserve Wikipedia's neutrality.

4. (Brief paragraph about reliable sources) Please enter URLs of three sources:
   • We could experiment with having a non-prominent "add more" option that'd allow editors to submit up to five.
   • For each source, checks against WP:RSP or other list. If it appears unreliable, prompts user to change it.
   • For each source, asks user whether the portion directly discussing the subject is a few sentences, a few paragraphs, or longer. If a few sentences, prompts user to change to more significant coverage, and if a few paragraphs, warns that it may be borderline.
   • For each source, asks user whether the author has an affiliation with the subject. If so, prompts user to change to an independent source.
   • If sources are reliable, uses Citoid/similar to automatically fill out references.
   • If subject has SNG, asks user to select criterion and provide source for it.

     The why: Articles that don't establish notability are unlikely to be retained. Structuring the task will help newcomers establish it more easily and reviewers see more easily whether it has been established. By placing this up front, new editors are spared having to write out an article on a non-notable topic and less likely to become resentful. Asking for three sources allows for one error, given that two are needed, while still minimizing the number reviewers will need to check. This step is notability-focused but gives editors a start on referencing that they can use in the next step.

5. Form asks basic details about the topic (all fields optional).
   • If connected to a Wikidata item, prefills information obtained from that item.
   • Many of these will fill out the infobox, but some (such as a person's date of birth or an official website) are introduced to the body or used for categories as well.
   • Asks for a reference for each piece of information, allowing reference reuse. If editor does not do so, provides a warning that can be dismissed.
   • As each piece of information is filled out, a live article preview updates.

     The why: This information will help make the article more comprehensive. Asking for references at each point aids verifiability, but is not so essential as to be mandatory. The live article preview gives editors a sense of progress.

6. Copyright disclaimer—user must check box attesting that they won't violate copyright. If Earwig detects a probable copyvio, provide a bold warning.

   The why: Copyright violations can create a major headache for experienced editors who have to clean them up, so it's important to deter them before the next step, where they could be introduced.

7. Draft is prefilled with section headings, and user is asked to fill out each of them.
   • In addition to the prefilled content from step 5, each section has an associated panel containing concise information (managed by the relevant WikiProject) about what content is appropriate there and other best practices. For instance, the panel for the "Plot" header for a film might say something like "A concise (400–700 words) overview of the film's main events, avoiding minutiae like dialogue or scene-by-scene breakdowns. Use the present tense and include spoilers just as you would other information. Read more"
   • User has ability to modify section names or delete sections if they are not applicable to the topic.
   • If a section is left blank, {{Empty section}} is added to it.

     The why: Many types of content on Wikipedia vary enough that we will never be able to fill them in in a structured way as in step 5, so this free-input step is necessary, even if it carries greater risk of editor error. Sections naturally prompt editors to fill them in over time, so it's helpful to add them even if they're initially mostly empty. Providing project-specific guidance will allow WikiProjects to communicate tailored best practices, minimizing the potential for error, and they can be built out over time as we learn what advice works and what doesn't.

8. One-click button allows user to submit draft to AfC (or maybe, if autoconfirmed and not COI, move directly to mainspace) when ready. A status icon is shown after on the user's homepage so that they can track it (it encourages them to be patient).

   The why: We want to make it easy to enter our review pipeline. The status icon aims to help reduce the number of users coming to the Teahouse asking for an expedited review.

9. Standard elements are added automatically or (when not possible) through prompts, including:
   • The software prefills a suggested short description using some combination of the Wikidata description, categories, AI from similar articles, and words in the first sentence following "(is|was|are) a". The editor is allowed/encouraged to tweak it, and is warned if it goes over 40 characters (and warned sternly if over 60).
   • An English variety tag and date format tag is added if the draft is detected (based on categories or Wikidata) to be about a topic in a particular region with a preference, although the editor is allowed to change it.
   • {{Authority control}} is added if the article is of a type (e.g. a biography) that should have it.

     The why: Adding these elements will improve the article quality, help guide its future development, and reduce the burden on reviewers who would otherwise add them. We want to make it as quick as possible to add them to keep the wizard short (balancing this with the need to provide enough guidance to reduce the error rate).

10. If draft is declined, user is guided through quick help screens explaining the relevant concept.

    The why: We want to make it easy for these editors to understand what they did wrong and how to fix it, as other editors are unlikely to do the work for them given the huge volume of drafts.

11. Once created, prompts user to optionally de-orphan, add redirects (I envision a window where you can just type out a list and they'll all be created), and nominate for DYK (if long enough).

    The why: De-orphaning helps integrate an article into the encyclopedia and guides readers to it. Redirects guide readers to articles and help avoid the creation of forks. The DYK process also drives attention to an article and provides a reward to the editor that encourages future contributions. None of these things are essential, but we want all of them to be easy.