Wikimedia Product/Contribution taxonomy

From February 2018, Abbey and James from the Wikimedia Foundation have been working to create a contribution taxonomy of the different ways that people contribute to Wikimedia wikis. Your input is welcome; updates will be made to this page.

Objective
To create a taxonomy/inventory of all the different forms of activity and workflow for editing and other contributions across a group of selected Wikipedias, assessed and prioritised in terms of where there are problem areas, especially for new editors or those on mobile, and what the Foundation's product teams might be able to do to support them, by June 2018.

For scope, we have selected to study the English, Hindi, Czech, and Korean Wikipedias; we expect to expand that by one more wiki in the next few days' consideration.

Rationale
Our wikis are nothing without their communities, and retention of new and existing editors alike has been a perennial challenge. There are a very large number of contribution tasks across our wikis, and they vary considerably in their approachability, scalability, and how much they contribute to editors' retention or burn-out.

Almost all tasks and workflows involve the platform maintained by the Foundation (edits, diffs, templates, categories, …); some tasks are supported directly with native tools maintained by the Foundation (the citoid service, the OTRS e-mail ticket system, the page views tool); some use near-native tools created and maintained by community members (gadgets and user scripts), or more full "second party" tools (RTRC, AWB, Twinkle, etc.); finally, some use "third party" tools (browser spell checkers, browser extensions like Grammarly, and so on). Some tasks require a lot of experience, domain knowledge, social capital within the community, having the right tools, or other key items.

On-boarding to these tasks can thus require these needs to be met, but without proper support editors can fail to get "in". Similarly once using the tools, editors can be frustrated by lack of workflow support and eventually leave. Understanding what we have is key to building better editing experiences.

Planned process

 * Phase 0 (February–March 2018)
 * For the "zeroth" phase, we will build the initial "master inventory" of contribution workflows. This will be based on prior studies related to editing, especially the New Editors research, as well as informed by our experiences and input from community members and stakeholders in the Foundation. We will document what instrumentation is available and pull in relevant usage patterns and levels where known.
 * We will determine an initial set of criteria by which to measure and compare different workflows, and share these with community members and other stakeholders.


 * Gate
 * At this point we will assess whether we have the right information to proceed with the work.


 * Phase 1 (April–May 2018)
 * For the next phase, we will combine the criteria with the inventory to assess the state of things, as well as the inputs to actions (like the tools and knowledge needed) for each step, the dependencies between them, and other relevant dimensions. It is likely we will adopt a visual system to document workflows, including primary and secondary workflows within task areas. We will prioritise the taxonomy, and iterate.


 * Gate
 * At this point we will assess whether we have the right information to proceed with the work.


 * Phase 2 (June 2018)
 * For the final phase, we will identify common patterns and clusters of workflow, prioritising potential interventions and highlighting gaps, issues, and areas of concern.

At this point, hand-off to product teams for action where they choose on the identified and prioritised gaps and issues.

Updates

 * 2018-02-07: Initial kick-off meeting.