On 25/02/2016, Hakuch <hak...@posteo.de> wrote: >>> That is absoulutely no justification for your edits without asking the >>> the list. >> >> I honestly believe I acted in the same way that you did (no accusation >> of wrong-doing). > > sorry but that is is really far from truth. Before I did the changes, > there was more than a month full of drafting a Proposal -> starting a > RFC -> Voting. In the end of that process, we had a decision by voting > 38:10. > > You cant compare this with you actions yesterday. You just ignored the > proposal process and reverted the result just because you don't like the > outcome.
The moral ground I'm standing on is that I was correcting the erroneous conclusion that there was enough consensus to accept the proposal. I know this looks like I'm pushing my singular viewpoint against the community's, but there are a few points which should make the current "official conclusion" feel uncomfortable, whatever your personal preference on semicolon vs suffixes is. In OSM we have to walk a difficult path between making the data consumable without too many headaches and describing a complicated world. Mappers have a lot of freedom and different solutions emerge. For some choices, like jewellery vs jewelry, there's no value in keeping both solutions so an expeditious decision is warranted. For other choices like suffix vs semicolons, the list of pros and cons prevents a clear winner from emerging. Luckily, both solutions can coexist and there is no need to choose a winner. Actually, if a winner is to be found, the community as a whole is certainly a better judge than the tiny fraction of the community that we ([tagging] readers and wiki editors) represent. Given both options, the community should naturally (if slowly) converge to the supperior solution if it exists. In a case like this, we'd need very strong arguments to say that a specific popular solution should not be used... ...But those strong arguments were clearly lacking: * Of the [tagging] participants who tackled the "semicolon vs suffix" question directly (so not counting peripheral topics like the iD bug, blanks and orderings, or comparison to lanes/opening_hours), many (dare I say most ? in any case more than 20%) participants leaned towards using the key rather than the value to encode multiple values. * Various issues with semicolons that some consider show-stopers (like litteral semicolons, or the 255 chars limit) were either ignored or brushed aside as not relevant. * The current usage statistics (hinting at the greater community's opinion) that name_N is 10 to 20 time more popular than semicolons [1], but this was again brushed aside (including the principle of documenting current usage). [1]: Using today's taginfo db dump: sqlite> select key,count(*),sum(count_all) from tags where key = 'name_1' or key='name_2' or (value like '%;%' and (key='name' or key='alt_name')) group by 1; name_1|250686|810490 name_2|29521|65868 name|15211|29136 alt_name|7975|10897 You can argue about the flaws of this simplistic query, but this won't change the general result. On 25/02/2016, Hakuch <hak...@posteo.de> wrote: > On 25.02.2016 01:37, moltonel 3x Combo wrote: >> 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. That's fair enough, any mention of the suffix and semicolon schemes (for the name key as well as other keys) should also link to the discussions, including the various proposals. I originally removed the link to the "remove sufixed name-tags" proposal because it is IMHO wrongly-accepted and because I was linking to the more factual "MV tagging" page, but I'm happy to add links to the proposals and discussions, as long as it is balanced. >> 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. The proposal could simply have said that name_N should be phased out, without planning the process. Without that, the proposal is just about the wiki and not about the db, which is a bad idea. Without that, all you can change in the wiki is remove mentions of name_N, but not say that it is deprecated. > 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. That's a strawman argument, you're talking about very different issues here. According to your proposal, one would simply replace "name=foo name_1=bar name_2=baz" with "name=foo;bar;baz" (or as some would have it, "name=foo alt_name=bar;baz", whose proponents implicitly agree that semicolons in 'name' are problematic, but then happily put a semicolon in 'alt_name' where it magically isn't a problem anymore :p). The fact that we don't know wether the extra name is an old_name or a loc_name or something else is independant of how the extra name was taged. The information is equally lacking from name_1, name=x;y, and alt_name. Do not shoot the name_1 messenger when it is just telling you that the mapper didn't have nuanced information about which context the extra name fits best in. I didn't see anybody arguing against prefering semantically-rich *_name tags when possible. The disagreement was about how to tag when all else fails and we have multiple values for a single *name slot. > 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" You don't have to take responsibility for other people's misreadings, but knowing about them should prompt you to take votes with a grain of salt, instead of taking the tally at face value just because you like the outcome. If you want to take responsibility for something, how about the superbly-onesided "Some points that came up in discussion" section ? > 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. Discussing is what I've been doing all along (yes, the wiki changes were just the continuation of discussion that I thought had ended). But it's been draining, so I'd rather go back to actual maping and coding for a while. If I come up with a perfect solution to the MV problem, I'll make sure to share it. Until then, I'll only wake up when somebody proposes again to get rid of a de-facto scheme despite it being more frequently used and having less technical issues. _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
