[Tagging] Proposal about suffixed tags has been approved

[moltonel 3x Combo]

On 24/02/2016, Hakuch <hakuch at posteo.de> wrote:
> On 24.02.2016 22:57, moltonel 3x Combo wrote:
>> The opinions were varied, but there was clear support in keeping the
>> name_N documentation, both for the basic principle of documenting
>> current practices, and because some contributors believe it is a
>> better way of tagging multiple-value fields. If anything, name_1 needs
>> to be kept because it is sometimes technically needed, even if it
>> isn't the prefered option. On top of that, this isn't an "either-or"
>> case where if we choose one scheme we need to deprecate the others.
>
> I really do not want to go again in this discussion, when you start this
> with just editing the wiki pages without asking on the list. But I also
> would like to know what means "technically needed"

When you have more than two names with the same semantic value, name_N
is the only way to tag this. alt_name can only contain one name,
semicolons are not a viable option for names.


>> I've reverted the deletion.
>
> that was against the decision of the proposal where everyone was able to
> take part.

And my reading of the situation is that there wasn't enough consensus
for the proposal, despite what the vote counts say. I suppose this is
the crux of this "appeal", and I discuss it further at the end of this
mail.


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


>>, which makes as little sense as deleting
>> the Semicolon page would.
>
> you can start a proposal if you want to delete the page

You missread me, I was comparing the deletion of the name_N scheme to
the deletion of the semicolon scheme. They both serve the same
purpose, but neither should get deprecated. Same goes for alt_name,
for that matter.


>> To make things a bit more constructive, I've
>> also created a page documenting MV tagging in general (trying to
>> gather all the points mentioned during last month's threads, sticking
>> to current practices, not advocating for one scheme over another) and
>> made other tweaks to the name pages. Feel free to discuss here or on
>> the wiki.
>
> As I told you in the message, I like the idea to have a special MV Page.
> But you shouldn't advise something there that has been discouraged by
> the proposal (you even removed the link to the proposal on the name
> page!) And the whole MV thing is still in discussion, you should inform
> about this on the page and call in the people to join the discussion
> with their ideas.

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.


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


>> By
>> the time you reduced the scope of your proposal from deprecating
>> name_N to merely un-documenting it, when it became clear (?) that
>> name_N had an important role to play, the proposal was IMHO dead on
>> arrival.
>
> I dont understand this. Do you mean the problem of the title "remove
> suffixed tags" ? Just to mention here again, the title was bad, yes. But
> I never changed the content of the proposal. Just people who didn't read
> carefully enough the content where misleaded by the title.

That is part of the problem with the proposal, and its votes. 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 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.