Workflow
|
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".
Image sources
- SVG Category
- Vote symbols
- Arrows
- Icons
- AIGA symbol signs
- Indication icons
- Crystal Clear icons
- Category:Mascots
- icons Category:Film icons
- Adobe Illustrator and other propriatary softare contain directories of symbols, but most likely under license.
Tasks and roles
The category articles contain information about the tasks and policies, and these can also evolve through discussion of the perceived problems and needs as they arise. They also contain links to other information frequently needed in that context. Categories must also be defined for the roles and the workflow categories are subcategories of the roles.
Migration
If we start organising our various development and work using common categories and conventions, then it can be migrated into the new interface more effectively. Also, since we are already teaching the wiki workflow principles independently of the project's education or XmlWiki, we should try and maintain a good clear working example of those methods ourselves.
- Organic Design Conventions has been started to help standardise various aspects of our content
We don't have Nodal Organisation in a functional state yet, but the current wiki paradigm uses categorisation very effectively as a means of workflow management. Here are some names of workflow categories from wikipedia to give some examples:
- Articles actively undergoing construction
- Articles copied to Wikibooks in need of cleanup
- Articles for speedy deletion
- Articles needing Chinese script
- Articles that are way too long
- Articles with confusing statements
- Articles with broken links
Obviously these are all oriented toward presentation and publication due to the nature of the Wikipedia project's work, but the general idea can apply easily to any manner of organisation. Its the general concept of creating an idea or collection of goals as an article and categorising it based on the roles and processes which are currently required to act on it. Each role which acts on it can then remove it from their category and add it to the next roles category who needs to work on it.
Its a lot like a Human-Tuple space where no communication is necessary between the processors of the work, and the items of work can be selected by roles randomly from the categories of work they feel like doing with no timing coordination needed.
