[OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

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 <richard at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20171016/cdb033db/attachment.html>