[Tagging] Proposal about suffixed tags has been approved

Hakuch hakuch at posteo.de
Thu Feb 25 21:01:48 UTC 2016


On 25.02.2016 01:37, moltonel 3x Combo wrote:

>> At least, you should have pointed out your decision before
>> you did the changes.
> 
> As far as I can tell, you're just as "guilty" of editing the wiki and
> emailing the list at the same time (modulo typing speed) as I am. Your
> approval of the proposal looked very strange to me, and had you
> mentioned it on the list before enacting it on the wiki I would have
> immediately commented on it. But such delays quickly get impractical,
> so the pragmatic decision (yours and mine) is to do both at the same
> time.

I already answered to this in the other thread. Just quick here: There
was no need for discussing again. There was a lot of discussion within
the proposal process. Everyone knew, that the vote will end on 8th of
feb and for 3 days nobody did care, until Kelerei closed the vote and I
did the post-vote cleanup.

Sorry, that you dont like the outcome of the vote, but there where more
than 4 weeks of discussion. You yesterday did the changes on your own.


> Firstly, there is a difference between documenting current practices
> and advising for one practice over another. I did my best to remain
> factual and to document but not advise, even if I secretly wish that
> we stoped using multiple schemes and converged on one that had less
> flaws than the others.
> 
> Secondly, while writing the MV page I did my best to summarize all the
> opinions of the recent threads (even some I didn't fully agree with),
> and my first email today was a way to ask people to join the
> discussion.

thats a problem of the wiki, that it is for doumenting as well as for
advising. Thats a big problem for all unexperienced mappers and results
in unsteady tagging. Thats why I ask you, to notice on the page that
there are different positions. You even should link to the proposal
because its also a document of the situation.

>>> As an aside, using a wiki proposal just to decide what should go in
>>> the wiki, rather than what should go in the db, is a strange thing.
>>
>> the wiki is the entrance to the database, better it should be. Mappers
>> who care for consistency check the wiki before they start just tagging
>> as they want to (and what looks nice on an arbitrary map).
> 
> We agree on that. But it seemed to me that there was a disconnect
> between the wiki edit proposal and your acceptance of existing data :
> 
>>> this proposal is about the wiki, that
>>> name_1 and alt_name_1 should not be suggested there for good tagging.
>>> Its not about the existing data in OSM.
> 
> If your proposal mentioned converting existing data as well as
> removing its mentions from the wiki, it would have been more coherent.
> Maybe I'm missreading things ?

It is hard enough to do small steps :) Right, it would have been more
coherent, but even much harder to get a workflow for this. Thats even
one of the problems of this name_1 tags, you dont know what the name is
meant for! So, how to retag the existing name_1 ? Very hard
That shows, why it was important for me to stop this behavior and
pushing people to use a uniform tagging scheme with semantic rich tags.

> It
> touched lots of topics, and some people probably got confused about
> the rather focused intent (I certainly did). For example there was
> strong consensus on the list against the behavior of the iD editor,
> even though this was a very tangential (dare I say unrelated ?) topic.

I can't take responsibility when people dont read what is written in the
proposal and what I said in the discussions again and again. I have got
a problem with this iD behavior, but I did never think that the proposal
will convince the developers of rethinking this feature. Thats why I
verbalized it very soft "to pave the way"

> I am sure this skewed the results (this seems to be the case at least
> for the votes of Meillo and geow, amonst the minority who commented).
> Perhaps they should have gone in the discussion page rather than in
> the proposal itself.
> 
> A smaller issue: I'm perfectly happy to advise against alt_name_1 (see
> the bottom of the MV page), but the proposal compounded name_1 with
> alt_name_1.
> 
> I wrote "when it became clear (?) that name_N had an important role to
> play" but I can see now that it wasn't clear for everybody. I won't
> reiterate why I think that name_N is *needed* (not just a nice
> option), but one just needs to look at the "Discussion about
> multivalued keys" thread to see that it isn't just my opinion. That
> thread started shortly after the thread about the actual proposal died
> down, and is IMHO part of the discussion about (against) the proposal.
> 
> Once you establish that foo_N is needed (and discuss the scheme in
> greater details), and you recognize that allowing name_N doesn't mean
> that you need to give up on alt_name, it follows that a proposal to
> remove name_N doesn't make much sense (any more than removing
> alt_name). That is what I mean when I say that the proposal was dead
> on arrival : I assumed from that point onward that it was logically
> going to be rejected. I was wrong, but I guess that other onlookers
> thought the same and didn't bother voting against the proposal.

however, you can start a discussion, draft a proposal, start a RFC,
start a voting. When you are successfull, you can change what has been
approved.

But not just because you dont like the outcome of another proposal,
thats the final point.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x3CBE432B.asc
Type: application/pgp-keys
Size: 3187 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20160225/216b8b9c/attachment.key>


More information about the Tagging mailing list