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

Warin 61sundowner at gmail.com
Wed Mar 18 22:39:34 UTC 2015


On 19/03/2015 8:57 AM, Christopher Hoess wrote:
>
> On Wed, Mar 18, 2015 at 9:14 AM, moltonel 3x Combo <moltonel at gmail.com 
> <mailto:moltonel at gmail.com>> wrote:
>
>     On 18/03/2015, Frederik Ramm <frederik at remote.org
>     <mailto: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 intentions.
>
> 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: 
> <https://lists.openstreetmap.org/pipermail/talk-us/2015-March/014445.html>) 
> 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?

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...

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.

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.


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


More information about the Tagging mailing list