OpenStreetMap
Changing the proposal process from "For/Against" to "pick you preferred option"
Posted by aharvey on 12 October 2020 in English.I’m no expect in the tagging proposal process but I do think on a whole it’s helpful and a good thing to have in the OpenStreetMap community.
It provides the necessary documentation to both help mappers (to know what tag they should use to be consistent with everyone else) and data consumers (to know what each tag is so they can decide how to interpret it).
The process of putting together this documentation and asking for feedback is great because it ensures that a wide range of people from different backgrounds and perspectives can raise suggestions or issues.
However one aspect of the proposal process I’m convinced should be changed, as it stands the proposal goes to a vote and needs over 74% majority to pass. While on the surface it sounds good that a significant opposition can block it, in practice it can leave the mappers and data consumers with no way to map something. If the proposal is changed to make the 26% opposition happy, then the 74% of supporters don’t swap over in enough numbers to the other side then nothing would ever pass.
The proposal process instead should be changed to something with the high level like “We need a way to map X”, anyone can propose an option, eg.
“X is mapped like A.” “X is mapped like B.” “X is mapped like C” etc.
Anyone could propose how they feel is best to map X, and when it goes to a vote you have to choose one of the options, and the one with the majority wins.
We shouldn’t be in a situation where there is no approved way to map a mapable feature just because the community doesn’t agree completely on how to map it.
Discussion
Comment from Fizzie41 on 12 October 2020 at 22:46
What then happens when you have a 2 or 3 way tie, with the same number of votes for each option?
Comment from aharvey on 12 October 2020 at 22:53
Extend the vote period, ask for more people to vote? I’m not sure it does get tricky when there is almost equal split each way.
Comment from Sanderd17 on 13 October 2020 at 10:37
Hmm, I don’t like that way of voting.
Voting should be considered the last step, after the community is heard, and was able to give their comments, the resulting scheme should be put to a yes/no vote.
The problem with chosing between multiple choices is that very often, you’ll actually like multiple options, but also refuse to use a specific one.
Like if we would take address tagging to the vote today, I wouldn’t care if the tag is
addr:street,address:street,addr:streetnameor whatever version of that, but I would vote against using anAssociatedStreetrelation (based on the past experiences I had).However, if all those options are possible in a vote, it’s very likely many people will have similar strong feelings for or against relations. But the votes against relations would be divided over many different options making them less likely to win.
In the current way of accepting tags, it’s up to the one making the proposal to create a compromise that he believes will be accepted by a majority. The voting is only verifying whether his belief holds true.
Comment from Tordanik on 13 October 2020 at 18:14
Wiki voting isn’t the only way for a tagging idea to become established. There’s also the option of establishing a tag through usage in the database and applications.
As such, the wiki process as it stands isn’t designed to always produce a winner. The purpose of wiki voting is just to speed up the process for cases where a good solution is obvious.
In those clear-cut cases, it wouldn’t be worth it to wait for a de facto consensus to emerge, as that might mean a few years of ambiguity and slower progress. But when there is no clear best solution, there is some value in the slower approach of gaining mindshare among mappers and developers until the idea becomes established: It means that the tagging idea will actually have to prove itself to some extent. It may well turn out that none of the initial tagging suggestions was a good one because a proper solution requires, for example, better editors or improvements to the data model first, which cannot be brought about with voting alone.