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

Christopher Hoess cahoess at gmail.com
Thu Mar 19 00:15:00 UTC 2015

On Wed, Mar 18, 2015 at 6:39 PM, Warin <61sundowner at gmail.com> wrote:

> I like the incentive to document the use .. as undocumented tags can be
> removed .. maybe this could be automated  ;-)    Say 6 months of
> undocumented presence = automatic deletion. A warning meassage to the user
> may provide documentation, ay after 3 months? Flames here...

I think that's carrying it a bit far, and too close to the "central
planning model". I think it would be sufficient to think of undocumented
tags as resembling unsupported APIs: yes, you can use them, and they'll
probably work most of the time, but they could break or change without
warning. If we had a culture where properly documenting tags was the rule
rather than the exception, and we had worked through most of the huge
backlog of undocumented tags that now exist, *AND* we were happy with the
state of affairs, maybe we could think about purging in that way, but I
think that would be premature to consider.

> The 'peer review' I currently see as the comments/voting process. I think
> it does help with improving tags provided suggestions for improvements are
> made rather than demands, commands and derogatory comments. Offering a
> problem is only one side of the coin .. there needs to be a solution too. I
> try to provide both.

Good point. I don't have a concrete process suggestion, but maintaining a
collegial and constructive tone in discussions is important. A lot of what
people have been saying on this list about resolving votes, abstentions,
coming to consensus and so forth could be applied to on-wiki discussions of
proposed changes. My proposal was aimed more at the fact that there are
very few social incentives to use the wiki right now; the approval process
is a mess because it's only used by people willing to take a lot of time
and energy for little concrete gain.

> Adding new values should be the same process as adding a new key, maybe it
> can be shorter in time? Simply adding things to the wiki does not get the
> attention of people .. notifying the group gets attention that may lead to
> improvement. And puting things to the group before going to the wiki is
> better as basic ideas may be discussed rather than going into a full detail
> ... things like this discussion don't fit well on the wiki.

I think it's important that editing the wiki to incorporate a new key or
value be very easy to do, otherwise we start sliding back towards a
"central planning" model. 90% of the documentation will probably be of
interest only to a few mappers and won't get changed much after being
created. We want to let people do that and go map without trouble. However,
if you're changing something important or popular, it's probably best to
change the wiki and see what people say before you start adding it to the

Right now, we don't notice things on the wiki because we're socialized to
consider it unimportant. However, pages like <
http://wiki.openstreetmap.org/wiki/Special:NewPages>, maybe with a little
filtering, could easily be used to track new key creations; maybe a bot
could even monitor it and send a digest to a mailing list regularly.
Discussion could take place at the discussion/talk pages in the wiki: e.g.,
I could say at Talk:Railway "I think we should add new value xyz, this is
how it fits with the current scheme, what do you think?" If on-wiki
discussion was the norm, people interested in railroads would have that
page on their watchlist, they would see my change when I made it, and could
reply. Maybe we could also have a forum on-wiki where people could announce
"I have a new idea, comment on talk page ... if it interests you." I think
the talk pages work OK for that, but I admit that I have been brainwashed
by almost a decade of Wikipedia editing, maybe other people do not like to
discuss there.

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

More information about the Tagging mailing list