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, Wikidata property proposals, Articles for deletion, "Did you know?" nominations, Non-free content reviews, Semi-protected edit requests, 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 has been conducted (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 items (data elements, actions and options). Using a form design metaphor, users can define the information captured, the automatic actions to perform (based on the former data) and the options to provide the users. For example, at the start stage we can ask users for an article (data element) and tag it automatically (action); at the "replies" stage a given set of tags to vote "yes" or "no" can be provided (options). The initial items represent a regular flow conversation (title and message to start a conversation, messages to reply, and marking as "resolved" to close the process), and it can be extended with more complex elements to support more advanced workflows as needed.
- Edit and display states. Each item (e.g., an article input field) has two states. The display state represents the element to communicate what it is (closer to what it will be displayed to the end user). The edit state shows all the information needed to configure that component.
- 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.
Prototype
You can view a video that illustrate some of the above ideas. The prototype used is also available, but only supports the specific interactions shown in the video.
- Initially the process structure is the same of a regular flow conversation:
- After adding several components a more specific on-wiki process is described:
Open questions
At the moment the main goal is to validate whether (a) the general approach would be able to capture the needed workflows and (b) it will be easy to use for users that want to create new workflows.
There have been raised other questions worth exploring in the near future:
- ""Specific items to support.** In the example above you can see that at each stage users can add different kinds of items (page input fields, sets of tags, etc.). Those are based on the initial exploration of workflows, but more thought is required to identify each item and its intended behaviour base on the needs of existing workflows.
- Properties to support for specific items. In the proposed model, items keep a minimal set of information when edited (e.g., type of item and label/placeholder to determine how to display it), but more advanced properties will be needed for different cases. For example, we may want to provide certain actions only for users with a given role (e.g., to limit who can actually trigger the deletion of a page) or a given period of time. Once those properties are identified they can provided as part of the editing view for each component.
- Entry points for workflow creation. In the model above the workflow creation process is presented as a way to customise the future conversations of the board. However, a centralised place where all workflows can be useful to keep them in control, especially if it is possible to be shared across processes.
- Extensibility mechanism. The above model defines several pieces that can be extended (e.g., new data elements, actions and options), but the way to do so has not been defined yet: where and how are these new components created.
- Sharing conversation patterns across several workflows. A generic pattern such as "voting" can be useful to different workflows. Reusing them make sense, but there are many details to figure out:how to avoid changes on a pattern to affect other workflows using it, how to base one pattern on a previous one without being linked, etc.
