Proposal:Internal quality/old votes

Voting

Since the time period is very short, if great objection are raised I'll stop the voting process and modify the proposal You are not forced to agree on every key, you might vote yes and give the list of feature you don't like. So if at least one is voted on, we have something Sletuffe 22:12, 24 November 2008 (UTC)

• I approve this proposal. Since I have proposed it, yeah, I am ok with it. But I oppose for now on any =ignore values since they might me abused by users to just shut up the validators. Sletuffe 22:09, 24 November 2008 (UTC)
• I oppose this proposal. I am very much in favour of simple "validate" tag that says which tests should be ignored for this object. But your proposal is a totally confused mixture of meta information (no_sign, no_name=yes, no_name=ignore...). A tag named "validate" is there to say something to the validators ("please ignore this"), not to give additional information about the object ("validate:ref=no_sign"). This is not well thought out, or maybe it was a good idea at the beginning but has got out of control. Reduce it to "validate:...=no" (or =ignore) and I'll vote yes. --Frederik Ramm 03:18, 25 November 2008 (UTC)
• I oppose this proposal. It is not our job to instruct the validator, some simple information can be given with validate=*, but the rest is really up to the validator to do. Some false trues, true falses and false falses. Dropping down a ton of new tags will not serve other purposes than making editing of data here even more complex. OSM tagging need to be simple while including enough information to render all the necessary map datas. Besides, the validator might serve different purposes, in such case, adding even more tags? --Skippern 03:31, 25 November 2008 (UTC)

• Good remark, validate:ref=no is not coherent to validate:no_name=yes, I change that Sletuffe 09:54, 25 November 2008 (UTC)

• I am undecided about this proposal. I can see there are cases where such tags may be useful, but agree with Frederik that validate:<test-name> seems a much more logical way to go. Perhaps a better proposal would be to adopt a common set of test names across the different validation tools? EdLoach 08:11, 25 November 2008 (UTC)

• That's exactly what we are trying to do here, but we need to agree on the minimum set of tags that we need, so you should give the list of tags you agree with, and refute others for witch you don't. Sletuffe 12:13, 25 November 2008 (UTC)

• I oppose this proposal. no_sign etc is actually information about the feature, not validation, and some of the others are of questionable motive too. I'm also not convinced any more we need to tell the validators anything; so they show false failures -- it isn't that critical -- they were only ever indications to aid mapping, not an aim in themselves. Randomjunk 09:39, 25 November 2008 (UTC)
• I oppose this proposal. I don't like any of the '=ignore' values, which can be used to supress all errors about a feature. I think it would get overused by people just to make an area report no errors. Rorym
• I oppose this proposal. Tagging for validators is directly equivalent to tagging for renderers. Either something a validator highlights is a genuine problem that needs to be fixed, not ignored, or it's a shortcoming in the validator which needs solving at source, not in the data. The output of tools like the noname layer is just guidance, not instruction, and we solve that problem through education, not hacking the database about just so an area is free of red marks in one particular tool. Jono 12:32, 25 November 2008 (UTC)
• I have comments but abstain from voting on this proposal. - since when did application-specific tags require voting. Just implement them anyway and document it in the validator's docs! --Thomas Wood 17:48, 25 November 2008 (UTC)

That's what I've done, but an approved tag after discussion have better chance to be better and used by other tools if voted, don't you think so ? (I've already modified 4 things so it became a little better ) And since people don't give help until there is a vote to have fun, that's how I did Sletuffe 18:23, 25 November 2008 (UTC)

• I approve this proposal. - I like the "sound" of 'validate:no_name=ignore' because when I read it (pretending that I don't really know about this proposal) then it suggests to me that 'no name' errors should be ignored by validators. I think it is important to move forward on this, because apart from lack of names, I also see duplication issues that seem impossible to solve. However, I think these tags shouldn't get more semantics than can be used by validators. And at this point that is a simple binary condition. --Phicoh 20:24, 29 November 2008 (UTC)

Looks like we have two approach here, wich confirm to me that validate:no_name=yes and validate:no_name=ignore are duplicates. We have around half people thinking the "ignore" syntax is best, while the other half think validate:no_name=yes is best. I am scared by the fact "ignore" might be abused just to shut up a validator (well, that's also true for yes). In the end it's rather just a question of words, and doesn't look like a big deal. But what I like in the "yes" approach, is that it says it has one information (that there is no name) while the other just focus on validators. The result in the end is just the same but the method for it seams more straight forward understanding it with "yes". Well, anyhow, I suggest we drop one for now. But I still like the no_sign stuff because it makes a rather interesting little variation that someone might be interested in. Let's put that back to RFC, yet another time for thinking and talking, not voting. Sletuffe 21:07, 29 November 2008 (UTC)

End of voting, that key is allready used by some validators, just check their docs

Let's go back to RFC on fewer keys, another voting might be needed later Sletuffe 21:09, 29 November 2008 (UTC)