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 Wale's 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: 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 an action, but not feeling confident to perform it without agreement from an established user. This is especially important for actions like Page renames and Page merges which granted early, but are often non-trivial to perform due to established conventions.
 * 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.

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 to filing a request for the specific action to be performed.

Note that I am not suggesting an automated way for creating generic discussion threads. Instead, I'm proposing an automated way for staging specific actions to be performed. 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.

Future ideas:
 * Once the action has been performed, the request can automatically close.


 * The action could be attributed to the proposer, instead of the performer.
 * Currently pending actions can be exposed through a dashboard where authorised users can easily perform the actions as a micro-contribution. E.g. an administrator would use their community dashboard to find that there are X pending requests for protecting a page, sorted by date, or number of supporters etc.
 * The staged action could have a Flow thread attached for comments (Structured Discussions)

In terms of user interface, I imagine this would conceptually be similar to the merging and closing of a pull request on GitHub or Gerrit. Where the action is "merge" and the subject is a branch. When viewing the branch, it can discover the existence of a relevant pull request. But one can also list all open pull requests.

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.