Note! We've gotten lots of strong applicants for this project already. Consider applying to other projects or organizations instead.

---

Brief summary

Create a step-by-step form to help beginners submit a Wikipedia edit request. An edit request is a request for someone to change some text in an article. Edit requests are an important part of Wikipedia. The form you create will help the edit requests comply with Wikipedia policy. For example, if the edit request cites a source, that source should be reliable.

Why? To fulfill Wikipedia's mission, it must be easy for anyone to become an editor. However, Wikipedia has a lot of rules. It's not easy for beginners to follow them. This project will guide beginners as they make their first edits. Most of their attempts will need further help, so we will submit them as edit requests.

This project will make editing more accessible for people from all backgrounds.

Skills required

• For the form:
  • frontend development skills (HTML/CSS/JS) required. No specific framework required. Svelte or jQuery (it's a really simple UI) slightly preferred.
  • interface design skills preferred; graphic design skills would be nice, but are not required
  • it will be in the form of a Wikipedia user script and will probably use the MediaWiki Action API, but prior experience with either is not required. (Would be nice.)
• For the checks (validating the URL, for instance): backend development skills required. No specific framework required. Python or Rust slightly preferred. No experience with database or other persistence required.
• For the project as a whole: excellent English communication, including the ability to read and participate in complicated community discussions about policy. This project has the potential to have a large impact on Wikipedia and great care must be taken while implementing and deploying it. For example, you should be able to read and understand all aspects of our policy on reliable sources.

Outcomes

• A Wikipedia user script that shows a form for submitting a Wikipedia edit request, with high-quality guidance and error messages, suitable for use by beginners.
• A backend server that the user script will make calls to, for checking websites and other purposes.

Stretch goals (if we have extra time):

• an interface to show these edit requests to experienced editors as they read the article
• an interface for the general public to express feedback on these edit requests (as a "safety valve")
• moderation interfaces
• interfaces to supervise the process (for example, to see URLs that have recently been disallowed by an automated process)

Possible mentor(s)

@Enterprisey, @Firefly, @SD0001

Microtasks

I think these tasks might be too hard; you only have to do any 3 out of these 5. You can do more if you really want to, but you probably want to put that effort towards applying to other projects.

Please submit these as part of your proposal. Do not post them in public.

You don't have to do any developer setup or clone any existing repositories for these microtasks (besides what your chosen framework requires). You're welcome :)

If a microtask says to write code, but doesn't say which web technology to use, you may choose any web technology.

Judging criteria for the microtasks:

• Depth of understanding of the edit request process
• Quality of improvements: how much they would improve the user experience and make edit requests more accessible

Before you submit your microtasks, you have the option to send microtasks via private message to Enterprisey on Zulip for feedback.

For Outreachy, each microtask equals one Outreachy "contribution".

Microtask 1

Make an edit request and write about it. Find an article (on the English Wikipedia or any other Wikimedia project with edit requests) and go through the edit request process. If that's too hard - well, that's why we're doing this project :)

Some hints: if you can edit the article, the edit request is invalid. Most articles on this list are protected so that new accounts can't edit them. Click the "View source" button. (If there's no button with that text, try a different article.) Figure out which button you should click to submit an edit request, and follow the directions. You don't have to actually submit the edit request if you don't want to, but you can submit it as a bonus. If you do submit it, you must link to this Phabricator ticket or otherwise identify your edit request as part of a GSoC microtask.

People tell me this is very confusing, so only spend 1-2 hours on this at most (but if you're making good progress, feel free to spend as much time as you want) and then go to the next step (writing down your notes).

Afterwards, write up your notes on the process. (Finding a page is not part of the process.) What was the hardest part? What confused you? If you were redesigning the process, what would you change? What other comments do you have, from a user-experience perspective (or from an end-user's or developer's perspective)? Reason for this task: you won't be able to make a (good) form for submitting edit requests if you've never submitted an edit request.

Microtask 2

Design a form input that allows the user to input a source. A source is a document that's used for evidence. We will (usually) require the user to provide a source with their edit request. A source can be a website, a book, a newspaper article, a scientific journal article, or any number of other things. Design a form that will allow the user to provide a source. At minimum, the user should be able to provide a website (URL) or a book (ISBN) as input. As a bonus, imagine how your form would display the feedback that the source was unreliable. You can submit your design using any method you want: for example, describing it in text, implementing it using some mockup tool like Figma, or drawing it using Paint. You may also implement it in code, but that's not required. Reason for this task: we don't have a designer on this project, so we'll be designing the interfaces together.

Microtask 3

Implement a form for a quote. A quote is some text from a source. We will (usually) require the user to provide a quote with their edit request. Using any frontend technology, implement (write code) for a form that will allow the user to provide a quote. This could just be a text area. Try to prevent the user from submitting obviously invalid quotes. Use your imagination to think about what "obviously invalid" means. For example, the empty string is not a valid quote. Bonus: how would you check that the quote comes from the source? Reason for this task: it's one of the steps you'll be doing in the project, but it's not one of the harder ones.

Microtask 4

Validate a URL. The user may provide a URL as the source. Think of one rule/heuristic that could be used to validate the URL and implement it using any backend technology. It may be as complicated or as simple as you want, but if you pick something complicated I'll be more impressed. As an example, consider the rule "users shouldn't submit links to Google search results". Thus, perhaps URLs shouldn't start with https://www.google.com/search/. But what about https://www.google.com/search/howsearchworks/? Someone might want to use that as a source. So try to make your code as correct as possible (excluding as few valid pages as possible, and including as few invalid pages as possible). Bonus: how would you display the result of your validation to the user? Reason for this task: you'll be doing something similar a lot during the project.

Microtask 5

Complete the user scripts tutorial. It's at https://test.wikipedia.org/wiki/The_Userscript_Tour. Use the channel below if you get stuck. (Fun fact: this was a GSoC project last year, and I was a mentor for it.) Reason for this task: you will be writing a user script during this project.

Warning: the user scripts tutorial has some bugs. Sorry, I'm working on it... might be a while before they get fixed. If you get stuck, no problem.

Other contributions

Feel free to contribute to other Wikimedia projects or other open-source projects in general during the application period (for both GSoC 2022 and Outreachy May 2022, that's roughly during the month of April 2022 - check the links for specifics). We will consider relevant contributions to any open-source project. "Relevant contributions" means contributions related to any of the skills listed for this project: front-end or back-end web development, user interface design, or work on technical specifications.

Note that GSoC and Outreachy are for newcomers to open source, and this section isn't meant to contradict that. This section means that it's fine to contribute to other projects during the application period. This section does NOT mean that contributions before that (for example, from February 2022 or earlier) are required. We will not consider contributions before that.

Need help?

Please use the Zulip channel, not the comments here. Questions may be asked in the public Zulip channel. You may PM microtasks to Enterprisey on Zulip for feedback.

https://wikimedia.zulipchat.com/#narrow/stream/314034-gsoc2022.3A-Edit.20Request.20Wizard

Logistics

For GSoC, this is a 350-hour project.

---

Note! We've gotten lots of strong applicants for this project already. Consider applying to other projects or organizations instead.