Proposal:Change vote counting rules

This page describes a historic artifact in the history of OpenStreetMap. It does not reflect the current situation, but instead documents the historical concepts, issues, or ideas.

---

make proposal voting outcome more logical
Proposal status:	Rejected (inactive)
Proposed by:	Mateusz Konieczny
Draft started:	2021-01-05
RFC start:	2021-01-05
Vote start:	2021-01-19
Vote end:	2021-02-02

Proposal

Threshold

Change the rule on what counts as successful vote from

"8 unanimous approval votes or at least 10 votes with more than 74 % approval"

to

"at least 8 approval votes and at least 75 % approval"

Threshold adjustment, vote requirement

Change

"but other factors may also be considered (such as whether a feature is already in use)."

to

"but other factors may also be considered (for example one person voting multiple times or votes from people who are not involved in OSM mapping at all must be ignored)."

(note content in footnote, it is also part of the proposal)

Add to Proposal process#Voting request

"Please use wiki account with the same name as account used for mapping.

If for some reason account names are different: please link them.

(1) Create or edit your OSM user page and mention your openstreetmap.org account

(2) Edit your user profile at openstreetmap.org that mentions name of the Wiki account"

Vacatio legis

This rules (if accepted) apply to votes started on 2021-02-10 or later

Cosmetic changes

Some additional cosmetic edits may be necessary such as adding new "Historic note" in Proposal_process#Approved.

Rationale

Curently 8 yes votes and 1 no vote results in a failed proposal, but 8 yes votes and 2 no votes results in accepted proposal.

This results in a situation where voting "no" causes an otherwise rejected proposal to pass, which is ridiculous.

Also, changing "more than 74% approval" to "at least 75% approval" has no significant change in what is necessary for a succesful vote, but makes it easier to explain. Now the rule of thumb "every no vote requires 3 yes votes to overcome it" would become strictly true.

The change to remove "existing use" from "other factors" removed a non-sensical example, as such rule is not actually applied. There has never been a case where the threshold to pass was applied differently on the basis of proposal importance or impact. And it is not needed since existing use is a factor already considered by the community during an RFC and vote. Thus, there is no need for an independent criterion regarding existing use.

Conversely, cheating in a vote, and the proposed rules for who is permitted to vote, provide a clear criterion for instances where a raw vote count should be ignored. While we assume good faith by the community, cheating has occurred in past votes, resulting in that vote result being invalidated. This change codifies this current practice of invalidating votes in cases where cheating is detected.

Adding Proposal process#Voting request is intended to make vote verification easier.

Examples

Under current rules:

• 26 yes votes and 9 no votes is 74.3% of support that is sufficient for proposal to pass
• 8 yes votes and 1 no votes is resulting in rejected proposal
• 8 yes votes and 2 no votes is resulting in accepted proposal (so additional "no" vote changed it from rejected to passing)
• 800 yes votes from 4 chan raid and 10 no votes is resulting in ignored proposal (we do not need rule to disqualify blatantly manipulated votes and we did it already)

Under proposed rules:

• 26 yes votes and 9 no votes is 74.3% of support that is rejecting proposal
• 8 yes votes and 1 no votes is resulting in accepted proposal
• 8 yes votes and 2 no votes is resulting in accepted proposal
• 800 yes votes from 4 chan raid and 10 no votes is resulting in ignored proposal, and we have rule confirming this action

Applies to

Proposal process

Impact

Vote counting rule has mostly cosmetic impact and changes some frustrating corner cases.

Adding "votes from people who are not involved in OSM at all may be ignored" part has a bigger impact

• Some people who voted (for example here) have accounts names not matching any username on openstreetmap.org and provide no mention of their account on user page and have no activity on Wiki. Such votes would become not counted.
• It creates a bit of busywork
  • It would require people with different usernames on Wiki and on their OSM account to edit userpage and mention their openstreetmap.org user name.
  • It would also require checking vote eligibility as part of vote counting.
• Clarifies that such votes are unwanted
• Makes vote manipulation a bit harder and easier to notice (if there is a pattern of votes from people who made single edit we will need to tweak this rules)
  • Obviously, it would not fully block possibility of vote manipulation - but at least it would explicitly note that such votes should be removed.
• There is a risk that more specific rules will increase number of people manipulating vote and arguing that technically rules were not violated

External discussions

• Talk:Proposal_process#illogical_result_with_8_yes_and_1_no_.3C.3E_8_yes_and_2_no (permalink)
• tagging mailing list post on 2021-01-05
• Statistics on past approved proposals
• Proposed features/Checkpoint for Tourism - 8 votes for, 1 against. Under current rules it would be rejected, with 1 more against making it passing.

See also

• Clarification of proposal process - explicit abstaining is not a vote (previous change of vote rules)

Comments

Please comment on the discussion page.

Voting

vote was terminated early, and ended with rejection of that proposal

