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.
0x3CBE432B.asc
Description: application/pgp-keys
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
