Workflow

This page describes a concept which is part of our glossary

Wiki-based workflow is a means of organising tasks into categories to be used as a blackboard system (a.k.a space-based architecture, shared nothing architecture or Tuple space). This is achieved in the wiki by establishing the workflow methodology as a set of best practices defining all aspects of the way the wiki is to be used, and an established resource of structured content to support that way of working.

Here is an example taken from the Wikipedia article which describes the system in terms of Human roles working together on a project.

A group of specialists are seated in a room with a large blackboard. The specialists are working as a team to brainstorm a solution to a problem, using the blackboard as the workplace for cooperatively developing the solution. The session begins when the problem specifications are written onto the blackboard. The specialists all watch the blackboard, looking for an opportunity to apply their expertise to the developing solution. When someone writes something on the blackboard that allows another specialist to apply her expertise, she records her contribution on the blackboard, hopefully enabling other specialists to then apply their expertise. This process of adding contributions to the blackboard continues until the problem has been solved.

A blackboard system enables this flexible brainstorming style of interaction between diverse software specialists. Each of these specialists scans the changes to the blackboard, and posts an updated partial solution based on the state of the blackboard whenever its own internal conditions for doing so are met. These partial solutions cause other knowledge sources to update their portions of the solution on the blackboard until eventually an answer is found. In this fashion, the specialists work together to solve the problem.

In the wiki we define processes which can be carried out by Human roles or program functions. Processes can also be defined which contain other processes in sequences or which can work concurrently. Events can also be defined which lead to the creation of new process instances (jobs) which are categorised into the "todo lists" or "inboxes" of the various roles that they need the attention from. As roles or processes carry out their work, they update the state of the jobs which causes them to be recategorised, and thus the jobs flow between the roles until complete.

Another important related concept is that "everything is a channel", whether its trading, blogging, inboxes or schedules, they're all channels which have relationships with other entities (such as "friends", subscribers, owners or contractors) which undergo change over time. Workflow is also based on this channels concept being "inbox-driven", but it also entails the aspect of processes. Rather than defining our own workflow system, we can use the smart contract system since it's already part of the open trading technology we'd be using (like Open Transactions on Bitmessage) for trading, contracts and trust groups.

Workflow

A wiki-based organisation must operate upon a formal workflow system which allows us to define goals in terms of available roles and processes and monitor their progress and productivity. Also this will mean that all our threads of operations are already "packaged up" for out-sourcing to our established contacts or to other organisations like elance or rentacoder.

The workflow system should be implemented with both the semantic organisation and the nodal model in mind. I think the simplest way to ensure a smooth transition into our P2P vision (web4) is to begin modelling the workflow using the methods and tools we currently use - namely templates. The workflow special page can assist in using templates for a workflow system by rendering a tree interface to the workflow hierarchy. The nodal aspect is that the template hierarchy describes a multiplexed view of the workload which can therefore be processed nodally.

Another important aspect of the workflow system is to track the time spent on each job by the various roles, and to maintain assessments of their productivity (by gaining statistics on the completion time of various job classes). All this information can be maintained by defining and scheduling reports (similar to how we'd implement Selenium for interface testing). Reports and tests are just processes which run regularly storing the result in a particular article dedicated to that test). The "report" namespace would probably be appropriate since they'd contained a specific class of information.

Instantiation

Instantiation of workflow items is an important concept which should work more similarly to make install than to standard object instantiation. Furthermore these instantiated structures should be maintained over time on an appropriate communications schedule with the class or package source. Instantiation starts by creating a new workflow article exhibiting an appropriate template call and parameters. The new workflow is hooked into the overall reducing workflow structure in the appropriate context - eg. a scheduled task, or to be processed by a particular function/service, or perhaps in a Human role's workflow "inbox".

See also

• Channel
• Process
• Platform
• System
• MW:Flow Portal - a new large-scale workflow system for Wikimedia
• Wikipedia:Workflow
• Wikipedia's current wiki-workflow categories
• Wikipedia's article on categoriation
• Wikipedia administration
• The state of workflow - by Tom Baeyens
• File:Roles and Classes in OO.pdf
• Workflowy.com