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) • 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:

1. what the current workflows actually are – how many of them are there, and what needs do they serve for users?
2. 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)?
3. 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.

1. 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.
2. 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)

I defer to this criticism!—I was trying to say as much above, that anything edited by humans needs to be human-readable, and my Workflow design will cause a lot of simple things to get blown apart and made less readable by real people.

But, do you really think the current process is human-centric? AFAICT, the whole thing is dominated by arcane templates that a very few wizards can modify safely. The plan here is to make the big picture both approachable and consistent. Let's work towards increased human-centricity! Adamw (talk) 01:35, 18 September 2013 (UTC)

Wow, Wikipedia as an assembly-line...I can hardly wait. No, I can. The reason Wikipedia words is because it is decentralized and Editors work autonomously. Enforced conformity and regimentation for the sake of efficiency...how revolting. Just think...with any new system you need to a) train people how to use the system and how it works and b) have people to enforce/guide the system. Think of all of that time and effort going towards creating content! Liz (talk) 01:25, 12 November 2013 (UTC)

@Liz: We do already have (both software-based and abstract) workflows, and semi-automation, and standardized formatting, and etc. eg w:Wikipedia:Article alerts/Specification and m:Research:Wikipedia Workflows/Article and many more.

The difficult (complex) questions are:

• What aspects work well, that could be propagated further (to other languages/projects)?
• What aspects could be improved? eg. removing the wall of instructions and sea of templates that w:WP:AFD currently requires (that I have to re-read almost every time), and replacing it with something more "automated" and foolproof like Twinkle, or the sidebar link/script that Commons uses

  At the top of my list, is w:Wikipedia:WikiProject Deletion sorting - this is ripe for automation. I'm so grateful to the editors who do this task, but wish we could save them the time via better software, so that they could do other things.

• What aspects don't work well, or can be problematic, that we'd need to keep in mind throughout any development of a workflow language.

(At least part of the idea, I think) is to find out where editors are repeatedly spending time on paperwork, and improve the efficiency of those tasks via software (if it's practical and ideal to do so, in each case), so that the editors can spend more time making human-only judgements and engaging in content-creation.

Hope that makes it clearer. :) –Quiddity (talk) 03:10, 12 November 2013 (UTC)

I'm also torn on this. I definitely think wikis need discussion-based workflows, and they already have a version of them (though in some cases discussion should be more emphasized). The issue is that the current workflows often require manual copying and pasting of templates or custom gadgets, user scripts, and/or bots. So the conversation here is not whether there should be workflows, but whether to keep the existing template- and bot-based workflows, or provide a built-in solution. With a simple, limited (but not too limited) solution, it might provide a better way to design and use on-wiki workflows. Instead of having to think about templates and processes, I could think more about "human-only judgements" (as Quiddity put it). E.g. as one step of the "propose a merge" workflow, there could be a "Why should this be merged?" textbox. I would then have to consider this and fill out the box before clicking "OK".

But it could also end up just increasing the difficulty of changing workflows. I also question some of the current design, such as that flows should start by detecting a template ("check the article content for new deletion tags"), and that it has to be powerful enough to serve fundraising's needs (see below). If we're already making a significant change to workflow technology, why not instead start a flow with an explicit button (such as "propose a merge" or "nominate for deletion")? If we decide we do want this, I'm also uncertain whether we should be introducing a new (YAML-based?) syntax. It might be better to find a way to do it as a Lua library, or use JSON (which is not used widely on-wiki, but is at least in TemplateData).

If each flow requires an extension (it mentions "The AfD extension"), I also question whether this is general enough to be useful. We can already implement an AFD extension in a non-general way. Superm401 - Talk 05:55, 3 December 2013 (UTC)

Mailing list discussion

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

Breaking off fundraising

The fundraising use case seems very different from the on-wiki one. Fundraising has several extensions alread, and can create more if needed. I'm not sure if "rules about how we handle donations" is referring to the donation user experience or post-donation reconciliation. But regardless, I'm not convinced this should use the same workflow technology as the proposed on-wiki one. For one thing, donation workflow logic might be better to keep in Gerrit-reviewed code. But beyond that, it seems like a on-wiki workflows and donation technology workflows probably have different focuses, priorities, and generality/simplicity tradeoffs. Superm401 - Talk 05:55, 3 December 2013 (UTC)

August 2015

It seems from the presentation at Wikimania 2015 - Searching, Structured Documents, Wiki Discussions - 2015-07-18 that this proposal is active again. Is that correct, or is it a sufficiently new version of the idea that this one can be marked closed? Rogol Domedonfors (talk) 20:42, 30 August 2015 (UTC)

@Rogol Domedonfors: Yes, the Collaboration team will be working on workflows. We're in the planning/early design stages right now, and this RFC does not reflect the current status of the Collaboration team work. Mattflaschen-WMF (talk) 00:33, 1 September 2015 (UTC)

Then perhaps it should be marked {{Outdated }}. Rogol Domedonfors (talk) 21:18, 4 September 2015 (UTC)