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.

Contents

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.

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:

Workflows that cause performance stress on the cluster

Workflows that are excessively long or complex (say, 15 steps, or require 10 control elements)

Enforce word or character counts in descriptions (to prevent users from including book-length tutorials)