|<translate> This page is outdated, but if it were updated, it might still be useful. Please help by correcting, augmenting and revising the text into an up-to-date form.</translate>|
This is a draft. It's almost certainly wrong. Please be bold in making changes, or in suggesting changes on the talk pages if you don't feel like pulling out diagram tools.
This is written with an expected audience of the WMF Features Engineering Team and other Mediawiki developers. However, it might be useful to others as well.
So far, our approach to editor engagement has largely looked at Wikipedia from the perspective of the editor. This approach is useful, as it demonstrates usability issues, communication difficulties, and ways we could encourage both new and experienced editors.
However, when we attempt to make improvements, we often find that the Wikipedia community isn't happy with our designs. Sometimes, this is because we are failing to take into account all of the side-effects of our changes, and editors feel like they've been left out of the process.
These documents follow the lifecycle of each type of Wikipedia output. Instead of asking, "What challenges does an editor see?" we instead ask, "What are all the steps an article goes through?" This allows us to identify the points in the process that might be inadvertently effected by changes upstream in the process. It also helps us identify which parts of the community should be contacted for input on any given feature.
In the diagram linked here, the divisions are fairly high-level. They most closely follow the different working groups within the Wikimedia community, rather than the specific tasks these people undertake.
Broad categories of output
Broadly, these are the things we make:
There are likely more.
Here are some workflows that are worth diagramming, although they don't lead to specific outputs of content:
- Workflows, a hub for various semi-related links