[Tagging] Feature Proposal - RFC - Gender

[Mateusz Konieczny]

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 illiamarchenko92 at gmail.com:

> Thanks for feedback! 
>
> Marc_marc <> marc_marc at mailo.com> >:
>
>> 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. 
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20221219/b85b4753/attachment.htm>