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" <[email protected]> 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 > <[email protected]> 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 <[email protected]> > > 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 > >> [email protected] > >> https://lists.openstreetmap.org/listinfo/imports > > > > > > > > _______________________________________________ > > Imports mailing list > > [email protected] > > https://lists.openstreetmap.org/listinfo/imports > > >
_______________________________________________ Imports mailing list [email protected] https://lists.openstreetmap.org/listinfo/imports
