<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 19/03/2015 8:57 AM, Christopher
Hoess wrote:<br>
</div>
<blockquote
cite="mid:CAHkn4E-_GY9xmFt+3+q5-eACGpXi4O6PBMMDx=ahfUeOD_p7FA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Mar 18, 2015 at 9:14 AM,
moltonel 3x Combo <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:moltonel@gmail.com"
target="_blank">moltonel@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On
18/03/2015, Frederik Ramm <<a moz-do-not-send="true"
href="mailto:frederik@remote.org">frederik@remote.org</a>>
wrote:<br>
> So please, don't go over board here by trying to
force-involve every<br>
> mapper in tag votes; they're simply not important
enough, and they<br>
> *should not be*. Don't try to make them important,
lasting, or binding.<br>
<br>
+1 to all that. While I think that "voting" is very
usefull, I think<br>
the whole concept of "accepting" a proposal (all the
related arguments<br>
about voter thresholds) should be scraped entirely.<br>
<br>
Instead, how about revisiting the purpose of proposals
pages vs key/tag pages :<br>
* key/tag pages would document the actual use (mainly
observed via taginfo)<br>
* proposal pages would document a desired use (and include
the current<br>
list of supporters/opponents)<br>
* ideally both pages would reference each other (many to
many), maybe<br>
using a "used/encouraged/discouraged by <link>"
template<br>
* key/tag pages could be kept up to date fairly
objectively<br>
* proposal voters should put the page on their watchlist,
in case a<br>
change in the proposal changes their opinion<br>
* proposals should only be "end-of-lifed" if there is
near-unanimous<br>
opposition and near-zero actual usage<br>
<br>
This should clarify the old question of whether the wiki
does/should<br>
document usage or intent. It'll allow competing proposals
to coexist<br>
more visibly. It keeps the interesting "opinion poll" use
of voting,<br>
while removing the obnoxious "proposal is ready ! vote now
so that we<br>
can start using it !" calls.<br>
<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Essentially, this serves two purposes:</div>
<div>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: <<a
moz-do-not-send="true"
href="https://lists.openstreetmap.org/pipermail/talk-us/2015-March/014445.html">https://lists.openstreetmap.org/pipermail/talk-us/2015-March/014445.html</a>>)
The protection of data becomes part of a reciprocal
contract: if you want your data protected, you need to
tell us what it means.</div>
<div>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.</div>
<div><br>
</div>
<div>OK, flame away! What don't you like?</div>
</div>
</div>
</div>
</blockquote>
<br>
I like the incentive to document the use .. as undocumented tags can
be removed .. maybe this could be automated <span
class="moz-smiley-s3"><span> ;-) </span></span> Say 6 months
of undocumented presence = automatic deletion. A warning meassage to
the user may provide documentation, ay after 3 months? Flames
here... <br>
<br>
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. <br>
<br>
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. <br>
<br>
<br>
</body>
</html>