This challenge focuses on reviewing daily batches of suspicious changesets flagged by a machine‑learning process. It is meant to support the community’s quality insurance efforts, not replace human validation.
The goal is to assess the changesets using available sources, history, and OSM Wiki guidance, and confirm or fix issues such as vandalism, harmful edits, or tagging mistakes (full details in the task instructions).
It aims not only to detect intentional harmful edits, but also to find accidental issues at an early stage. Since most OSM contributions are made in good faith, each case should be assess carefully, with respect for local knowledge and context.
Initial reviews show that roughly 60–65% of flagged edits are actually incorrect. Your input is therefore key to fixing real issues and helping refine the model, while keeping it aligned with OSM practices.
Note that tasks not reviewed within the day will be removed and handled by our team externally so the focus remains on fresh leads.
The three tasks I looked at all appeared to have a link to a changeset, but the link actually goes to https://maproulette.org/challenge/55814/task/{{changesetlink}, which would seem to be an error.
I’ve just looked at a couple. Both turned out to be first edits by brand new mappers. One looks 100% well-intentioned; the other one is 50/50. In both cases the appropriate response would be a polite “hello and welcome” message to the new mapper, followed by asking about the source of the data.
In neither case is it possible to “correct the edit” without a survey.
I can see the usefulness of this as a feed into e.g. Vespucci, so that “things that are a bit iffy” can be corrected on site. I’m less convinced of the benefits of Maproulette here; the “50/50” one I looked at was in Manchester and we know from previous experience that remote mappers cannot add value there.
Thanks for highlighting this. You’re absolutely right — reaching out with a friendly welcome is often the best first step for new mappers. We’ve updated the instructions to reflect this approach.
Fully agreed. It’s important to recognize that many of these cases require local validation rather than remote fixes. We’ve added a note in the instructions to highlight this. Your point about using these tasks as signals for potential on‑the‑ground follow‑up is especially valuable, and we’ll keep it in mind as we continue refining the approach.
For now, we encourage contributors to use the status “Can’t complete” in such situations.
Thanks to everyone who has taken a look at the challenge so far. If you’ve tried it, I’d really appreciate hearing your feedback— Was it useful? Were the tasks clear? Did you run into any issues or have suggestions for improvement?
Thanks for your inputs. We’ll closely analyze the false-positive cases to refine the model. In the meantime, if you noticed some recurring situations, it would be helpful if you could share details/examples.
