<p dir="ltr">Alright, I will give it a quick shot. <br>
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.<br>
Uh any preferences on the stack?  Rails,  chef, postgres, whatever else the main site tends to use? <br>
</p>
<div class="gmail_quote">On 07/11/2013 2:34 PM, "Jason Remillard" <<a href="mailto:remillard.jason@gmail.com">remillard.jason@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Daniel,<br>
<br>
I think it would be welcomed by everybody to put together some kind of<br>
software like this. If it is successful, eventually, bake it into the<br>
guidelines. Please push forward!<br>
<br>
However, my near term goal are<br>
  - reduce the number people who show up on the import list after the<br>
DWG has frozen the account, get hassled online, then give up on the<br>
import. I think it has happened at least 3 or 4 times this year.<br>
 - reduce the number of reverts the DWG needs to do.<br>
<br>
Anyway, I updated the wiki, being more explicit on what I believe our<br>
current process actually looks like.<br>
<br>
Could everybody look at it?<br>
<br>
Thanks<br>
Jason.<br>
<br>
<br>
<br>
<br>
On Wed, Nov 6, 2013 at 6:56 PM, Daniel O'Connor<br>
<<a href="mailto:daniel.oconnor@gmail.com">daniel.oconnor@gmail.com</a>> wrote:<br>
> Can I push a different approach, for the longer term?<br>
><br>
><br>
> I understand the problem we are trying to solve is preventing harmful<br>
> imports, so the map data is of high quality.<br>
><br>
> From an end user's perspective, that's completely understandable - often<br>
> what prompts the import is the belief there is missing content, I know how<br>
> to fix that, thus I can add to the quality of the map<br>
><br>
> Given most people who want to import content are highly aligned with the<br>
> goals, how can we make the guidelines clearer; and make it less upsetting<br>
> when a data import is rejected?<br>
><br>
><br>
> A second observation: when you have an open project, but try to control it<br>
> with a single point, you introduce a friction to everything. Suddenly, it<br>
> takes weeks as you go into a queue for your change to be noticed; and on the<br>
> other side of the fence a kind of wearyness can set in: oh, not other one of<br>
> these low quality things to deal with.<br>
> This is the exact sort of thing seen in PEAR's community<br>
> (<a href="http://pear.php.net/" target="_blank">http://pear.php.net/</a>); which is now effectively dead - rules designed to<br>
> help ended up hindering it, and other communities filled the ecological<br>
> niche it represented.<br>
><br>
> IMO; it's better to give people the best tools to promote quality rather<br>
> than add more manual checks and balances.<br>
><br>
><br>
> We have great validation tools built into JOSM, and things like<br>
> keepright/osm inspector, etc; but those catch problems after the fact right<br>
> now.<br>
><br>
><br>
> Third: We have a limited pool of resources. I think it's fair to say<br>
> everyone on this list is here to help and uplift a user to the point they<br>
> can import and know it's worthwhile, high quality, and overall positive.<br>
> It might be worth while introducing a prioritisation system.<br>
><br>
> <a href="https://github.com/gravitystorm/openstreetmap-carto/pulls" target="_blank">https://github.com/gravitystorm/openstreetmap-carto/pulls</a> is a good example<br>
> of the community, supported by a set of simple tools, that can review,<br>
> discuss and express either interest in a particular rendering change; or<br>
> make a polite case for why it shouldn't occur.<br>
><br>
> The basic criteria for an import queue management tool would be:<br>
> - There is a structured way to explain your changes, similar to the wiki<br>
> page template<br>
> - It's easy to have external people visibility vote or comment; and<br>
> understand the context of who they are.<br>
> - There's a clear go/no go decision point enabled by the tool. IE: You must<br>
> have at least N upvotes from this list / the DWG.<br>
> - The highest voted things go first, because they are the highest quality.<br>
><br>
> Surprisingly; our help system achieves a lot of this very well.<br>
><br>
> For example:<br>
> <a href="https://help.openstreetmap.org/questions/27844/put-in-an-unwanted-way-what-have-i-done" target="_blank">https://help.openstreetmap.org/questions/27844/put-in-an-unwanted-way-what-have-i-done</a><br>
><br>
> The user learnt, the community helped; and it's easy to understand the<br>
> context of who the people are (or, well, it would be if I clicked on their<br>
> name and got to their user page; and read something like<br>
> <a href="http://wiki.openstreetmap.org/wiki/User:Frederik_Ramm" target="_blank">http://wiki.openstreetmap.org/wiki/User:Frederik_Ramm</a>).<br>
><br>
> To me, it's a lot easier to be told "don't do that" if you realise the<br>
> person suggesting it to you is someone who builds the tools you use.<br>
><br>
> At the moment, when people are told "no", the reaction can be visceral:<br>
><br>
> - I followed all of the guidelines on your wiki! Mostly! Sorta! My heart was<br>
> in the right place!<br>
> - Who are you, anyway? You don't live near me or the area I'm mapping! You<br>
> don't know the problem I'm trying to fix!<br>
> - You are telling me off. What? I thought this was a big open project and<br>
> because I've got an edit button, that implies I have just as much 'right' to<br>
> do this as anyone!<br>
><br>
><br>
><br>
><br>
> I've done rudimentary mockups of a toolset that could achieve much of this:<br>
> <a href="https://docs.google.com/presentation/d/1VF-xtf_Iy-MrpegF5RPbnka6UeVD8RY43ezto8wbjwk/edit?usp=sharing" target="_blank">https://docs.google.com/presentation/d/1VF-xtf_Iy-MrpegF5RPbnka6UeVD8RY43ezto8wbjwk/edit?usp=sharing</a><br>

><br>
> ... which is very similar to the wiki process; but makes the "are you<br>
> approved to do this by the community" much more clear.<br>
><br>
><br>
> On Thu, Nov 7, 2013 at 3:30 AM, Christoph Hormann <<a href="mailto:chris_hormann@gmx.de">chris_hormann@gmx.de</a>><br>
> wrote:<br>
>><br>
>> On Wednesday 06 November 2013, Martin Koppenhoefer wrote:<br>
>> ><br>
>> > IMHO imports should only be done by longterm / experienced mappers,<br>
>> > because otherwise you get what we already have gotten from many<br>
>> > imports ;-)<br>
>><br>
>> But even if that was the intent making the instructions difficult to<br>
>> understand is not a reliable way to discurage inexperienced people due<br>
>> to Dunning-Kruger effect.<br>
>><br>
>> And despite bad imports happening i think there are many scenarios in<br>
>> which a complete newcomer could successfully do a valuable import<br>
>> (admittingly not every newcomer and not every kind of import of<br>
>> course) - with sufficient willingness to learn and sufficiently clear<br>
>> instructions for him/her to actually see what needs to be learned.<br>
>><br>
>> Without understandable instructions imports are essentially a<br>
>> hen-and-egg problem - you need experience to do an import and you can<br>
>> only acquire this experience by doing imports...<br>
>><br>
>> --<br>
>> Christoph Hormann<br>
>> <a href="http://www.imagico.de/" target="_blank">http://www.imagico.de/</a><br>
>><br>
>> _______________________________________________<br>
>> Imports mailing list<br>
>> <a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
>> <a href="https://lists.openstreetmap.org/listinfo/imports" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Imports mailing list<br>
> <a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/imports" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a><br>
><br>
</blockquote></div>