Workflows

Uses {{lzUseContext:name = "One-dimensional arrays"}}

Workflows are computations that transform input data into output data, with all data stored in files. The smallest unit of computation in a workflow is a Task, which corresponds to the execution of a program that reads some input files and produces some output files. The workflow defines the dependencies between the Tasks and the data files. A workflow manager uses this dependency information to run the tasks in the most efficient way possible, given the available computational resources.

Workflow tasks resemble functions (see Functions), the difference being that they process data stored in files (of sort `{{lzSort:file}}`) rather than represented by terms. We therefore use the same arrow notation for task sorts as for function sorts:

{{lzSort:(inputs:𝕊) → (outputs:𝕊)}}

Task composition, unlike function composition, is usually written from left to right, representing the flow of information

{{lzOp: (inputs_:𝕊 → intermediate_:𝕊) ⧟ (intermediate_:𝕊 → outputs_:𝕊) : (inputs_:𝕊 → outputs_:𝕊)}}

~

Workflows describe productive activities that are well supported but not enforced by wiki.

We rely on discovered sequences of primitive actions to complete tasks that might be directly supported by designed features in a monolithic system. Primitives, cautiously created when needs arise, are closely aligned with the necessary software operations.

Workflows might start life as a workaround for a missing feature only to be recognized later to be a versatile solution that does not require additional user affordance.

Workflows avoid the unfortunate, inscrutable and wholly unintended feature interactions common in designed systems.

See Familiar Workflows for some specific cases.

# Features

Some workflows revolve around unfamiliar capabilities for managing or sharing our work.

We rely on domain names for identity and make subdomain creation automatic. We expect but do not require an author profile page for each new site.

We often make new pages as ghostly versions of their future selves that can be read, even borrowed from, but are not saved until forked.

We present useful versions of specific plugins as companions to the standard about pages. Recent Changes, Grep for Errors and Topo Map are useful versions of Activity, Grep and Map plugins.

We employ Template pages and Transport services to construct new pages with consistent format and organization structure.

# Limitations

We live within limitations, some enforced by browsers and others of our own choice, that preclude operations familiar to database driven sites.

We limit notifications to the discovery of twin pages in already known and visited sites. We can know what our friends are doing only if we go look. We offer affordances for observing but do not subject authors to spam.

We collect more history than might be desired especially when a page with many edits to large items becomes bulky. Clever refactoring and forks from history provide handy journal manipulations.

We live within the visibility constraints of firewalls but find use for carefully placed staging sites from which we can fork to public visibility pages once reviewed.

# Incompleteness

We do without some convenience features because we simply haven't made providing them a priority.

We have good support for comparing pages, often three, four or more pages, by scrolling each to align paragraphs that may have moved in different versions. But we don't yet red-green diff individual lines.

We learn strategies for opening and abandoning pages to the point that we don't miss the ability to close from the middle or otherwise rearrange the lineup.

We don't handle deleting pages except in the case of browser local storage where they can inescapably hide desired content. This requires retrieving the more empowered Local Changes variation of Recent Changes.