If we are not happy with the current system that disregards voting power and simply states for preferences on options - then yes we can change it . Actually this is an important part of governance - to change the rules if we are unhappy with them.
And Actually we don't have to design our own system. ASF has us covered.Voting types are a very well researched subject and there are multiple voting systems we can choose from see "Electoral systems": [1] - each of them with different properties. There were plenty of similar discussions in the past in either ASF or ASF project that went the same way - not happy with simple system, implementing more complex one that had different "fairness" properties - and well we can pick one for multi-voting options if we want, I would not encourage us figuring out our own "approach" but simply pick from existing ones. ASF has a project called Apache Steve [2] that implements multiple voting methods that ASF recommends. You can read about those methods at STeVe page. We use it for board elections and we used it (and Single Transferable Vote [3] method) this year to select the new logo candidates. This is a "multi-winner" system - i.e. one that allows several winners. There is a single-winner variant of it - Instant Runoff Voting [4] that can be used instead - where you put your options in the sequence of preferences. Generally - the Single Transferable Vote is widely considered in ASF as the most "fair" and we use it for almost everything where multiple options are possible. Note that we do not have to use it of course (though we could ask infra to set it up for us) - this system is designed in the way that people have one-time ballots and that the voting is anonymous and can't be really traced to a person - and I think we are nowhere near that expectation. But we can use one of the methods it implements. In simple voting like ours, it would be rather easy to implement it manually in an shared spreadsheet (or we can find a ready-solution that is less complex than STeVe) *My proposal is not to invent our own - but to use Instant Runoff Voting (as the variant of the Apache-recommended STV).* More details on the Instant Runoff voting: People instead of voting +1, 0, -1 simply order the votes in preference. Then one or more eliminations are used to simulate multiple runoff elections. In each round, the candidate with the fewest first-preference votes (among the remaining candidates) is eliminated. This continues until only one candidate is left. [1] Electoral system: https://en.wikipedia.org/wiki/Electoral_system [2] ASF Steve project: https://steve.apache.org/ [3] Single Transferable Vote https://en.wikipedia.org/wiki/Single_transferable_vote [4] Instant Runoff-voting https://en.wikipedia.org/wiki/Instant-runoff_voting J. On Thu, Oct 23, 2025 at 8:49 AM Amogh Desai <[email protected]> wrote: > I think I agree mostly with what Daniel says. > > We should arrive at a preference based voting to eliminate any sort of > voting power bias. > > I would second Daniel to have a rank based voting for ballots which can > have multiple choice: https://en.wikipedia.org/wiki/Instant-runoff_voting. > > The ad-hoc +/- voting has more problems than we can imagine, and those > can be solved by ranked ballots -- giving everyone equal power while also > being easy to explain and implement. > > Thanks & Regards, > Amogh Desai > > > On Thu, Oct 23, 2025 at 9:20 AM Kiruban Kamaraj <[email protected]> > wrote: > > > IMHO, if we don't let people vote -1, how are devs supposed to raise > > legitimate concerns about an option? If someone votes -1, they should > > explain why - and hopefully devs are only doing this when they have real > > concerns, not just to push their favorite choice. If you have a solid > > reason to oppose something, just vote -1. If you don't care about another > > option either way, then don't vote on it. > > > > I agree with what Jerek said. > > > > *it's not "who wins" but "which option wins". I don't absolutely care > who* > > *"wins" here, but which option has the most support.* > > > > On Thu, Oct 23, 2025 at 2:55 AM Daniel Standish via dev < > > [email protected]> wrote: > > > > > The DAG terminology vote I think has surfaced a problem with our > multiple > > > choice voting procedure. > > > > > > If you allow people to vote for multiple options, they seem to tend to > > use > > > it in a manner to signify their ranked preference. However, this could > > > easily result in an option that doesn't have majority preference > getting > > > the win. > > > > > > E.g. suppose 4 people vote for option A, and 5 people vote for option B > > +1 > > > but also +0.5 for A. Then option A will win even though people prefer > > > option B 5 to 4. > > > > > > This is a bad outcome. > > > > > > It gets even stranger if you allow negative votes. Then you end > > > essentially invalidating other peoples votes, unless *everyone* minuses > > all > > > of the options they don't favor. And even if everyone does that, then > > it's > > > hard to see how that gets to the outcome favored by most. > > > > > > With ranked choice voting, everyone votes for their most favored > choice, > > > but they can also rank all the options. If their most favored option > > does > > > not win, then their vote goes to their second favored option, and so > on. > > > > > > This is a better way to do this. > > > > > > I propose that when doing multiple choice votes, we do ranked choice, > > > instead of allowing people to just vote for multiple options with plus > or > > > minus votes. > > > > > >
