[Tagging] Separating usage docs from design docs (was: Increasing voting participation)

Christopher Hoess cahoess at gmail.com
Wed Mar 18 21:57:24 UTC 2015

On Wed, Mar 18, 2015 at 9:14 AM, moltonel 3x Combo <moltonel at gmail.com>

> On 18/03/2015, Frederik Ramm <frederik at remote.org> wrote:
> > So please, don't go over board here by trying to force-involve every
> > mapper in tag votes; they're simply not important enough, and they
> > *should not be*. Don't try to make them important, lasting, or binding.
> +1 to all that. While I think that "voting" is very usefull, I think
> the whole concept of "accepting" a proposal (all the related arguments
> about voter thresholds) should be scraped entirely.
> Instead, how about revisiting the purpose of proposals pages vs key/tag
> pages :
> * key/tag pages would document the actual use (mainly observed via taginfo)
> * proposal pages would document a desired use (and include the current
> list of supporters/opponents)
> * ideally both pages would reference each other (many to many), maybe
> using a "used/encouraged/discouraged by <link>" template
> * key/tag pages could be kept up to date fairly objectively
> * proposal voters should put the page on their watchlist, in case a
> change in the proposal changes their opinion
> * proposals should only be "end-of-lifed" if there is near-unanimous
> opposition and near-zero actual usage
> This should clarify the old question of whether the wiki does/should
> document usage or intent. It'll allow competing proposals to coexist
> more visibly. It keeps the interesting "opinion poll" use of voting,
> while removing the obnoxious "proposal is ready ! vote now so that we
> can start using it !" calls.
That's an interesting idea, but I think it may be a little too heavy on
coexistence; I think we'd gradually accumulate a cloud of contradictory
proposals with no incentive to resolve them.

I have a "modest proposal" to make on the tagging/approval workflow. (For
readers not familiar with the idiom, it's a proposal put forward to spur
discussion rather than a serious policy recommendation.) I feel that many
people's reaction is going to be "No! That's ludicrous and against the
spirit of OSM!" but I'd like to hear *why* you think that.

Let's start with a few principles. Tags are here to convey information
about objects being mapped. Because we map a wide variety of features and
serve many different interests, the process of tag creation needs to be
fairly egalitarian. No matter how intelligent or well-meaning, a small
central board can't design all necessary tags from scratch (wisdom of
crowds, etc.) However, in order to serve their purpose of conveying
information, tags also need to be documented. If only one person
understands what a tag means, it really hasn't conveyed information.
They're weakly self-documenting, but the meaning of a given key-value pair
may be ambiguous or obscure; it's vastly preferable to have written
documentation in the wiki, in whatever language, to clarify the mapper's

Perhaps somewhat more controversially, while we want an egalitarian process
for tag creation, I would propose that we also want new tags to undergo
some form of peer review, if possible. Feedback from others can improve the
design of the original proposer.

So, my modest proposal: if you want to create a new key, add a new page to
the wiki. If you want to create a new value for a key, add it to the
existing page for the key. If someone sees that edit and wants to change
it, they can change it; if you object, the two of you can discuss it on the
talk page. Tags used in the database that are not documented in the wiki
(here comes the outrageous part!) are treated as provisional; they can be
added or removed at will, by any editor, mechanically or otherwise.

Essentially, this serves two purposes:
1) We have very strong social norms to avoid damaging other people's data.
However, these norms protect not only good data (where the meaning of the
data is shared and readily available) but data which is only understood by
the original mapper, if anyone (essentially, private mapping). (cf. this
recent message: <
The protection of data becomes part of a reciprocal contract: if you want
your data protected, you need to tell us what it means.
2) It leverages the rich toolset on wiki to let people keep track of how
tags are being expanded and redefined. MediaWiki has features like
Special:Newpages, watchlists, related changes, and so forth which would
make it easier to keep track of new ideas about tagging. It's much trickier
to do this if you have to monitor changesets on the map, even when
aggregated by tools of taginfo.

OK, flame away! What don't you like?

Chris Hoess
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150318/6d98bf4c/attachment-0001.html>

More information about the Tagging mailing list