Just for the record, the Wikimedia Foundation Election Committee has been a standing committee since 2015, and reports to the Board Governance Committee.  It is tasked with making recommendations on how elections are carried out, and specifically is responsible for community elections to the Board of Trustees, the FDC and the FDC ombuds, as well as " Similar community-selected positions as determined by the Wikimedia Foundation Board of Trustees".  To the best of my knowledge, the Elections Committee has had no involvement in the MCDC election, and there's no indication at all that the Board asked them to assist or to manage the election.  I would really like to see a couple of stewards acting as scrutineers for this election, simply because they are really experienced at identifying the kinds of problems that turn up on elections like this (you'd be surprised how often there are issues, I certainly was when I was on the EC), and the Strategy folks who are in charge of the election already have more than enough on their plate.  DISCLOSURE:  I am a candidate in this election.

I am curious what is meant by a "7-member district".  Lodewijk, could you explain in more detail?

What isn't really obvious is that at the same time as the content management community is carrying out this single-transferable-vote election, a special committee representing affiliates from different geographic areas is also, in parallel, selecting 6 people from exactly the same list of candidates.  Thus, we have the same slate of candidates running simultaneously in two separate elections, competing for 7 community-selected seats and 6 affiliate-selected seats.  As a candidate, I find this situation quite uncomfortable. It's not well understood, and the number of candidates makes the selection process much more complex for both groups.  I hope that for the STV election, we see exactly the type  of results that we saw for the Trustee election a few weeks ago, in the same format, so that it is very clear how the STV process worked in this case.  I understand and accept that the affiliate selection process is going to be very different, and there will be a fair amount of negotiation to come up with the most favoured result, but since there's a reasonable chance at least some of their selected candidates will be selected already by the community, they'll need to ensure they have a final selection of at least 13 people so that any duplicates or otherwise ineligible candidates (due to the 2-per-wiki rule) will still result in filing all the seats. 


Risker/Anne


On Mon, 18 Oct 2021 at 12:47, effe iets anders <effeietsanders@gmail.com> wrote:
There's that, +1 for sure. 

But even within the current limitations, there are some configuration options that could have been chosen to improve user experience. For example, various WMF staff members have communicated different cutoff points when people shouldn't have to worry about their ranking any longer. Great. But this is hidden in a wall of text. A more user friendly way would have been to actually limit the interface to the top-X positions, if you can show with some basic simulations that this is indeed the reasonable cutoff. 

Not that this would have been a 'good' voting method by any standard with rank-top15 but it would be 70/15 times less painful :) 

It's also odd that I have to discover the first-letter-trick. There may be more tricks out there! I honestly was fully expecting that the WMF would have fixed the software before setting up the vote, so I didn't give it another thought. But a few of these pain points could have been clearer if there would have been a test period with a few volunteers... (although I assume at least the election committee was thoroughly consulted)

Lodewijk

On Mon, Oct 18, 2021 at 4:30 AM Jan Ainali <ainali.jan@gmail.com> wrote:
Thanks for your reply Kaarel,

I just wanted to note that UI of SecurePoll caused problem in the board election too, and that the same excuse was used then "in a short time once". Obviously this is a piece of infrastructure that we need in the movement and that any team doing one election should not need to fix the software for it.

Hence, a specific project, unrelated to any election, should be tasked to solve this by the Wikimedia Foundation. And it should start soon to avoid us finding ourselves in the same problem when the next election is being called.

Thanks,
Jan Ainali


Den mån 18 okt. 2021 kl 13:02 skrev Kaarel Vaidla <kvaidla@wikimedia.org>:
Thank you everyone for taking the time to vote on the elections, for engaging with the tools that have been created to facilitate the voting, and for taking the time to provide the feedback. Running these elections with 70 candidates is a pilot and it is a great opportunity to learn together and with your support and input. We are gathering the lessons learned, so there can be improvements for the next time.

