[Imports] edit import guideline wiki page

Jason Remillard remillard.jason at gmail.com
Thu Nov 7 04:04:12 UTC 2013

Hi Daniel,

I think it would be welcomed by everybody to put together some kind of
software like this. If it is successful, eventually, bake it into the
guidelines. Please push forward!

However, my near term goal are
  - reduce the number people who show up on the import list after the
DWG has frozen the account, get hassled online, then give up on the
import. I think it has happened at least 3 or 4 times this year.
 - reduce the number of reverts the DWG needs to do.

Anyway, I updated the wiki, being more explicit on what I believe our
current process actually looks like.

Could everybody look at it?


On Wed, Nov 6, 2013 at 6:56 PM, Daniel O'Connor
<daniel.oconnor at gmail.com> wrote:
> Can I push a different approach, for the longer term?
> I understand the problem we are trying to solve is preventing harmful
> imports, so the map data is of high quality.
> From an end user's perspective, that's completely understandable - often
> what prompts the import is the belief there is missing content, I know how
> to fix that, thus I can add to the quality of the map
> Given most people who want to import content are highly aligned with the
> goals, how can we make the guidelines clearer; and make it less upsetting
> when a data import is rejected?
> A second observation: when you have an open project, but try to control it
> with a single point, you introduce a friction to everything. Suddenly, it
> takes weeks as you go into a queue for your change to be noticed; and on the
> other side of the fence a kind of wearyness can set in: oh, not other one of
> these low quality things to deal with.
> This is the exact sort of thing seen in PEAR's community
> (http://pear.php.net/); which is now effectively dead - rules designed to
> help ended up hindering it, and other communities filled the ecological
> niche it represented.
> IMO; it's better to give people the best tools to promote quality rather
> than add more manual checks and balances.
> We have great validation tools built into JOSM, and things like
> keepright/osm inspector, etc; but those catch problems after the fact right
> now.
> Third: We have a limited pool of resources. I think it's fair to say
> everyone on this list is here to help and uplift a user to the point they
> can import and know it's worthwhile, high quality, and overall positive.
> It might be worth while introducing a prioritisation system.
> https://github.com/gravitystorm/openstreetmap-carto/pulls is a good example
> of the community, supported by a set of simple tools, that can review,
> discuss and express either interest in a particular rendering change; or
> make a polite case for why it shouldn't occur.
> The basic criteria for an import queue management tool would be:
> - There is a structured way to explain your changes, similar to the wiki
> page template
> - It's easy to have external people visibility vote or comment; and
> understand the context of who they are.
> - There's a clear go/no go decision point enabled by the tool. IE: You must
> have at least N upvotes from this list / the DWG.
> - The highest voted things go first, because they are the highest quality.
> Surprisingly; our help system achieves a lot of this very well.
> For example:
> https://help.openstreetmap.org/questions/27844/put-in-an-unwanted-way-what-have-i-done
> The user learnt, the community helped; and it's easy to understand the
> context of who the people are (or, well, it would be if I clicked on their
> name and got to their user page; and read something like
> http://wiki.openstreetmap.org/wiki/User:Frederik_Ramm).
> To me, it's a lot easier to be told "don't do that" if you realise the
> person suggesting it to you is someone who builds the tools you use.
> At the moment, when people are told "no", the reaction can be visceral:
> - I followed all of the guidelines on your wiki! Mostly! Sorta! My heart was
> in the right place!
> - Who are you, anyway? You don't live near me or the area I'm mapping! You
> don't know the problem I'm trying to fix!
> - You are telling me off. What? I thought this was a big open project and
> because I've got an edit button, that implies I have just as much 'right' to
> do this as anyone!
> I've done rudimentary mockups of a toolset that could achieve much of this:
> https://docs.google.com/presentation/d/1VF-xtf_Iy-MrpegF5RPbnka6UeVD8RY43ezto8wbjwk/edit?usp=sharing
> ... which is very similar to the wiki process; but makes the "are you
> approved to do this by the community" much more clear.
> On Thu, Nov 7, 2013 at 3:30 AM, Christoph Hormann <chris_hormann at gmx.de>
> wrote:
>> On Wednesday 06 November 2013, Martin Koppenhoefer wrote:
>> >
>> > IMHO imports should only be done by longterm / experienced mappers,
>> > because otherwise you get what we already have gotten from many
>> > imports ;-)
>> But even if that was the intent making the instructions difficult to
>> understand is not a reliable way to discurage inexperienced people due
>> to Dunning-Kruger effect.
>> And despite bad imports happening i think there are many scenarios in
>> which a complete newcomer could successfully do a valuable import
>> (admittingly not every newcomer and not every kind of import of
>> course) - with sufficient willingness to learn and sufficiently clear
>> instructions for him/her to actually see what needs to be learned.
>> Without understandable instructions imports are essentially a
>> hen-and-egg problem - you need experience to do an import and you can
>> only acquire this experience by doing imports...
>> --
>> Christoph Hormann
>> http://www.imagico.de/
>> _______________________________________________
>> Imports mailing list
>> Imports at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports

More information about the Imports mailing list