Requests for comment/Staged actions

This proposal describes a ticket system that I believe will solve problems affecting efficiency and usability for both editors and administrators, both for for beginners and established users. This proposal was first discussed 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).

Problem
When a user isn't allowed to perform an action due to missing user rights, the action is virtually undiscoverable for that user. For example:
 * 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 require the user to establish consensus for the action before performing it. For example, "Page renames" and "Page merges" are abilities granted early, but often discussed regardless of user experience level. The same applies to Deletion nominations, which aside from exceptional/speedy cases, are always proposed before being executed.

Proposal
The MediaWiki interface should expose all available content and user actions by default in the interface. This means that when viewing a page, the "Rename", "Delete" and "Protect" action would always be listed. However, for users not authorised to perform the action themselves, this link would lead filing a request for the specific action to be performed.

Note that I am not proposing an automated way for creating generic discussion threads. Instead, I'm proposing an automated way for staging user actions. An action that can be approved or rejected by an authorised user (e.g. administrator) with the click of a button. The staged action would also be discoverable in a way that is associated with the page. For example, if attempting to (request) blocking a user, it could lead to an existing request if there already is one underway.

Again, these are not discussion threads, they would not be hosted on a regular project or talk page. 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. The system would be mechanically aware of a page being proposed for deletion, without requiring an edit to the page in question to insert such a notice. Similar to how Special:Contributions warns about the target user having been blocked.

Future ideas:
 * Once the action has been performed, the request is automatically closed.


 * The action could be attributed to the proposer, instead of the performer. This I believe would lead to a more positive social experience whereby users feel included, and would decrease the gap between administrators and users. It encourages an idea of administrators being there to interpret established guidelines, and to asses consensus among users, and perform sensitive actions as needed based on that - as opposed to the idea of administrators acting in isolation based on their own judgement.
 * Pending actions can be exposed through a dashboard where authorised users can easily perform the actions as a micro-contributions. For example, an administrator would view their personal 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 or stall actions as needed.
 * The staged action could have a discussion thread attached to it for comments (similar to an issue tracker, possibly by integrating a Flow-based thread).
 * The system may be provide integration for staging edits. This would not be part of the ticket system, the same way that user blocking and page deletion aren't part of it, it merely acts as a way to store the staged action and perform it once approved. The internal software logic would be invoked as usual. The reason staging edits can't be part of it initially is because MediaWiki currently doesn't support non-linear page history, nor a way for storing user-specific branches of revisions. If and when such capabilities exist, the initial workflow would likely be for personal drafting and sharing resulting in a user explicitly merging it themselves. If the ticket system is in place by then, it could also allow for a more "pull request" like model for cases where pages are protected, possibly as a more sustainable and scalable alternative to "Flagged Revision".

User interface
In terms of user interface, I imagine this would conceptually be similar to the merging and closing of a pull request on GitHub. There, the action is "merge" and the subject is a branch. When viewing a branch, the system discovers the existence of a relevant pull request. The system also provides a way to list all open pull requests, by user, by website (e.g. wiki), or by target (repository; here, a user or a page).

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 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.