[OSM-talk] Newbie alert

Peter Wendorff wendorff at uni-paderborn.de
Wed Mar 19 18:22:05 UTC 2014


Am 19.03.2014 18:03, schrieb Bryce Nesbitt:
> On Thu, Mar 13, 2014 at 2:53 AM, SomeoneElse <lists at mail.atownsend.org.uk>wrote:
> 
>> Bryce Nesbitt wrote:
>>
>>> The "entry level editor" could reasonably limit new users to "entry level
>>> edits".
>>> Messing with anything with a relation is not a first edit kind of
>>> activity.
>>> What if the entry level editor said "hey, this is too complex, map
>>> something else
>>> and gain some experience and come back to this section".
>>>
>>> The barrier is still low.
>>>
>>
>> Saying "you can't update anything that involves a relation" rules out
>> rivers and streams (borders), roads (turn restrictions), and many types of
>> landuse and buildings (multipolygons).  I don't think that it's feasible.
> 
> 
> You've taken the proposal farther than I intended.
> Certainly adjusting the geometry of a boundary should be just fine for
> everyone.
> 
> ---
> Let's take "Stack Exchange", a Question & Answer site, as a possible model.
>  A new user can vote up *any* answer.  However, it requires a reputation
> level of something like 100 to vote *down* a question.   This reflects that
> voting down has some social cost, and it takes some time for new users to
> become familiar with the community norms.
> 
> ---
> For OpenStreetMap the moment a new user *deletes* a member of a border
> relation something might pop up:
> *Feature locked: this type of edit requires more editing experience. Please
> see here for details.*
Some remarks here:
1) it's not possible to pop up anything as the editor not necessarily
knows anything about the user at the time of the edit, this is known
only when uploading - and then it's too late. In contrast it's perfect
for a new user to change a local copy of osm, as long as it's not uploaded.
> 
> Not only have you prevented a messy deletion, you've given the new user
> something to strive for (unlocking the capability).
You have made some of the new users to leave as they don't want to edit
any relation, they wanted to fix the street - and they never cared about
the turn restriction, which shouldn't have been changed by their edit.
They wanted to fix the street, but didn't know or didn't want to do
anything with the bus route.

> I dispute that this is any sort of barrier to a new editor.  A new editor
> (particularly a non-geek editor) may well feel
> comforted that they are in an environment where the sharpest knives are
> locked away, at least until they are ready to use them.
> And you're teaching at a teachable moment.
If it were that easy I would agree. Unfortunately we don't have knives
and spoons in our toolbox, we have only a spoon, but the data we are
working on, the food we eat when editing the data, contains salad (ways
and nodes independent of relations) as well as chilli (the relations
with their content) and unfortunately cherries as well - where you don't
know if the stone is left inside or not. Newbies don't expect the stone
to be hidden in the cherry, the don't expect to break anything by only
changing a way; and it's hard to explain why some streets are allowed to
be edited and others are not. Why some buildings are allowed to add and
others are not (as they are part of an associated-street relation for
example).

> ---
> Another possible model is OK Cupid, where users must pass a short quiz to
> access features.  For OpenStreetMap that could mean a quick educational
> quiz on relations.  A user trying to make an edit that requires relation
> experience would be directed to the quiz.  The moment they answer the
> questions correctly their account is permanently unlocked with regard to
> relation editing.
> In this approach one quiz would handle all editing platforms, and the
> rejection of an edit would happen at the API level.  The editors would only
> need to format the API error message for viewing (perhaps with a i18n layer
> for translations).
Knowing about relations does not necessarily mean to know how to detect
them in any editor or how to prevent breaks inside - and the other way
around.

regards
Peter



More information about the talk mailing list