Flow/Workflow Description Module

This document describes a process by which local wikis may design and implement workflows in software that take advantage of software features without having to update the code. In particular, take advantage and configure Flow technology with on-wiki configuration and management.

This system would be called a workflow description system.

Rationale

Taken as a whole system, there exist an almost innumerable number of workflows that exist on wiki-based projects that utilize talk pages as their underlying mechanism.

While it could theoretically be possible to address these workflows in "hard" software related to Flow, such solutions would not be flexible enough to meet the needs of over 380 individual wiki communities. Worse, hard solutions would likely be language-specific, and the Foundation projects span over 280 languages.

Accordingly, a system must be designed and implemented that will allow for each individual wiki to design and implement workflows locally, in the language of that wiki, that support their particular use cases.

This is especially important because local wiki processes may change over time as consensus changes or the wiki matures.

Examples of Existing Workflows

This list is not meant to be illustrative, not exhaustive.

• The English Wikipedia's "unblock request" workflow
• Sockpuppet Investigations
• Administrator's Noticeboard notifications
• Help requests
• Teahouse invitations

Feature List

In order for this feature to be successful, the following features should be included and fleshed out.

(This is a working list)

Must Have

Language Agnostic

The descriptor language must allow for localization and internationalization

Locally Editable

Local wikis must be able to design and implement their own workflows.

Allow for Embeddable Form Elements

Workflows may require the use of buttons and forms to do automatic posting to Flow boards or trigger other actions

Allow for Interactivity

Some workflows may require the use of JavaScript for best performance (such as activating Guided Tours)

Allow for Stepped Decision Trees

By their nature, workflows are stepped "wizards" that may result decisions, creating their own branches.

Allow for Inclusion of Images

Some workflows may require images (such as illustrations or example mockups)

Allow for Abort Actions

Workflows must be able to be cancelled.

Nice to Have

Human Readable

While the underlying technology will likely be written in code, the workflow descriptors themselves should be human readable, or at least require a low-threshold for learning the particulars of the language. A language like JavaScript is probably at the "more complex" end of the acceptable spectrum. However, it is entirely possible that something as basic as Applescript can serve.

Prevent Bad Design

The system should, as much as possible, prevent local wikis from implementing poorly designed workflows. This includes but is not limited to:

1. Workflows that cause performance stress on the cluster
2. Workflows that are excessively long or complex (say, 15 steps, or require 10 control elements)
3. Enforce word or character counts in descriptions (to prevent users from including book-length tutorials)

Optional

Reference Implementations

It would be good to have and ship with a series of "reference" workflows that illustrate best practices and the power of the system itself