On 09/11/2013 04:13 PM, Adam Wight wrote:
The goal of my RFC was to see if our requirements align with the onwiki administrative and discussion stuff.
As I mentioned on the talk page, I am strongly inclined to keep these requirements separate (regardless of whether the on-wiki version is implemented). See https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Workflow#Breaking_o... .
- After negotiating changes to process, a simple means to promote the
changes to actual usage.
This is one of the key things, along with a simple way to *use* the process, which I'll spell out below. Done right, it is easier than user scripts, templates, and bots. Done wrong, it is much harder.
----
* A simple way to use the process. E.g. a simple way to propose a merge, a simple way to nominate for deletion, a simple way to "close as delete", etc.
- Helpful tools, depending on the process: easy queue management, alarms
for when a grace period elapses, a way to detect when someone short-circuits the process and unilaterally deletes a tag or something...
As mentioned on the RFC talk page, we should carefully consider whether these new Workflows should even use templates (tags), or simply user-initiated processes (I want to propose a new name for a page, so I click "Propose rename") with behind-the-scenes states.
- Level the field, removing obstacles to people who are not
indoctrinated in admin culture or tech skills.
This is not impossible, but I'm skeptical. More likely, there will still be a "tech crowd" (maybe a little larger then the current tech crowd that works on wikitext and Lua templates, but probably not a *lot* larger).
This could still be worthwhile if it's easier for these people to implement process changes.
But we should also be sure to optimize for the people using the process (e.g the user who wants to rename a page using a Workflow).
Matt Flaschen