User:Johan (WMF)/Suggested edits issues
Short report written for the Android team at the Wikimedia Foundation. Published here for transparency. This is from Johan (WMF), and doesn't represent anyone's interpretation and recommendations but his own personal ones.
Suggested edits is a tool to give new editors a way to start editing Wikimedia wikis in the Wikipedia app. In a world that has long been shifting towards mobile use, our assumption is that the survival of the wikis depend on us finding ways to engage mobile users. However, we also need to make sure we don’t create problems for the existing Wikimedia communities.
The main issues have been around two suggested edit functions: adding descriptions to Wikidata and depicts statements to Wikimedia Commons.
The latter issue was mainly due to the fact that computer-aided tagging led to very general statements, whereas the community consensus – a decision by the editorial staff, so to speak – favoured as specific statements as possible. As CAT has been turned off, that is not a major problem for now. The Wikidata issues remain largely unsolved.
Our general issues
- The tasks are simple to do but not necessarily simple to actually get right. There’s community consensus – editorial decisions – to follow certain guidelines. These are not obvious the same way as fixing a wrong date or a misspelling is.
- Suggested edits invite a large number of edits to wikis which are not easily patrolled. Wikimedia Commons and Wikidata are core projects that are important for the entire wiki ecosystem, but they have comparatively low number of patrollers per edit compared to e.g. many Wikipedias. By adding workflows that suggest newcomers add many edits in a short period of time, this means that unwanted edits are not found and reverted, or are found and reverted only at high cost in volunteer time.
- App editors are largely shut out from interacting with the community in ways that could efficiently teach them what to do.
What can we do?
Pay more attention to patrolling workflows. Will this put an additional burden on patrollers? If yes: What are we doing to also simplify patrolling and how could we contribute to this? Take patrolling capacity into consideration when deciding on which wikis to develop workflows for.
Work on integrating app editors with the rest of the Wikimedia community, or at least give them efficient feedback mechanisms.
Two particularly common things have been that Wikidata descriptions often – against guidelines – start with a capital letter, in writing systems that use those, and end with punctuation.
- An extra pop-up with the single focus on imprinting both these facts when the suggested edit feeds
- When someone adds a description with punctuation for the first time, warn them
- When someone starts a sentence with a capital letter, warn them this might not be the desired behaviour
As has been stated before we also need to, as soon as possible, find better ways to identify disruptive editing done in the app and disable suggested edits. Blocking someone should be a community decision, but if the edits are not productive, we should not encourage more of them at a high editing rate. Our thresholds for disabling the suggested edits feed – built on undos and rollbacks – do not work. This means that as the community is fixing the problems a well-meaning but largely destructive editor is causing, we keep inviting them to continue editing at high speed.
Later addendums, things that are important enough that they merit being mentioned here but weren't when this was published.
There's a Wikidata issue where descriptions are added in the wrong language, e.g. someone supposedly adding an Arabic description but the text is actually English.
It can be used to deliberately wreak havoc since the feed keeps giving new pages to edit.
The problem with patrolling Wikidata is its multilinguality. Patrollers can only efficiently patrol the languages they speak, which will always be a small minority.