Great post, definitely highlights the core problem here: beyond rules and validation and so on, there's a social question and a question of onboarding.

I'm optimistic about comments on changesets. If they're friendly, then experienced users could, for instance, review some percentage of new edits and create & explain their corrections in the same sense as the editor of a book or how code reviews work in programming.

If some voluntary review process, like a checkbox to say "I'm not sure about this, can someone check my work", were technically feasible, it could be a good thing. I'm not sure that is technically feasible at the moment, because of the infrastructure required and the increased chance of conflicts. But, it would be a fun thing for someone with time and energy to experiment with.

But there are ten kinds of coffee in our cafes, which one should I tag?

Good question - this has already been addressed in the FAQ, but up for debate if someone sees a way to make it clearer:

Which coffee? This site tracks the price of house coffee for here. In many cases, that means a 12oz drip, but if all coffees are pour-overs or your country uses different standard size, the overriding rule is cheapest-here.

I'm interested in a clearer idea of what 'non-geographical' means in itself, separating the issue of 'it changes too often', or is it the same, and should just say the latter and not treat them as two issues. Shapes are obviously geographical, and classifications - amenity, highway, etc., are as well, but OSM has always stored much more than that, and much more than is represented on the map.

I think there is some 'geographical enough' criteria that's valid, but I'm drawing blanks on what it is and how we could explain it in some way other than the "know it when I see it" criteria.

It's my personal feeling is that things that are "on a map, factual, and current" should be welcome on OpenStreetMap but not necessarily endorsed or rendered.

Sanderd17 - good points about notation and Andy, thanks for the ISO link - I'll check that out and see if I can implement it in COFFEEDEX.

To be clear: we'd be happy to accept a pull request that adds support to iD, as stated in June of 2013. Nobody has stepped forward with code to do that, so it hasn't happened. Anyone who can write it and submit a pull request can make it happen today.

Java is a poor choice of basis - your contributor base is small and userbase has to deal with Java-isms. The 'multiple backends' concept makes performance and potential hard to pin down. The military-fund-for-open-source model of project management often produces incomprehensible software (see: GeoPackage). The GeoGit model is, like Git, more or less a glorified hash table whereas OSM is at its core not a list of features but a graph database, and the graph-ness of this graph database makes the idea of versioning it fundamentally different than a shapefile or PostGIS database. The lack of opinion in terms of datatype means that operations will be lossy and non-pure for quite a few datatypes, unless GeoGit's internal format is a superset of all geospatial data formats. And there's no real solid answer for how GeoGit will scale to OSM, even if the bottleneck of database throughput is removed.

That's not to say that I disagree with the intent - nearly everyone agrees with the intent, and wants something-of-this-sort.

We're also making strong use of Taginfo, which through its API can provide recommendations about related tags. This also provides an API for wiki-sourced documentation of tag combinations, including thumbnail images.

When we do implement presets, it's likely to be in a simple JSON format: XML parsing in Javascript is not very efficient or simple.