Standing Election Committee

A Standing Election Committee has been proposed following the 2013 community elections to the Wikimedia Foundation Board of Trustees, the Funds Dissemination Committee, and the FDC Ombudsperson.

Why now?

• The number of community elections has grown three-fold. Adding to one Board of Trustees election every other year, we now have FDC + FDC Ombud elections every other year. This means a three-fold increase in workload. It is difficult for a short-term committee to handle this increasing workload effectively.
• A short-term committee is just about able to handle immediate tasks, but not take on bigger improvements requiring continuity. Many of these are detailed below.
• A short-term committee does not have the time and bandwidth to enable the elections to take a Great Leap Forward in terms of larger issues: consistently expanding the voter base etc. There are 285 Wikipedias and numerous sister projects. Surely it should be our vision to work towards an election system and process that enables contributors to all of them to vote? This requires not just a vision, but thinking through and a series of continuous improvements (and much interaction and coordination with different projects).
• A standing committee with standards for activity and mechanisms for finding its own members could recover sooner from inactivity without board intervention. This year, the committee did not feel able to do this.

What are the benefits?

• Permits sufficient time between elections to:
  • Investigate alternative voting methodologies, including research, discussion with Board, discussion with community
  • Consider the alternative of using an external election service provider, including research, discussion with community and recommendation to Board
  • Work with Engineering to redevelop SecurePoll into a more functional platform (assuming that elections will continue to use this extension)
• Allows greater participation of committee members as tasks are spread out over a greater time
• Reduces the pressure for strong written English skills
• Encourages review of processes well in advance of election
• Much of the "standard" work of the committee (drafting/editing of emails, creating templates for the various election-related pages) can be drafted well in advance of the election and can even be translated well in advance, promoting increased participation
• Improved opportunities for skills development of committee members (difficult to learn some of these tasks on the fly)
• Easier for the Committee to cope if one or more members is not able to meet commitments, and also to identify and remove committee members who cannot or will not meet commitment without creating unnecessary turmoil mid-election

Any potential issues?

• No guarantee that committee members will actually do this work (Based on my observation of AffCom and FDC, I would argue that a Standing Committee would reduce, rather than increase this risk)
• Committee members may perceive themselves to be “representatives” of their home projects/language rather than representative of the entire community. (This is not a new issue.)
• Volunteer fatigue as a general phenomenon (This holds across the board in a volunteer movement and can be mitigated to some extent via sustainable work flows, rather than scrunched ones, due to shorter times.)
• Volunteers might not be able or willing to commit for longer periods of time for this type of committee work.
• A permanent committee increases the risk of the increase of bureaucracy (they might feel the need to design a charter, set of internal rules, committee voting procedures etc.)

What else needs to be considered?

• The idea is to schedule FDC+Ombud and Board of Trustee elections in alternate years, instead of clubbing them in the same year. Even after accounting for member activity, the volunteer election committee found the workload too heavy this year: reviewing so many candidates at the same time, and having three elections together resulted in a very complex ballot.
• What exactly would be the mandate for this committee? Will they be allowed to change things drastically, or will the board provide clear boundaries for each election, and will they only organize them when such instructions have been provided?

What would this committee look like?

• 5-7 members, drawn from a range of communities
• Headed by a formal Chair
• Staff support mandatory; needs to be a formally assigned task
• Board liaison role needs to be clarified
  

Staff support

Two staff positions are proposed - one from LCA, one from Engineering. While these are not full-time roles, the work needs to be given high priority and should be formally part of job descriptions and performance assessment.

Rationale: To quote Risker: "We have good reason to believe that volunteers have not been getting the job done effectively for some time (from my review, at least the last 3 elections), and more and more of the workload is going to naturally devolve to staff. Volunteers don't have the necessary clout to get their banners prioritized, to re-align the Engineering/Operations Dept. schedules, to mandate that the necessary resources be made available, etc."

• Someone from (probably) LCA with sufficient permissions and technical knowledge, as well as understanding of communication systems, to be able to facilitate banners, emails, and other communications with the community; setting up pages; arranging translations; ensuring timelines are met, and so on. This person is going to wind up making sure that the necessary work is done, whether by the committee or by him/herself. This person would also be the key liaison with Engineering to facilitate implementation of the voting interface (whether external or SecurePoll), and would probably be the key individual collecting information for the committee to review with respect to external voting systems.

It is very unrealistic to expect the committee to set up the analysis of external voting systems; the last time that a committee was allowed to do that, they decided to use the single-successful-candidate version of the Schulze system, which is specifically not designed to produce multiple successful candidates and is ridiculously complex to understand. It's the kind of voting system that people obsessed with voting systems come up with, not the kind of system that people wanting to ensure good voter understanding and participation would select.

• Someone from Engineering with sufficient experience and access to be able to oversee the redevelopment of SecurePoll and to ensure its smooth operation. At present, I believe there are only about 3-4 staff with sufficient knowledge to do this. SecurePoll is not robust by any stretch of the imagination, it's terribly badly documented, it's very outdated, and it's not flexible enough for our needs anymore, particularly when voting for different roles on the same ballot. This person also needs the technical expertise to participate in the review of external voting systems, to analyse how those systems would work with WMF MediaWiki, and so on. Again, this needs to be built into a specific individual's job description.

Further thoughts

• On volunteers: While it is a good idea to draw from people who explicitly volunteer, it is also worthwhile to recruit people with skills that the committee needs in order to succeed. At least one of the volunteers must have sufficient understanding of technical matters and WMF MediaWiki to be able to flag when things are going sideways.
• On committee chair: Since it will happen every year, for at least 6 months of the year, we could shift the overhead from the board liaison to a committee chair. (Appointing members, helping them recreate their own processes, sending routine announcement emails, arranging channels of communication with the WMF in tech & PR).
• On board liaison: Role needs to be more clearly delineated. With a committee chair in place, the board liaison can be simply observing, advising, and informing the board, as is the case on other Board-created committees.
• On the software: Even if it is decided to abandon SecurePoll for board elections, it is software that is still in use by various projects for elections, and is also used by the WMF for polling. Board encouragement to get this extension fixed would be valuable if we don't keep Board elections in-house, and absolutely required if we decide to continue running our own elections. Engineering would have a hard time justifying the investment of time in rewriting this without significant direction from above.

References

• Post-mortem of 2013 Elections (Risker's report) Also see talk page
• Wikimedia Foundation elections committee, the implementation of this proposal