I am responding to some of the points made in the thread:
  • The user interface and, as a result, the user experience for voting on the SecurePoll for 70 candidates with a Single Transferable Voting method is indeed sub-optimal. Unfortunately, we could not figure out how to make it more user friendly in a short time once it became clear that there would be 70 candidates. It would need essential changes on how the voting would happen. There are some suggestions for improvements in this thread (no dropbox, but clickable or drag & drop candidate chips; choosing a different voting method or creating 7-member districts). It would be great to receive further perspectives on this!
  • Thank you, Lodewijk, for sharing practical guidance on how to make the most of the current user interface. Typing the first letter of the candidate name to find the right one in the dropdown box with 70 names is probably the best way to do it. A huge thank you to everyone who is taking the time to cast their vote!
  • Ensuring the supporting materials to help people to make informed decisions has been a complex matter. The candidate statements add up to 55 pages of text, which is difficult to navigate. It seemed like a compass tool could be of help here, but it comes with its own complications:
    • There was a 10-day window to submit the statements and a 5-day upvoting period. We did our best to communicate it widely on mailing lists (e.g. here and here) as well as social media groups, yet as there is so.much going on, not everyone noticed it in the timely manner.
    • We are no longer collecting or upvoting statements. We hope that 19 that were selected are at least to some extent helpful in informing the voting. We are happy to receive the feedback regarding the statement collection and upvoting, so it would be possible to improve the process in the future.
    • Election compass has its own user interface and experience challenges. We have opted for all the candidates being selected as default for comparison, as it provides a good comparison across the pool - this helps to have a good overview of the positions of all the candidates. However, this makes navigating their rationale statements more difficult, as it involves a lot of scrolling. Also, if one is interested in comparing 2 candidates, there is a lot of deselecting that needs to happen. It seemed that selecting candidates manually would bring more personal bias into use of the tool, so we have chosen the select all approach as default. Overall, it is the number of candidates that is creating the bulk of the navigation and comparison issues and we are open to feedback on how to improve this in the future.
    • The length of the statements made by the candidates in the compass tool was capped to prevent us from creating another wall of text. While it helps to better understand the position of the candidate, it would create a further barrier for voter engagement, if the expression is not clear and concise. I believe that the word limits will be an essential part of the future elections and candidate statements, because it reduces the access barrier for voters and also facilitates translations to a wider range of languages, which makes the information even more accessible. What can be discussed is the exact limit size and also what information is the most helpful to collect from candidates.
    • The tool that we used is Open Election Compass. We did not do a full code review for this, but we did not experience any anomalies in weighing of the votes during testing. If there are people who are interested in doing the code review, here is the link to the tool in GitHub.
  • We are truly grateful to the community members who have stepped in and tried to make the information regarding the candidates more easily digestible. This goes a long way in supporting informed voting in this process! Thank you Dušan Kreheľ and Andrew Lih for your proactive and constructive approach!
I apologize for the length of the response - I have tried to break it up so the single points are more clear. I am available to respond to any further questions and specifications, as well as happy to receive any further feedback.

Wishing everyone a great week ahead!
Kaarel

On Mon, Oct 18, 2021 at 10:44 AM Mario Gómez <mariogomwiki@gmail.com> wrote:


On Mon, Oct 18, 2021 at 3:57 AM effe iets anders <effeietsanders@gmail.com> wrote:
This is a horribly problematic election. Not only does it take hours to go through the candidates if you actually want to rank them, but you would also need to be willing to spend about a lot of time to enter them into the broken voting interface (which works great for up to 5 candidates - not for 70). 

I filled about 14 candidates and it was not extremely bad, but for anyone looking to rank more candidates, I guess it might have been daunting. I agree that the dropdowns are a very inconvenient UI for this kind of votation. I can imagine something more efficient like having chips for every candidate (no dropdown), and then sequentially click on them to add them to the ballot in order, then maybe supporting drag and drop to re-order. Changing the order of candidates once the ballot is prepared is particularly cumbersome.

Best,

Mario
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/B5KAHUEMXXPSFBDPM2ZQC6OFHUNVPUQS/
To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org


--
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/A77244U2OHCS3SQHE4RADPHCTEWSF7IB/
To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/3SPBQENPZ3Y7EGCUCUHENK6DDKA3RRQO/
To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/LZLWTP64HSH3XGJP4MVHGELCL7KH22NL/
To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org