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_…
.
* 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