I'd say we can strive for a single method of multi-choice. It seems - from the earlier discussion - that there are many properties of "simple" voting that make people worried. That's a valid worry - and if we already have a way (I assume we will use some very simple tooling) to do IRV - IRV voting is "way simpler" for the voting people. You do not have to think what +1, -1, 0 means - you do not have to worry about how your -1 will be perceived, the only thing you have to do is order the choices according to your preferences. Calculation is a bit more complex, but well, we have engineers and there are tools available - so I guess we can manage it.
I think also - if we agree to it upfront - it helps with just "following the book". The case we have with Dag naming - was a good example - in the middle of voting concerns were raised that things are unclear and that there are doubts about the way of voting. Could those concerns be raised before - surely, but they weren't and we had to start discussing mid-voting That has actually a socially-intimidating effect - it suggests (even if not intentionally) that the voting process was not well thought out and is not really good, and that we should have done better (even if we've "always done it this way"). I think if we leave the option of "simple voting" on the table, this might repeat the story - we might start voting and someone in the middle of it will start questioning the process. I strongly prefer that we set up the process - and even have an example voting done "well" - i.e. where we generally agree on the process and follow it and do not leave the option that one of us starts questioning it in the middle. No matter the intention - this is pretty disruptive. So I would strongly prefer to have just one way of voting on multiple options - and seems that we might even get a consensus on that (IRV) and simply call for LAZY CONSENSUS on using it in the future for all such votings. Also - I think it would be a good exercise to complete current Dag voting and re-assume it using the IRV method - while we are still focused on that subject - even if just out of curiosity what will be the difference in results. And that gives an opportunity to see if our new process works, get some tooling to do it and see if we all understand how it works. Also it might give those who see deficiencies in the current process to run them themselves and show how it should look like - with good communication of goals, options and process. It's always easier to say "I would like to change the process", but the real deal (and way better) is to "run it yourself" - to show how it should be done. That also shows real commitment to changing the process. J. On Fri, Oct 24, 2025 at 7:58 AM Amogh Desai <[email protected]> wrote: > Sounds like a good plan, Daniel. > > > Thanks & Regards, > Amogh Desai > > > On Thu, Oct 23, 2025 at 9:53 PM Daniel Standish via dev < > [email protected]> wrote: > > > Yes IRV is what I was referring to when I write ranked choice vote. If > > that's the approach that Apache favors / supports, then it sounds good to > > me. > > > > As I mentioned today in the other thread, I think it is generally better > if > > we can avoid multiple choice votes. But when it makes sense, then IRV > > seems right to me. > > > > I think it also could be reasonable to start out with an initial vote of > > just simple one option selection, i.e. non-transferrable vote and > majority > > wins. And then if it's close, anybody can request we do IRV. The reason > > for this is it might not be close enough to matter and it's simpler to > not > > do IRV. > > > > But I think we should not allow voting for multiple options because it's > > confusing, hard to reason about, and as mentioned in the original message > > of this thread, you may be unwittingly voting against your interest. > > > > > > So my proposal I think would be the following two provisions: > > > > 1. For multiple choice votes we have two options: > > a. simple majority vote, each voter gets one non-transferrable vote, and > > cannot select multiple options > > b. IRV > > > > 2. The person calling the vote can choose which voting approach to use. > If > > simple vote is chosen, any community member eligible to vote can request > > changing to IRV for any reason. > > > > > > > > > > On Thu, Oct 23, 2025 at 1:02 AM Jarek Potiuk <[email protected]> wrote: > > > > > > Oh absolutely - sorry I missed it :) > > > > > > Actually I started to do research and write my response before you > > > responded - so the issue is that I did not have a chance to read your > > > message :) ... Awfully sorry for that Amogh... Mental note to myself - > > good > > > thing to read the new answers before you press send on yours ;) > > > > > > On Thu, Oct 23, 2025 at 9:54 AM Jarek Potiuk <[email protected]> wrote: > > > > > > > > > > > > > > > On Thu, Oct 23, 2025 at 9:50 AM Amogh Desai <[email protected]> > > > wrote: > > > > > > > >> Yeah, I was proposing Instant Runoff earlier when I said this: > > > >> > > > >> > 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 > > > >> . > > > >> > > > > > > > > Oh absolutely - sorry I missed it :) - there were too many emails in > > the > > > > thread to read this morning and I simply missed yours, sorry Amogh. > > And I > > > > picked my proposal even without realising you had the same proposal - > > > > which might mean it is a really good idea :) > > > > > > > > And one more comment: > > > > > > > > > I don’t necessarily think this is a bad outcome. Those 5 people > also > > > > believe A is a good idea, just not as good as B. > > > > > > > > Yes. I agree with Wei Lee here. It's not a bad outcome. It's SOME > > > outcome. > > > > It has some properties (and also some social aspects to it - like > > people > > > > are less likely to put -1 even if they do not agree with something > and > > > few > > > > other things. Again - it disregards individual voting power of a > single > > > > person (if the voting power is something we seek as desired > property), > > it > > > > focuses more on the single option support, not whether one person has > > > > always the same "strength" of their vote. It assumes that we have > > > > collaborating people who will not seek to 'play" the system but > simply > > > > state their preferences. It's not tamper-proof and if we have bad > > > players, > > > > they can definitely abuse it. > > > > > > > > So yes - if we are at the stage where we are concerned about bad > actors > > > > trying to play the system to their advantage, then yes, we should > > choose > > > a > > > > system that is tamper proof. To be honest that never occured to me in > > the > > > > past that we are at this stage, but it's a good idea anyway. > > > > > > > > > >
