Richard, thanks for the link and your analysis. Eric Raymond once said that "Every good work of software starts by scratching a developer's personal itch." Judging by how many different individuals have created various challenges and fixers, there is clearly a big irritation - highly messy, unclean data. A corollary is that the existing tools do not address the entire scope of the problem, thus new tools keep being created. BTW, thanks for listing a few tools I haven't heard about.
A number of people here feel that we cannot trust our users to be diligent. While I don't like stigmatizing it in such way, some people some times do make bad edits. The fundamental question we should keep in mind is: "does the benefit outweighs the risk". Or more precisely - which approach produces better result. If we do nothing, the data becomes less consistent, and sporadic unorganized efforts may hinder more than help. If we do bot editing, corner cases and bugs may spoil valid data. If a challenge requires manual edit, we have a high risk of typos - people are not very good at performing the same edit over and over and not make mistakes. If we do distributed accept/reject, some people, in theory, may be tempted to be trigger happy. In each case, the balance is fairly hard to reach. In distributed editing, one way to solve the "auto-clicking" is to use "multi-reviewer" approach - require two people to agree on an edit before it happens. I can fairly easily add that capability. This way, an expert editor may use the tool for direct editing (power mode), but the published challenges will require two person agreement, unless the community decides that a specific query is acceptable with just one. I do not want to make that decision for each community, as different cases require different approaches. What do you think? Would that address the most pressing concern? On Mon, Oct 16, 2017 at 10:13 AM, Richard Fairhurst <rich...@systemed.net> wrote: > Yuri Astrakhan wrote: > > For example, RU community wants to convert amenity=sanatorium > > -> leisure=resort + resort=sanatorium. Clicking on a dot shows a > > popup with the suggested edit. If you think the edit is correct, simply > > click Save. > > I've been a bit loth to get involved with this one but I do share the > general worry. > > Editor authors have a general responsibility to encourage good editing > behaviour in their UI design. It isn't quite as simple as "every tool can > be > used for good and bad things": the developer should design the tool to > encourage the good and discourage (or prevent) the bad. The developers of > JOSM and, particularly, iD have long been exemplary in this regard. > > This new tool can certainly be used for good, and there are use cases for > which it is ideal, but it's also very easy to misuse. My biggest concern is > that since it's decoupled from an editing environment, the natural tendency > is just to click 'Change', 'Change', 'Change' rather than reviewing and > manually making the changes. (We've seen this behaviour in several > "challenges" in the past, such as the dupe nodes drive.) OSM is a > collection > of human knowledge; this workflow goes too far in removing the human from > the equation. > > As an alternative, could I encourage you to look at something tentative I > did the other year for that relic of an editor, Potlatch 2? > > https://www.openstreetmap.org/user/Richard/diary/28267 > > This allows a user to navigate instantly between instances of a "challenge" > within the editor, while benefiting from an external data source to define > that challenge. The P2 implementation is fairly simple (there's no > "Resolved" button to feed back to that external source, for example) but > demonstrates the concept. > > If you were to build something along these lines into JOSM or iD, following > the traditional MapRoulette-like approach of asking users to make the > change > rather than automating it, I think you'd get the benefits you're seeking to > achieve without the potential damage. > > Richard > > > > -- > Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk