For handling ranked voting, I wonder if we could reuse Apache STeVe (Single Transferable Vote) which is used for the board elections.
On Thu, Jun 18, 2020 at 8:20 AM Michael Sokolov <msoko...@gmail.com> wrote: > Rank voting: we had a lengthy discussion about how to use this in my > book group, where we vote on which book to read. It turns out to be > hideously complex, depending on how you do it. We floated two systems. > In both, voters rank their choices from 1 to N. In one scoring system, > an item ranked with rank x gets score N - x + 1, and the scores are > tallied for each item, the item with the highest total score wins. > This system is pretty easy to score: we felt we could do it on a piece > of paper at the table in our group. We actually tried this, it was > kind of fun, but I think it led to the same outcome we would have had > from "normal" voting, in that instance. > > Voting theorists seem to prefer a system where a winning candidate is > chosen in multiple evaluation "rounds" by counting the top-ranking > votes for each voter, and if any item has a majority, it wins. > Otherwise, the bottom-scoring item is removed from the pool of > candidates, and its votes are redistributed by taking the next-ranking > item from each voter who had previously listed the now-removed item. > Or said another way, the whole process is repeated while skipping the > removed item. And then this goes on, removing losing items until some > item has a majority of top-ranked votes among the remaining tallies. > I guess that this has nicer game-theoretic properties than the simple > linear combination, but it is annoying to compute since it requires > maintaining every voter's distinct ranking. > > Perhaps there are other systems. We could use one logo 80% of the > time, and the other logo 20%? Or we could produce a Chimera? > > Ball's in your court Ryan, but I would be willing to bet that awarding > the winner to a plurality in a single round will get us the same > result as all this complication... > > On Thu, Jun 18, 2020 at 1:30 AM Ryan Ernst <r...@iernst.net> wrote: > > > > > IMHO this vote is invalid because... > > > it doesn’t include the red / orange variants submitted by Dustin Haver > > > > I considered the latest submission by Dustin Haver to be his submission, > but I can see how some might like the other better and it should have been > part of the vote. > > > > > I propose to restart the VOTE to include all submissions. > > > > Given that I omitted the submission above, that seems reasonable. And > since we are restarting, I guess we can allow Baris to add in an entry. > > > > Baris, please add your entry to the jira issue. I will restart the vote > next week. > > > > > If we're going to have more options, I suggest we use "ranked voting" > > > > I considered rank voting, but tallying a rank vote by hand can be > incredibly tedious. I don't think we should use any external tools since > that prohibits verification on who is voting from the PMC. However, given > the lastingness of this decision, I guess it is fair to do the necessary > harder tallying work of rank choice voting over email. When I restart the > vote, I will give instructions on making multiple selections. > > > > So, consider this vote CLOSED and VOID. > > > > > > > > On Wed, Jun 17, 2020 at 8:27 AM David Smiley <david.w.smi...@gmail.com> > wrote: > >> > >> If we're going to have more options, I suggest we use "ranked voting": > https://en.wikipedia.org/wiki/Ranked_voting > >> If you create a Google Form based submission which supports a ranked > choice input, then this should make it probably not hard to tally the > results correctly. A PMC boolean would be helpful too. > >> > >> ~ David > >> > >> > >> On Wed, Jun 17, 2020 at 11:14 AM Andrzej Białecki <a...@getopt.org> > wrote: > >>> > >>> IMHO this vote is invalid because it doesn’t include all submissions > linked to that issue. Specifically, it doesn’t include the red / orange > variants submitted by Dustin Haver (which I personally prefer over the > sickly green ones … ;) ) > >>> > >>> I propose to restart the VOTE to include all submissions. > >>> > >>> On 17 Jun 2020, at 17:04, Adrien Grand <jpou...@gmail.com> wrote: > >>> > >>> A. (PMC) I like that it retains the same idea as our current logo with > a more modern look. > >>> > >>> On Wed, Jun 17, 2020 at 4:58 PM Andi Vajda <o...@ovaltofu.org> wrote: > >>>> > >>>> > >>>> C. (current logo) > >>>> > >>>> Andi.. (pmc) > >>>> > >>>> On Jun 15, 2020, at 15:08, Ryan Ernst <r...@iernst.net> wrote: > >>>> > >>>> > >>>> Dear Lucene and Solr developers! > >>>> > >>>> In February a contest was started to design a new logo for Lucene > [1]. That contest concluded, and I am now (admittedly a little late!) > calling a vote. > >>>> > >>>> The entries are labeled as follows: > >>>> > >>>> A. Submitted by Dustin Haver [2] > >>>> > >>>> B. Submitted by Stamatis Zampetakis [3] Note that this has several > variants. Within the linked entry there are 7 patterns and 7 color > palettes. Any vote for B should contain the pattern number, like B1 or B3. > If a B variant wins, we will have a followup vote on the color palette. > >>>> > >>>> C. The current Lucene logo [4] > >>>> > >>>> Please vote for one of the three (or nine depending on your > perspective!) above choices. Note that anyone in the Lucene+Solr community > is invited to express their opinion, though only Lucene+Solr PMC cast > binding votes (indicate non-binding votes in your reply, please). This vote > will close one week from today, Mon, June 22, 2020. > >>>> > >>>> Thanks! > >>>> > >>>> [1] https://issues.apache.org/jira/browse/LUCENE-9221 > >>>> [2] > https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png > >>>> [3] > https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf > >>>> [4] > https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png > >>> > >>> > >>> > >>> -- > >>> Adrien > >>> > >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