• I approve this proposal. As described there are also negative (minor certain negatives and plausible negative) impacts, but overall it is improvement and benefits of change outweigh negatives --Mateusz Konieczny (talk) 08:39, 19 January 2021 (UTC)
• I oppose this proposal. I approve the "Threshold adjustment" but oppose to a new "vote requirement", osmf already has 2 of them and I see no benefit in not using one of them Marc marc (talk) 09:33, 19 January 2021 (UTC)

"osmf already has 2 of them" - which ones? First is probably days of mapping within last year (I thought about it, but it would make things even more time-consuming during vote counting - but may be worth doing if we notice many accounts with suspiciously low activity). Which one is second? Paid membership? Mateusz Konieczny (talk) 10:00, 19 January 2021 (UTC)

• I approve this proposal. --Dieterdreist (talk) 09:41, 19 January 2021 (UTC)
• I approve this proposal. --Westnordost (talk) 09:58, 19 January 2021 (UTC)
• I approve this proposal. --Alesarrett (talk) 12:01, 19 January 2021 (UTC)
• I oppose this proposal. I see nothing absurd in requiring a quorum of 10 people, or if you've nearly got enough then insisting it is unanimous (aka 8 votes for, 1 vote against). Calling 74% equal to 'three-quarters' is absurd, it is 75%-or-more. I agree that someone shouldn't cheat by multiple voting. I disagree strongly with any further disenfranchisement of 'no' voters. Any proposal should be so strong and popular that the threshold is purely academic. Jnicho02 (talk) 14:20, 19 January 2021 (UTC)

Absurd part is that currently "8 yes, 1 no" fails and "8 yes, 2 no" passes. "Calling 74% equal to 'three-quarters' is absurd" - where it is happening? Mateusz Konieczny (talk) 14:22, 19 January 2021 (UTC)

"8 yes, 1 no" == not enough people to decide, and "8 yes, 2 no" == enough people to decide. That's not absurd. Jnicho02 (talk) 16:44, 19 January 2021 (UTC)

"Absurd" is being able to make a proposal pass by voting against it. When it comes to voting systems, I'm a strong proponent of the participation criterion: that is, casting a vote should never cause the opposite of what you want to happen. --Carnildo (talk) 18:53, 19 January 2021 (UTC)

Thanks for showing how this problem is named! Mateusz Konieczny (talk) 22:28, 19 January 2021 (UTC)

• I approve this proposal. I think this proposal does not go far enough (8 votes is too low of a minimum threshold, I would rather see at least 10-12), however, since the proposed rules are a (slight) improvement over the existing requirements, it should be approved. I agree that sock-puppet votes should not be allowed and that voters should identify themselves by openstreetmap.org user accounts. These are basic and very reasonable ground rules that should have only minimal impact to the work associated with facilitating a proposal vote. --ZeLonewolf (talk) 15:45, 19 January 2021 (UTC)
• I approve this proposal. LeifRasmussen (talk) 15:55, 19 January 2021 (UTC)
• I approve this proposal. Would be nice if some examples of voting being manipulated were linked. Other than that I agree to these changes. --GoodClover (talk) 16:04, 19 January 2021 (UTC)

There was hilariously obvious case that was fortunately invalid for other reasons anyway. On the other hand Proposed features/Military bases has unexplained "no" vote that under proposed rules would be invalid due to no matching openstreetmap.org account and no info which account is used for mapping. Mateusz Konieczny (talk) 21:47, 19 January 2021 (UTC)

• I oppose this proposal. This proposal is actually three distinct changes: 1) changing the approval threshold, 2) adjusting the "other factors may also be considered" text, and 3) changing the voting eligibility requirements. These would be best discussed separately on their own merits, and changes to the eligibility rules should be described in the "Voting" section not in the "Post-vote" section as this proposal suggests. Also, GoodClover has a good point -- can we see an example of the problematic votes that this proposal is trying to address? --Jmapb (talk) 16:50, 19 January 2021 (UTC)
• I oppose this proposal. While I do think that the difference between "8 votes yes, 1 vote no", and "8 votes yes, 2 votes no" should be corrected, this proposal is actually three proposals in one. Each proposal should be voted on separately. --Kathleenlu (talk) 17:13, 19 January 2021 (UTC)
• I approve this proposal. --Riiga (talk) 17:16, 19 January 2021 (UTC)
• I approve this proposal. --Carnildo (talk) 18:53, 19 January 2021 (UTC)
• I oppose this proposal. I oppose this proposal that excludes non OSM editors who could offer valuable insight to how to tag objects. Glassman (talk) 20:25, 19 January 2021 (UTC)
• I approve this proposal. --Phidauex (talk) 20:39, 19 January 2021 (UTC)
• I have comments but abstain from voting on this proposal. At the moment undecided, I like the change in threshold - same could be achieved by Math.ceiling(), which was probably intended too, but perhaps not. The change makes that clear. Wondering how this affects the third option.--Hungerburg (talk) 23:09, 20 January 2021 (UTC)
• I approve this proposal. I'm in favour of all the proposed changes here: to make the success criterion simpler and more logical, and clarify the other aspects of voting. --Rjw62 (talk) 18:31, 24 January 2021 (UTC)

References