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

[Christopher Hoess]

On Wed, Mar 18, 2015 at 6:30 PM, moltonel 3x Combo <moltonel at gmail.com>
wrote:

> On 18/03/2015, Christopher Hoess <cahoess at gmail.com> wrote:
> > 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.
>
> Are you afraid of wiki bloat ? I don't think it'd be much of an issue.
> Proposals that fall into disuse will naturally lose their links from
> feature pages and disappear from public view. We already have a
> collection of old contradictory proposals that have never been
> officially rejected. It doesn't hurt much, they sometimes come up in a
> search, but since we probably  never want to fully delete them from
> the wiki anyway...


Well, we should encourage people to try to reconcile proposals and agree on
tagging schemes, although there will be some cases where we "agree to
disagree" and document that. How hard we push from that is largely a
question of procedure, I suppose.


>
> > 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.
>
> Tempting, but I don't think it'll fly, for a few reasons:
>  * We've got a huge backlog of frequently-used non-documented keys to
> work through :
> http://taginfo.osm.org/reports/frequently_used_keys_without_wiki_page


Yeah. We'd have to have a lengthy "amnesty" period (>= 1 year), with
targeted notifications, challenges to write documentation, etc., before
making a change in policy like this.


>
>  * For good or ill, a lot of contributors don't (want to) use the
> wiki. Turning it into a mandatory part of osm just won't work from a
> social point of view

 * You're raising the bar quite a bit for the creation of new tags,
> without even improving the quality of tags in the process.
>

Is that because using the wiki is intrinsically terribly hard (admittedly,
having unified login for the wiki and the database proper would be nice),
or is this a side effect of the fact that there's very little incentive to
use it? People (hopefully) use tags more than once: slapping down a
sentence or two in the wiki on the occasions you need to invent one doesn't
strike me as an extraordinarily high bar.

I don't think we can get everyone who needs a new tag to submit
high-quality, well-thought-out proposals from the beginning. But making
their ideas publicly visible via the wiki should get more feedback on the
tags and sooner. As it stands today, bad or incomprehensible tagging can
fly under the radar until it's so widespread it can't readily be corrected.


>  * Suggesting that it's ok to undo somebody's work because he didn't
> document it is a recipe for nasty conflicts.
>
>
See my caveats above & my reply to Warin: I wouldn't want to launch
search-and-destroy missions against undocumented tagging. But if there's
really a serious conflict over how to use certain tags, it's going to
manifest *somehow*. Because, under this proposal, documentation on-wiki
provides a positional advantage, I would expect these conflicts to flow
away from the database towards the wiki, which IMO is more transparent than
having them buried in map changesets.

It seems like the best way to get your way under the current system is not
to waste energy on the wiki and tag as energetically as possible according
to whatever scheme suits you. That's not entirely a bad thing--in the big
picture, adding to the map is what's important--but it's a recipe for
perpetual semantic confusion and ambiguity within the database.

-- 
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150319/a3509412/attachment.html>