Repository navigation
Feature request: "simple majority of cast votes" pass mode (more +1 than -1, excluding abstentions and non-voters) #707
Description
Add a pass mode where a vote passes when there are more binding votes in favor (+1) than against (-1), and where abstentions (eyes) and maintainers who did not vote are not counted at all.
Today the pass decision is a percentage of all allowed voters and never looks at the against count. Our governance requires the opposite: a plurality of the votes actually cast, ignoring everyone who abstained or stayed silent. We currently cannot express this with pass_threshold.
Current behavior
From src/results.rs, the result is computed as:
in_favor_percentage = in_favor / allowed_voters.len() * 100
passed = in_favor_percentage >= pass_thresholdThis means:
- The denominator is always the full set of
allowed_voters. Abstentions (eyes) and non-voters stay in the denominator and drag the percentage down — there is no way to exclude them. - The
againstcount is tracked (against_percentage) but never used in thepasseddecision. There is no "more in favor than against" comparison.
So a vote with 2 in favor, 0 against, 10 abstentions in a 12-maintainer team yields2 / 12 = 16.7 %, which fails at anypass_threshold >= 17. Loweringpass_thresholddoesn't help either, because a low threshold would also pass a vote with more-1than+1(e.g. 2 in favor, 10 against), sinceagainstis ignored.
Use case
The Hiero project (LF Decentralized Trust) uses GitVote for all asynchronous maintainer votes. Our governance defines the passing rule as follows (see roles/roles-and-groups.md, "Voting" section):
A vote passes when more maintainers have voted in favor (+1 / thumbs up in GitVote) than against (-1 / thumbs down in GitVote). Maintainers who abstain or do not vote are not counted. For example, 2 votes in favor and 0 against with 10 abstentions is a passing vote.
Abstaining is an explicit, first-class outcome in our process: maintainers are required to participate in a nomination but may effectively abstain by only posting a comment. Non-participation is a separate governance concern (inactivity), not a "no" vote. So neither abstentions nor non-voters may count toward or against the result.
We suspect this "plurality of participants" model is common in maintainer/promotion votes and would be useful beyond our project.
Proposed solution
Introduce an alternative pass mode, selectable per profile. For example:
profiles:
default:
duration: 5m
# Instead of pass_threshold, allow a mode that compares cast votes:
pass_mode: simple_majority # passes when in_favor > against; abstain & not_voted ignored
allowed_voters:
teams:
- project-maintainersBehavior of simple_majority:
passed = in_favor > against(binding votes only).- Abstentions and non-voters are excluded from the decision entirely.
- Optionally require at least one
+1(i.e. an empty vote with0in favor and0against does not pass).
Naming is of course up to you (pass_mode, or aquorum/majoritysub-section). The key point is a mode that (a) comparesin_favoragainstagainst, and (b) uses cast votes rather than the fullallowed_votersset as the basis.
Alternatives considered
- Low
pass_threshold: rejected — it ignoresagainstand would pass votes with more-1than+1. - Threshold as a % of all maintainers: changes the semantics (a fixed quorum of the whole team), and depends on team size; it does not match "more for than against, ignore abstentions".
- Custom GitHub Action counting reactions: works, but we'd rather keep using GitVote as the single, consistent voting tool across all Hiero projects.
Additional context
This would also make the existing "close on passing" / early-close logic more expressive for us, since our governance already allows closing a vote early once the outcome can no longer change (enough +1 that remaining votes can't flip it, or enough -1 that +1 > -1 is impossible).
Happy to help implement, test or review a PR for this issue.
Activity
tegioz commentedon Jul 16, 2026
Thanks @hendrikebbers, we'll look into it 👍
Related to #648
hendrikebbers commentedon Sep 23, 2026
@tegioz we (https://github.com/hiero-ledger) would be more than happy to help to get the feature in. If we know that it will be not an option for you we need to fork the tool.
tegioz commentedon Sep 23, 2026
Hi @hendrikebbers
We've plans to work on this soon (hopefully next week if everything goes well), we'll keep you posted 👍
If you prefer to fork it, that sounds great too, whatever works best for you 🙂
hendrikebbers commentedon Sep 24, 2026
@tegioz that is awesome :) Thank you so much. If you need any help or additional input (or a beta tester) just ping me
tegioz commentedon Sep 24, 2026
Will do, thanks!
tegioz commentedon Sep 29, 2026
Closed by #709
You can find more details about how it works in the reference config file. It'd be great if you could give it a try when you have a chance @hendrikebbers 🙂
gitvote/docs/config/.gitvote.yml
Lines 91 to 134 in caf54d3
hendrikebbers commentedon Oct 6, 2026
@tegioz thank you. we will test it out