Just for the record, the Wikimedia Foundation Election Committee <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections_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 Trustee <https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_Foundation_Board_of_Trustees>s". 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 <[email protected]> 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 <[email protected]> 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 <[email protected] >> >: >> >>> 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 >>> >>> <https://meta.wikimedia.org/wiki/Movement_Charter/Drafting_Committee/Candidates#Candidates> >>> 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 >>> >>> <https://lists.wikimedia.org/hyperkitty/list/[email protected]/message/7HVBI6M55MNVBKHNEDBEIUPSWFGJIBIE/> >>> and here >>> >>> <https://lists.wikimedia.org/hyperkitty/list/[email protected]/thread/FAJ57JAR3VP75V23OKX6MEBYUHWIAYUY/>) >>> 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 >>> <https://open-election-compass.com/>. 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 >>> <https://github.com/open-election-compass/client>. >>> - 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 <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Mon, Oct 18, 2021 at 3:57 AM effe iets anders < >>>> [email protected]> 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 -- [email protected], >>>> 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/[email protected]/message/B5KAHUEMXXPSFBDPM2ZQC6OFHUNVPUQS/ >>>> To unsubscribe send an email to [email protected] >>> >>> >>> >>> -- >>> >>> Kaarel Vaidla (he/him) >>> >>> Movement Strategy <https://meta.wikimedia.org/wiki/Strategy/2030> >>> >>> Wikimedia Foundation <https://wikimediafoundation.org/> >>> _______________________________________________ >>> Wikimedia-l mailing list -- [email protected], 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/[email protected]/message/A77244U2OHCS3SQHE4RADPHCTEWSF7IB/ >>> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> Wikimedia-l mailing list -- [email protected], 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/[email protected]/message/3SPBQENPZ3Y7EGCUCUHENK6DDKA3RRQO/ >> To unsubscribe send an email to [email protected] > > _______________________________________________ > Wikimedia-l mailing list -- [email protected], 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/[email protected]/message/LZLWTP64HSH3XGJP4MVHGELCL7KH22NL/ > To unsubscribe send an email to [email protected]
_______________________________________________ Wikimedia-l mailing list -- [email protected], 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/[email protected]/message/S3QB44DL2REEAXGPETAU4EKK6LMJVYG5/ To unsubscribe send an email to [email protected]
