Processes defined to coordinate many activities on a wiki rely heavily on conventions and huge instruction texts. More effective processes may facilitate and encourage user participation.
## User needs
After initial observations of processes such as [Featured article candidates](https://en.wikipedia.org/wiki/Wikipedia:Featured_article_candidates), [Wikidata property proposals](https://www.wikidata.org/wiki/Wikidata:Property_proposal), [Articles for deletion](https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Log/Today), ["Did you know?" nominations](https://en.wikipedia.org/wiki/Template_talk:Did_you_know), [Non-free content reviews](https://en.wikipedia.org/wiki/Wikipedia:Non-free_content_review), [Semi-protected edit requests](https://en.wikipedia.org/wiki/Category:Wikipedia_semi-protected_edit_requests), [Proposed mergers](https://en.wikipedia.org/wiki/Wikipedia:Proposed_mergers) and many others, these processes seem to have some patterns in common (e.g., discussion, consensus, action items, etc.) but they also respond to very different needs. Instead of trying to cover all those specific needs by supporting each process, the idea is to provide tools for the community to easily build support for these processes (and new ones that can appear in the future).
**Audience.** The audience for workflow support tools are advanced users which are familiar with the policies of the current wiki, but users of different levels of expertise may participate in the different processes.
User research is planned (T101331) to learn more about the diversity of the existing processes, and the problems users have supporting them.
##Design goals
The basic principles considered for the workflow system:
- **Simple.** Make it easy to define and participate in processes. Even if workflows are defined by advanced users, it should not require a PhD on workflow modelling to use the system.
- **Flexible.** Processes can vary in complexity (also over time) and the tools to support them should be able to make it possible to support the complex cases without adding an overhead to support the simple ones.
- **Extensible.** Since it is not realistic to anticipate al the specific needs, we need to provide extension points where the community can add their own pieces to the puzzle to better support the existing needs or solve new ones.
- **Efficient.** Most of the instructions and maul actions can be made part of the system. The goal is not to automate everything, but provide support to leave the decision making to humans and actions to machines as much as possible.
**Success metrics.** We expect to see the following impact:
- More participation. By reducing instructions and automating some rules, users will be more likely to participate in processes.
- More productive. With better support, users should be able to complete processes faster.
- More processes supported. By making processes easy to define, users will be more likely to provide support for some activities not considered before.
It would be great to instrument some of the existing processes to set a baseline to compare new solutions with.
##Design ideas
- **Structured conversations.** Workflows can be presented as structured conversations: instead of allowing users to post free text, a predefined structure (i.e., conversation pattern) is expected according to the process. For example, in an process to nominate a page for deletion, it is expected that users will provide the article they are nominating. Present workflows as structured conversations allow to simplify conceptually the transition between regular conversations to workflows.
-- Reusable. These structures can be very specific, but they can also be generic. So it is useful to be able to reuse them for different processes. For example, a process can start with a generic "voting" pattern before a more specific "Nominate feature article" pattern is created.
- **Three main stages: start, replies, and completion.** These seem common areas to structure: the initial message that starts the process, the replies that allow the community to participate, and the final resolution of the process.
- **Customisation based on adding data elements and actions.** Using a form design metaphor, users can define the information captured, automatic actions to perform (based on the former data) and options to provide the users. For example, we can customise the process initial message to ask for an article (data element users will provide when starting a new workflow) and add a template to it (which will happen automatically once the user sends the initial message). We can also indicate that wen users reply to the initial message, they are given a set of tags to vote "yes" or "no".
-- Extensible. Although we can provide an initial set of elements, there should be a way for users to extend them: develop new components, and/or have generic scriptable components (e.g., create an action based on a Lua script)
- Preview to test a workflow. Workflow definition happens at one step of abstraction higher than workflow execution. To make sure that descriptions work as intended, some mechanism for testing them is needed. The testing environment should allow to simulate the use of real data, different users and highlight the invisible effects (e.g., article X is deleted) but do not have real effect on data.
You can [[ https://youtu.be/8raZHiyXu60 | view a video that illustrate some of the above ideas ]]. [The prototype used](http://pauginer.github.io/prototypes/flow/workflows/recipe/index.html) is also available, but only supports the specific interactions shown in the video.