Requests for comment/Staged actions

Request for comment (RFC)
Staged actions
Component	General
Creation date	28 November 2011
Author(s)	Timo Tijhof
Document status	in draft

This page describes a mechanism for proposing actions that is meant to address issues of efficiency and usability for editors and administrators alike, both for beginners and established users.

This proposal was first drafted by Krinkle in 2011 at Wikimania following Jimmy Wales' talk about "bots eating my edits" where the software allowed the user to make a logically incorrect edit (specifically regarding Merge Requests on the English Wikipedia).

Problem

When a user isn't allowed to perform an action due to missing user rights, the action is virtually undiscoverable for that user. This includes:

Blocking and unblocking of users.
Protecting and unprotecting of pages.
Deleting and undeleting of pages.
Granting and revoking of user group membership.
Renaming a page.

In addition to scenarios where users aren't authorised to perform the action (and thus don't even have the interface shown in their action menu), there is also the important scenario of a user having been granted the right to perform a certain type of action, but social policy or uncertainty motivate the user to establish consensus before performing the action.

For example, "Page renames" and "Page merges" are abilities we grant relatively early on, but in practice users tend to discuss these before hand. The same applies to things like "Articles for Deletion" nominations which (aside from exceptional "speedy" cases) are discussed before being executed.

Proposal

The MediaWiki interface should expose all available actions for content entities and user entities - by default. This means that when viewing a page, the "Rename", "Delete" and "Protect" action would always be presented. For users not (yet) authorised to perform the action themselves, this linked form would allow the user to propose the action, rather than perform it immediately.

From an end-user perspective this may be perceived as having "requested" an action, or having "staged" a change.

Note that I am not proposing an automated way for creating workflows or discussion threads.

Approval

Instead, I'm proposing an automated way for staging a user action. An action that can be approved or denied by any user with the relevant permissions by clicking a button.

Discoverability

These requests and staged actions would be discoverable and organised. They are associated with a subject (e.g. a page, or user). This means if a second user is considering to "Request user block" or "Nominate for deletion", they would naturally find the existing request and can instead watch that, comment on it, or approve it (if they have these rights).

Again, these are not mapped to an existing discussion hierarchy, no (semi-)automated edits in wikitext or project pages. These are staged actions semantically associated with an action and a target (e.g. a "block user X", "delete page Y"), in a way that is machine-readable and discoverable as such.

MediaWiki would be self-aware of a page being proposed for deletion, without requiring an edit to the page in question to insert a template to state this fact.

User interface

In terms of user interface, I imagine this would feel similar to the merging and closing of a pull request on GitHub, or a task in Phabricator.

For GitHub, the action is "merge" and the subject is a branch. When viewing a origin branch, the system discovers the existence of a relevant pull request. When viewing the target repository, the system allows you to see all open pull requests by target repo, or by user, etc.

For MediaWiki, the actions can be things like "granting a permission", "protecting a page" or "blocking a user". These proposed actions would present the subject of the action, and any parameters. With a way to approve or decline the action for users with the needed permissions.

The staged action could have a conversation take place below it for comments and thoughts from others (similar to an issue tracker or pull request). This could be an embedded talk page, Flow/StructuredDiscussions thread, or other system to emerge from Talk pages consultation 2019.

Further possibilities

Attribution

The action could be attributed to the proposer, instead of the performer. I believe would improve on the current social experience by making users feel included and rewarded for their efforts. It may decrease the gap between administrators and users. It may encourage the idea that administrators' job is to interpret established guidelines, asses consensus, and approve requests based on that - as opposed to the idea of administrators acting in isolation based on their own judgement and being the sole users with the ability to perform these actions.

Micro contributions / User dashboard

Users could have a dashboard where they can easily find tasks to perform. (Based on their permissions level).

This would open a new path for micro-contributions, allowing the duties to be much easier to perform for authorised users. For example, it would allow more of these actions to be easily performed from a mobile device without the need to navigate a complex workflow.

