[Imports] edit import guideline wiki page

Daniel O'Connor daniel.oconnor at gmail.com
Thu Nov 7 08:52:36 UTC 2013


Alright, I will give it a quick shot.
Right now it's likely to just be a minimal wrapper around a stack overflow
clone or similar; plus static pages to understand the problem space
better/quickly iterate through the essentials.
Uh any preferences on the stack?  Rails,  chef, postgres, whatever else the
main site tends to use?
 On 07/11/2013 2:34 PM, "Jason Remillard" <remillard.jason at gmail.com> wrote:

> 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?
>
> Thanks
> Jason.
>
>
>
>
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20131107/80ca0725/attachment-0001.html>


More information about the Imports mailing list