Requests for comment/Workflows editable on-wiki

This draft overview describes a potential workflow specification and engine. It is written imagining an audience of MediaWiki system architects and workflow specification authors.

Stakeholders

 * Editor and admin community: Begin replacing informal on-wiki process with a formal workflow, where it will be helpful.
 * Extension authors: Tools like UploadWizard could be made customizable
 * Fundraising: We need a formal and transparent way of enforcing rules about how we handle donations.

Architecture decisions
Don't expose another Turing-complete DSL! Workflow customizability is entirely defined by the supporting code (engine and implementation). The idea is that we are creating a DSLL, (like Forth ;), which we use to define very concise descriptions of workflow solutions to a small set of problems.

Complex workflows should be decomposed into smaller, self-contained workflows, which can be executed in parallel or in sequence.

No job will change state unless it's following a defined transition. There is no UI tool which will set a job to an arbitrary state.

Exceptions
A specification may define global signals, which can be sent to a job in any state. This is a shortcut which expands to an implicit transition from every state in the workflow to a special exception state. An example would be, a workflow in when the user can "cancel" at any step, which fires cleanup processing and transitions to the exit node.

If a job becomes uncompletable for any reason, it should be flagged as permanently frozen, and cleanup performed outside of the workflow system. There is no "universal" exception mechanism to catch unexpected errors.

Transactionality
The easiest way to understand atomicity in workflows is to think about when the system is in steady-state. Everything between steady-states should be atomic.

Transition will be protected by a database transaction, but the workflow implementation is responsible for guaranteeing that any action outside of the database is rolled back if the transition fails.

Asynchronous vs. synchronous states
States are asynchronous by default, meaning that the job will be paused after entering this state, and will continue in that state until receiving a signal. A synchronous state is one in which the implementation provides a callback which runs upon entering this state. This callback will usually perform processing, and then send its own job a signal.

Versioning
Modifications to a production workflow are tricky, because there may be jobs in the queue already. Let's do something like semantic versioning, where a minor version change is merely informational, but a major version bump means that the engine must provide a migration to upgrade older jobs.

Diagnostics
Jobs will be logged as they move through a workflow, including any signals or actions.

Implementing a workflow
Components:
 * Implementation
 * Base specification
 * Default configuration
 * Customized specification and configuration

Example: Articles for Deletion
Overview:

Specification
name: Articles for Deletion Queue implementation: ArticlesForDeletion


 * 1) The AfD extension will hook on article save, and will check the article
 * 2) content for new deletion tags.  If this condition is present, we
 * 3) instantiate a new AfD job with the new revision as its argument, and
 * 4) begin the workflow.
 * 5) The workflow is split up into parallel and child workflows, a strategy
 * 6) that should be used liberally, everywhere.  We use the same implementation
 * 7) for all specifications here out of laziness, but there are really three
 * 8) archetypes: discussion queue, provisional endorsement, and admin review.
 * 9) Pages are wired to send the following signals to this workflow:
 * 10)   extend
 * 11)   keep
 * 12)   delete
 * 1)   keep
 * 2)   delete

states: Start: actions: # Append this article to the AfD discussion page, then signal "open" add_to_afd_queue

# This is a soft keep. If a child workflow later acts on "delete_in", # the expiration date and default outcome will be overridden. keep_in: normal_grace_period

# Takes a map from deletion tag name to workflow specification title. # A child workflow is begun, which can signal back to this machine.

fork_on_tag: PROD: Proposed Deletion BLP-PROD: Proposed Deletion, Biographies CSD: Speedy Deletion Queue Copyvio: Copyright investigation

transitions: open: Discussion

Discussion: transitions: # There is logic in here to limit total time open to maximum_discussion. extend: Discussion

# Proposed Deletion PROD: actions: # Only allow PROD once per article. On successive invocations, # automatically send a "keep" signal and wait for admin review. limit_jepoardy: 1

scan_ # Sets an alarm to run delete_in: normal_grace_period

transitions: # signaled by the implementation when the template is removed from the article, or     keep: Keep

#     delete: Delete

Keep: actions: signal: review

Delete: actions: signal: review

Review: transitions: endorse: End reverse: End

exceptions: early_renomination: Keep

configuration: normal_grace_period: 7 days longer_grace_period: 10 days maximum_discussion: 21 days

afd_queue_page: "Wikipedia:Articles for deletion" deletion_review_queue_page: "Wikipedia:Deletion review"