Edit Review Improvements/New filters for edit review
|Edit Review Improvements (ERI)|
The Special:Recent Changes page is a central starting point for many types of edit review. Collaboration Team is planning a suite of new tools—as a beta option initially—designed to improve edit review on RC page. If successful, these improvements will likely spread to Watchlist and other review pages.
Among the new tools and other improvements are a set of predictive filters powered by machine-learning program ORES (on wikis where ORES predictions are available), and a new interface that improves both user experience and search effectiveness.
These will help reviewers in general to better target their efforts and be more efficient. The improvements also have the potential to particularly benefit new contributors, who require a more supportive edit-review process, according to research. They'll do this by using AI and other means to find edits by contributors who are a) new and b) making mistakes but c) in good faith (a key goal of Edit Review Improvements).
- 1 Phase-One Improvements—COMPLETE
- 2 Phase Two
- 3 Deployment by default
- 4 See also
Phase One RC page changes, available on all wikis as a Beta feature, include the following new capabilities and improvements:
Contribution quality predictions
By enabling users to filter for good-quality edits, these filters empower reviewers who are, for example, looking to thank contributors; by helping detect bad-quality edits, they make numerous types of edit-review more efficient. The quality predictions are made by ORES, a machine learning service trained on a large set of edits previously scored by human editors.
Filters with different levels of accuracy are provided (ranging from "Very likely have problems" to "May have problems"). Stricter, more accurate filters find fewer false positives but return fewer results overall and so miss more of their target. Less accurate filters cast a wider net and find more of their target, but they also find proportionally more false positives. Learn more about predictions.
User intent predictions
By enabling users to filter for edits made in good-faith, these filters empower reviewers seeking to support good-faith users; by enabling detection of bad-faith edits, they assist reviewers looking for vandalism. Like the Quality filters above, these predictions are made by the machine-learning service ORES. Also as above, filters at different levels of accuracy are provided to meet different users' needs. Learn more about predictions.
Experience level filters
Research shows that new editors are particularly vulnerable to rejection. The Experience level filters enable reviewers to treat new users with the care they require and to identify contributions by users at a couple of more advanced levels. These are the Experience level filters:
- Newcomers: fewer than 10 edits and 4 days of activity
- Learners: more days of activity and edits than "Newcomers" but fewer than "Experienced users". (corresponds to autoconfirmed status)
- Experienced users: more than 30 days of activity and 500 edits. (corresponds to extended confirmed status)
The filters return the edits only of users who are currently logged in.
More powerful filtering
Most previous RC page filters offered only a simple option to show or hide a certain property (X). By augmenting these filters so that they now let users show or hide both X and its opposite (notX), the current tools provide more control. For example, previously, one could show Wikidata edits or hide Wikidata edits, but one could not show only Wikidata edits.
Furthermore, by organizing filters into logical groups, the new arrangement provides an improved ability to narrow results. (Logically, the new arrangement provides groups of OR filters, with each group of ORs being connected to other groups by ANDs.) Learn more about filtering.
Among the many user interface improvements included in this project is a user-controllable highlighting function. By letting reviewers apply color to emphasize desired edit properties in the results area, Highlighting makes Recent Changes search results more meaningful. Among other user benefits, this new interpretive layer adds another tool for prioritizing work. Learn more about highlighting functions.
Once the Beta features described above are in place, we will gather user input and test satisfaction, then finalize plans for more improvements. The following options are under consideration:
Extend new functionality to more pages
“Recently used filters”
By enabling the system to remember reviewers’ recent filter settings, help users to repeat their most common tasks quickly and easily, without having to input settings each time.
Upgrade interface and capabilities for the untouched RC page features
Phase one changes won’t affect all tools on the RC page. The following tools will remain unchanged: Namespace filters, Tag filters, filters for time frame, and number of results. Future efforts will likely bring these tools up to the new UI standard. This will enable the selection of multiple namespaces, multiple tag filters, and more specific time-frames.
Support ORES for propagated Wikidata edits
ORES supports Wikidata. You can enable it on wikidata.org and use it on Wikidata' Special:RecentChanges. The ORES extension doesn't currently handle these edits on the client-side (e.g. when viewing Wikidata changes relevant to any Wikipedia in Wikipedia RecentChanges page). We plan to fix it.
Deployment by default
The deployment by default is scheduled for September. It will include the new filtering interface, the machine-learning filter groups “User Intent Predictions” and “Quality Predictions,” the highlighting tools, the ability to save your filter settings for later use, and the new filter groups: “Watchlisted pages,” “Last revision” and "User registration and experience." Other features will be still in Beta.
The release will be done following these options:
- Communities with no strong opinions will be scheduled by the development teams (phase 1).
- Communities with specific concerns or internal discussion can request to have the deployment to their wikis delayed to phase 2 if they have sensible, consistent with the project, actionable, realistic feedback to oppose (at the development team's appreciation).