If we have inconsistent tagging of unisex=yes and it is unclear which is its meaning then passing proposal does not really solve it
unisex=yes data will still have the same problem in case of such damaged tag[1] it would be better to introduce a new one (though if vast majority is using this tag in this way and it merely reaffirms it then it is fine, but https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Gender#Rationale does not read this way) [1] https://en.wikipedia.org/wiki/Skunked_term 17 gru 2022, 23:16 od [email protected]: > Thanks for feedback! > > Marc_marc <> [email protected]> >: > >> Le 17.12.22 à 21:58, Illia Marchenko a écrit : >> > Gender proposal is ready for voting. After the previous vote, this >> > proposal has been reworked. I plan to start voting in a few days. >> > >> >> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Gender>> >> <>> >> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Gender>> > >> >> Isn't it good practice to have an RFC after the last change >> (i.e. today) ? >> > > >> >> > RFC isn't voting. > > >> Always pushing to go faster only leads to no votes and starting over- >> in skimming the proposal, i didn't understand how redefining the meaning >> of 3 tags will remove the ambiguity of one of the (unisex=yes) >> > > >> >> > This proposal isn't limited to clarification of the unisex=yes. > > >> Don't expect all contributors to read the counter-intuitive explanations >> you offer. >> a =segrated =not-segrated value would be much more intuitive >> > > >> >> > I added female=separate and male=separate to the proposal. > >
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
