Talk:Requests for comment/Workflows editable on-wiki

WHY
This RFC is missing a fundamental piece of explanation: Why do we need a workflow system? What are the alternatives and how do we weigh our options, before we even go down the path of ironing out details about how a workflow language would work. I remain unconvinced a complex, heavy-handed solution like this is necessary or worthwhile to invest our time in. Steven Walling (WMF) &bull; talk   16:25, 11 September 2013 (UTC)
 * Agreed. I do think fixing the many broken workflows on Wikipedia is worth our time and engineering effort. But I want us to be extremely careful when approaching this problem and have a crystal-clear understanding of:
 * what the current workflows actually are – how many of them are there, and what needs do they serve for users?
 * which ones are the most important to fix in the short-term (e.g., affect the most users, or the most critical content creation/improvement processes)?
 * which ones aren't actually workflows, so much as discussions gone haywire?
 * This last point speaks to my ideological disagreement with framing Wikipedia processes in the engineering-centric "workflow" way. When Wikipedia began, and up until the past 5 years or so, its lifeblood was peer-to-peer discussion. Everything from which pages to delete to who gets admin rights and who gets banned was worked out via consensus-based discussion among users, not automated or semi-automated processes. That began to change when the community grew too large, due in no small part to the fact that sane discussion systems (notifications, feeds, basic filtering of conversations by relevance/popularity/newness) were not present. The big "decline," as we like to call it, started to take hold in lock-step with the growing proliferation of user-created workflows reliant on templates and bots, which in many cases were meant to actively obscure the fact that, at heart, these processes were still just people talking to people about stuff (see AfC for a classic dysfunctional example). My biggest fear in creating a workflow language is that we cement this trend toward automatization, and, in the process, kill the spark of humanity and community that makes Wikipedia such an important part of life for our users. Maryana (WMF) (talk) 17:09, 11 September 2013 (UTC)
 * Cool! This is a great challenge to raise.
 * Whether such a thing will make the discussion culture more or less human is really important. I'm not going to make an argument either way on that, but I have two observations which probably won't help: first, negotiating a process will be easier if there is a clear, readable description of the process; and second, machine-readable workflow descriptions are never friendly or readable to humans, even if we draw a picture.  I noticed as much when trying to translate Oliver's AfD graph to a proper Petri net, because he had made things readable at the sake of strict accuracy, and any machine-executed workflow must be accurate first, readable second.
 * Personally, I believe this is close to the lightest possible useful design, and I'm sure I could write the basic engine in 2Kloc or less. It's just a directed graph model that you can extend with PHP and JSON/YAML.  It doesn't quite make my point, but here's an example of a perfectly functional workflow implementation in about 300 sloc, https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/StateMachine.php
 * Adamw (talk) 17:24, 11 September 2013 (UTC)
 * Why does everything need to be machine readable? One of the upsides of the AfD process is that it is human-centric. --In actu (talk) 18:25, 11 September 2013 (UTC)

Mailing list discussion
Some talk here: http://lists.wikimedia.org/pipermail/ee/2013-September/000668.html