Flow/Workflows workshop

Notes from the workflow workshop, 11/1/13

Intro by Adam (what is a workflow?)

Any process that happens in time can be called a workflow. That exists independently of whether it's computerized/written down. (Handouts: deletion chart on WP (see right) – computer would die if it tried to read it, b/c it has a lot of hidden information. Meiosis. Girl-scout cookies: best example.)

Usual way to break a workflow down is to draw a graph for how something moves from one state to another.

E.g., State =1 --> action --> State =2.

Assumptions

There are things called states. Nothing happens in a state. There are arrows (flow arrows) and actions. Any job that we talk about has a main state and some variables. Arrows can go in any direction – even bidirectionally. Arrows are triggered by a signal; makes sense to talk about them by name of signal that triggered them. Workflow elements have hierarchical relationship; can be asynchronous, are always nested within other workflows – every level of the workflow can communicate with every other level.

Advantages/disadvantages of using formal workflows

Advantages

well-defined transitions allow us to do validation
visualizations are clear
procedure is intuitive
serializable
reproduceable
scalable/modular

Disadvantages

procedure is limiting – only use them where they're going to be an improvement
not good for freeform things
level of detail is a judgment call
Most importantly: it's conceptual overhead. Might help one person organize their thoughts, but will mean that next person who touches the code has to interpret it, understand the framework. When things change, you'll need a schema migration.

Some comments by Maryana

I want us to be careful of some of these disadvantages.

Procedure is limiting – we don't want to create more bureaucracy or formalize existing bureaucracy in a way that makes processes even more impenetrable for new users. (Example: "I'm sorry, you can't create a new article until you've checked off the 50 boxes of requirements on this AfC modal")

Conceptual overhead – if we create a workflow language for the community to create/modify their own workflows, we'll have to hand it off to volunteers who need to be able to make sense of it. If we want this to empower a wider range of contributors than the kind of people who currently write Lua templates or edit Mediawiki.css, we'll also have to spend engineering time creating a way for non-technical users to manipulate the workflow structure (Matt Walker gave example of G-code).

Not good for freeform things – when Wikipedia started out, it was a tiny community of people who just talked to each other to decide things. The complex, formalized, structured processes that we see today came about because the number of people contributing grew rapidly beyond the limits of what the discussion tools (talk pages) could support, and it became impossible for everyone to stay in the loop about everything they cared about. Flow + Echo can change that, and we should see how far better discussion tools get us before we start on formal workflows.

Comments from Oliver

Sometimes the informal process is less transparent, more constricting/limiting than if it were formally codified in software. Example: blocking process, where users have to edit a template to request an unblock, which is super confusing.

What is not a workflow

Anything that's free-form, open-ended, not sequenced.

Examples

writing a Wikipedia article – there's no one right way to do it, no one correct sequence of steps
talking to people on Wikipedia – (Erik B.) but when you add voting to the mix, does that make it a workflow? (Oliver & others) people do count votes, but we don't necessarily want to push consensus-based decisions more in the direction of votes by just reducing it to the software counting votes, etc.

Possible workflows in Flow feature ideas

We took a spin through the etherpad (http://etherpad.wikimedia.org/p/Flow_workflows(?)) and tried to see which of these processes would make sense as formal workflows. The one we all agreed on was blocking/unblocking.

Conclusions

After the WikiProject release, the Flow team has two possible paths: user talk and article talk. For both of these, we need to figure out whether there are any workflow-like processes that might work better as formal workflows – e.g., block/unblock. But we should be judicious and careful in our choices. We probably won't get to this in the next 6 months – about the same fuzzy timeline as the Fundraising Workflow extension. So our two teams should continue talking and check in on this when we both get closer to working on it :)