An administrator would log in and arrive on their dashboard to find that there are "X pending requests for protecting a page", sorted in some sense, with a way to easily and quickly approve actions as they see fit.

Draft edits

When a page needs to be locked for editing (either temporarily or indefinitely), wikis currently have two (bad) options:

Use "Page protection" which offers no discoverable way for users to draft a contribution. On English Wikipedia, this is somewhat mitigated through a custom version of the "This page is protected" message, which contains button to start a talk page thread where a user could then describe what they would like to change for someone else to then manually find, manually implement, with no formal ability for the user to easily draft it themselves or get recognised for their contribution in a way the software considers as an edit to the page.
Use "FlaggedRevs" which freezes the public version of the page to the last reviewed version of the page. Users can then use the normal editor to propose a change. However, each proposal is required to build on top of the previous unreviewed proposal (which the user hasn't seen before they start or is otherwise aware of), and reviewers are required to approve changes either in order or in bulk.

The notion of staged actions may serve as the basis in the future as the way to to "draft" or "propose" contributions. If the internal logic for staging actions is made generic enough, it could be allow proposing of edits as well. The internal software logic would be invoked as usual (including automatic resolution of conflicts where possible, and attribution for the edit). This would allow for a more "pull request"-like model for editing pages might be a more sustainable and scalable alternative to "Flagged Revision" for times where an article is locked for most users (page protection).

Examples

An administrator can easily find ways to contribute by showing the list of open requests for action X. This would effectively remove the need for categorisation and template maintenance relating to these workflows currently. It would also avoid problems where current workflows are enforced by bots that can effectively eat edits when users "do it the wrong way". The software should acknowledge the structure of these workflows, instead of being free-form and enforcing afterward. The problem here is that our current system allows and effectively encourages users to do things wrong, and being punished for it.

People can participate from either subject or action perspective:
- Administrators can find open requests for admin actions.
- Editors interested in page merging can find page-merge proposals.
- Editors interested in a particular subject can discover the proposal by being programatically associated with the subject. For example, the page-merge proposal might manifest on the subject's talk page in some way, or perhaps surface on Watchlist/Echo notifications somehow. All this without needing bot-assisted synchronising of talk page and transcluded subpages.

Enable future work on a "Community dashboard" (like WikiHow). In addition to advertising admin actions to admin users, there are other micro actions and big actions we can promote there:
- For example "241 unpatrolled edits" (in topics of my interest), "2,510 wanted articles", "4,012 articles to be categorised" etc
- There could be a section for queues specific to the user groups the user is a member of, or has otherwise subscribed to ("19 open unblock requests", "2 open merge requests", "7 requests for user rights".

Simple way for users to request things without the need to follow a complicated style guides and learning templates and finding what to write where and then do a bunch of stuff here and then placing some template there.
- For example, Wikimedia Commons has a gadget (enabled by default) to nominate files for deletion. It involves doing half a dozen API requests, substituting a bunch of templates and in the end ends up saving edits to 3 different pages. How did this happen?

Easier integration in countervandalism tools. With an increased number of editors and reviewers, there will be an increased need for a ticket manager so that reviewers know how to follow-up and can easily demonstrate past experience with admin tools without being an administrator.
Having block requests and warnings programmatically recognised could obsolete the need for User_talk:Example/blockmsgs subpages on Wikipedia.

Simple way to request user rights. Currently when users try review tools without being a member of the review user group, they need to find the appropiate project page, learn templates and wikitext, make the request and wait. And this process differs from wiki to wiki, further making it more difficult for the developers of these review tools to help users succeed in requesting a user right. A ticket system for staged actions would enable having a one-click button for "Request patroller right" that would on any wiki without prior software configuration or setting up of workflows. Once you assume the request system exists, it's sometimes hard to imagine how it's currently done - if one wouldn't know any better.