User:Enterprisey/Edit Request Wizard plan + notes + log

Project goal: Creating a step-by-step form for submitting edit requests, with the aim of making it easier for beginners to learn how to edit.

Project components:

• A frontend: a form as described above
• A backend: a service for doing things we can't do in the browser. For example, we can't grab the HTML of an arbitrary website in the browser (that is, from the form, using JS/TS) due to security policies, so we need to ask the backend to do it for us.

An edit can do a lot of things: fix grammar, correct an error, and so on. We'll focus on one of those things: perhaps "add a fact to an article", for example. We will break it down into multiple steps, and make a form that has those steps.

Using the example of "add a fact to an article", here's how I would break it into steps:

1. Get a fact
2. Get a source that supports the fact
3. Get a specific quote from the source that supports the fact
4. Rephrase the quote in your own words
5. Locate a spot in the article where the fact should go
6. Publish!

(We can definitely change all of this around; these are just my preliminary thoughts.)

And here's how each of these would become steps in the form:

1. Get a fact: I don't know if we'd want the user to type the fact in. We probably wouldn't use whatever the user typed here. Maybe just so they can remember.
2. Get a source: Something like Visual Editor's cite interface. Probably using simpler words everywhere. Maybe just a text field where we autodetect whatever they paste in (URL most likely, or DOI, or ISBN, etc etc) and have buttons with particular source types (book, newspaper, etc) underneath in case people don't know what to do with the text field.
   Validation for the source: Now here's the first tricky part. First pass, I'm thinking WP:RSP green and/or "used on an FA/GA". Rationale: we want to make sure that if the user submits the form, then whatever comes out the other end isn't totally worthless, or at least isn't vandalism. (Why? Because we don't want to be responsible for a new wave of awful edit requests...)
3. Get a quote: Big ol' text area - "Please copy and paste a short quote from your source". For website sources, we would then check that the quote actually appears on the website (plus some minimal edit distance?). For books, journals, etc, IDK, but I'd imagine we could hack something up. Now, we probably can't submit the precise submitted quote with the edit request due to copyright - probably just "starts with these words ____ and ends with these words ___" (using enough words to uniquely identify the quote).
4. Paraphrase the quote: Another big ol' text area. Show the quote from before, maybe also show the fact they typed at the beginning. Validation for this one will be tricky (by which I mean likely impossible) - maybe we'll just have to rely on the standard edit filters. Also length (word count, character count, sentence count) can't be outside a 0.5x-2x range of the quote, maybe? That sounds too robotic.
5. Find a place in the article: I assume this will all be in a (draggable) modal over the text of the article, so we just make our modal tiny and let the user click wherever in the article. This is gonna require a real slick interface to convey to the user that they must do that. Probably doable. Alternative: just click a section or paragraph. (Maybe that's a better idea than clicking a specific location?)
6. Submit: We'll let the user submit at this point. Maybe we'll also let them submit after any step completed above, as partial credit. I'm thinking just dropping it onto the talk page, probably formatted nicely with a subst template or something. For initial stages of testing/deployment, these would most definitely go in some sort of database or holding zone and nowhere near live pages.

Deployment plan:

Pick one heavily-trafficked article that people would want to say things about. My mind is thinking of some well-known pop musician, for some reason. Probably a good stress-test.

Then we'd put a "Suggest" tab next to the "Edit" tab. We might want to change its appearance to make it stand out - white text on dark background? animation (probably not... unless we make it happen just once)? The tab would bring up the modal dialog as above.

See what happens - instrument the heck out of the dialog to see where users get stuck. If we only get useless responses, tweak until it stops being so bad. If that proves impossible... we'll cross that bridge when we come to it :)

If the responses start getting more useful, we'll put 'em live on the talk page and see how editors deal. Major component here: closing the loop and getting feedback to those who submitted the requests. This'll be tough with IPs. For registered accounts, we can have a bot drop a talk page message whenever there's a new reply in the section for their edit request. Or something like that. Does that send an email by default?

If we're looking good still, expand to another page (different topic area, I imagine, for diversity) and, after a waiting period, another, and two more, etc etc. Once we get to maybe a dozen (?), start expanding faster. I'm thinking a combination of top articles by traffic and WP:VAs. Or maybe articles with lots of talk page traffic and/or (in)valid edit requests received.

In parallel: add more "workflows" besides adding a fact - perhaps updating text that has a factual error (which is the same workflow above, except now you select existing text in the article to change, and you rephrase that instead of writing a new paraphrase), or adding something from Category:Inline cleanup templates (although that could get nightmarish FAST. here's the most spitball of all spitballs: limit inline cleanup tags to max 10 per page, then let people upvote them, then let people add another one as the 10 get resolved? but that's out of scope).

Precise technical details on deployment:

I'm pinning my hopes on T241524 ("Parser function for loading gadgets") for now. Current status (2022-06-06) I believe is we're waiting on Krinkle's thumbs-up or thumbs-down. Failing that, we could do a default gadget (I have no opinion yet on whether we let IPs do this). Commons.js is right out.

Other stuff:

• We need a RfC on the deployment plan at VPPR, probably starting... nowish (so we can let the full month run).
• To repeat an earlier point for emphasis: it should be as impossible as we can make it to vandalize with this tool. Yes, this will reduce the expressivity of the tool. The recommended alternative will be the normal editor
• Where I'm coming from, philosophically: the best way to get people into wikipedia is to to find them when they want to make an edit, and let them accomplish something concrete in that moment, even if it's not making a full edit to the live article.

Action items:

• @Enterprisey - draft that RfC
• @SD0001, Firefly, Ankit - thoughts and comments, please

Initial plan (2022-06-16)

starting from the popup window that ankit demonstrated:

• make it draggable
• look at the form, and look at existing forms, and try to follow their overall design / design language
• make it put the values on the talk page: Wikipedia:User scripts/Guide#Using module mediawiki.api 2 (mw:API:Edit)
• convert the form into steps (for example, step 1 has just the text field for the url)

no validation for now

meeting 2 (2022-06-23)

• change the citation screen to use Citoid: mw:Citoid (make it look like the visual editor "cite" view)
• while the user is selecting text, show this to the user, like by dimming the rest of the screen
• check that the quote comes from the cited url (in the script if possible, if the backend if not possible)
• also store the section that the quote comes from (and the paragraph too, if possible). add click handler to paragraph, look for mw-headline above the paragraph

for enterprisey: rfc (community vote) for deployment

meeting 3 (2022-06-30)

status:

• all items from meeting 2 done except the last
  • idea for that: check the previous element sibling, and if there's no sibling, go to the parent element. you will eventually encounter an h2. if you don't that's fine, just write "no section"
• user can now enter url (passed through citoid), select text, quote, and rephrased quote

for next time:

• start looking at toolforge wikitech:Help:Toolforge/Web
  • first you'll need the quickstart wikitech:Portal:Toolforge/Quickstart
    • you will create a new tool.
• add section heading (mw:Help:Formatting) level 2 to beginning of template
• (lower priority) WP:RSP. scrape to json file with URLs and statuses. for now, no automatic updates (just scrape once) - automatic updates are later

meeting 4 (2022-07-07)

for next time:

• fix Access-Control-Allowed-Origin
• show status of url: User:Headbomb/unreliable.js
  • if comment is 'Deprecated source', 'Wikimedia-related website', 'Blacklisted source', don't allow the user to use that source
  • if the comment is too long and complicated, just use the first few words (like just 'Borderline source')
• when headbomb adds a way to import unreliable.js, do so
• when selecting text, if no node is found, show error to user instead of just in the console ("first section or unknown section")
• add new panel with explanation at beginning

meeting 5 (2022-07-24)

for next time:

• (high priority) whenever the script is waiting for a network request, it should show "Loading" or something like that
• if the website doesn't exist, like https://exampleasdf.com/, it should not be allowed
• when the kind is "unreliable" it should not be allowed
• finish caching for the JSON, cache for 1 day (86400 seconds) is ok, no need to check for a more recent version (like with revision IDs)
• don't have the title "EDIT WIZARD" on the top of every panel - or if you want to keep the title, remove the padding. you choose whether to remove the title or keep the title
• no need to do a welcome panel for now unless you want to
• try putting the edit wizard button as a tab next to "edit"
  • one method: using https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.util-method-addPortletLink - that function returns the element, which you can pass to the $button parameter in the PopupButtonWidget constructor
  • the tab should visually stand out
  • you don't need the text that says "Please select the text before continuing" when you switch to a tab
  • or try whatever works
• for regex: be sure to add \\b like in https://en.wikipedia.org/wiki/User:Enterprisey/unreliable.js#L-111
• (lower priority) no "verify" button: verify automatically or "continuously" after user has stopped typing for half a second (and also when "next" is clicked) https://stackoverflow.com/a/5926782

meeting 6 (2022-07-28)

for next time:

• when wikipedia website is entered (or anything from that list in JSON, like wikinews.org), it should show specifically "wikipedia cannot be used"
• now that we're using a tab, for "done selecting", change the tab text now
• in the template on the talk page, only put the first 3 words and last 3 words
  • options: regular expression, indexOf, split(' ')
• the "no verify button" can be left until later, no need to work on it now
• potential bug - infinite "loading..." with 10.0002/1234

feedback #1 (2022-07-29)

(thanks Barkeep49 and perryprog)

• some text is only loaded with javascript enabled, so it won't work if you're just checking the HTML source. example: on this page https://www.basketball-reference.com/players/b/brousel01.html, the text "May 28, 1974: Drafted by the Portland Trail Blazers in the 8th round (128th pick) of the 1974 NBA Draft." only appears when you're loading the page with javascript, but it doesn't appear in the HTML source, so the script rejects it. what we can do: we're probably going to have to use headless chrome. this will be a pain in the butt but such is life.
• selecting a sentence is a subpar user interface. consider alternatives. one alternative: every sentence is numbered (and the numbers are displayed in the page), and the user types in the number of the sentence. or we could just do the usual "click on the sentence" - every sentence gets wrapped in a <span> and we put click handlers on all of them. we should do the second one.
• format the source in a <ref> tag so that it can be copy/pasted (citoid can definitely do this)
  • in fact, replace "Rephrased Quote" with "Text to Add", followed by wikitext in a <code>, followed by the same wikitext but directly included ("rendered")
    • most generally: make the report easier to action (be sure to add the proper templates/formatting, test compatibility with existing scripts like User:Terasail/Edit Request Tool or User:Awesome Aasim/editrequest
• abstract: big risk of close paraphrasing & copyvio, think about mitigations. noodletools "explain it to yourself in words you can understand"
• abstract: think of responses to "teaching editors to edit and other goals of this project are fundamentally things an automated wizard can't do". perhaps "the community would have to do an equivalent amount of work to onboard them anyway, we're just making it easier for them to 'get on the other side of the table', so to speak"

makes me (enterprisey) think of another one:

• change error message for invalid quote to "make sure the quote is copied/pasted exactly from the article", or something with that meaning

See also

• User:Enterprisey/Edit Wizard design doc