Gov/en/Portal:Voting/Research: Difference between revisions

(One intermediate revision by the same user not shown)

Line 1:

{{KidsIntro|Before choosing how to vote, it is smart to look at groups who have made decisions together online for a long time, like the people who build Wikipedia, the Debian computer system and the Firefox web browser. Scientists have also studied how these groups decide. This page tells what they learned.}}

{{KidsIntro|Before choosing how to vote, it is smart to look at groups who have made decisions together online for a long time, like the people who build Wikipedia, the Debian computer system and the Firefox web browser. Scientists have also studied how these groups decide. This page tells what they learned. One big lesson: these groups vote only rarely, for the biggest questions. Most of the time they just do things, undo mistakes and talk.}}

{{ExpertIntro|Evidence base of the Voting portal, built on several reference bases rather than a single one. Wikimedia is one of them: it ran Schulze (Condorcet) Board elections on the SecurePoll secret-ballot extension in the late 2000s and early 2010s, then switched to single transferable vote (Meek, Droop quota) in 2021 for proportional multi-seat results; ArbCom elections and RfA complement consensus-based editorial decisions. Debian is another: it has elected its Project Leader with a Condorcet method (cloneproof Schwartz sequential dropping, equivalent to Schulze) under its constitution's Standard Resolution Procedure for over two decades, with published tallies, quorum and supermajority rules. Mozilla is a third, contrasting case: a well-documented module ownership system that distributes authority by contribution, without community-wide elections. Peer-reviewed research (Schulze 2011, Tideman 1987, Konieczny 2009, Forte et al. 2009, Shaw and Hill 2014, Jemielniak 2014, O'Mahony and Ferraro 2007, Leskovec et al. 2010, Mockus et al. 2002) documents the mathematical properties of these methods, the governance dynamics of these communities, and how these processes have been evaluated. Each cited source was verified online. The closing section lists what WikiDeal could take from this, as initial hypotheses.}}

{{ExpertIntro|One finding stated upfront: in all the communities studied here, formal voting is a last resort, reserved for complex or contested questions, while most decisions pass through lighter mechanisms (direct action, revert, discussion, lazy or rough consensus). Evidence base of the Voting portal, built on several reference bases rather than a single one. Wikimedia is one of them: it ran Schulze (Condorcet) Board elections on the SecurePoll secret-ballot extension in the late 2000s and early 2010s, then switched to single transferable vote (Meek, Droop quota) in 2021 for proportional multi-seat results; ArbCom elections and RfA complement consensus-based editorial decisions. Debian is another: it has elected its Project Leader with a Condorcet method (cloneproof Schwartz sequential dropping, equivalent to Schulze) under its constitution's Standard Resolution Procedure for over two decades, with published tallies, quorum and supermajority rules. Mozilla is a third, contrasting case: a well-documented module ownership system that distributes authority by contribution, without community-wide elections. Peer-reviewed research (Schulze 2011, Tideman 1987, Konieczny 2009, Forte et al. 2009, Shaw and Hill 2014, Jemielniak 2014, O'Mahony and Ferraro 2007, Leskovec et al. 2010, Mockus et al. 2002), plus Ostrom's commons research and community process documents (Wikipedia, Apache, IETF RFC 7282), documents the mathematical properties of these methods, the governance dynamics of these communities, and how these processes have been evaluated. Each cited source was verified online. The closing section lists what WikiDeal could take from this, as initial hypotheses.}}

__TOC__

Line 10:

== What twenty years of Wikimedia elections teach ==

The Wikimedia movement, which produces Wikipedia, has run large online elections since the mid-2000s and documents them publicly on [https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections Meta-Wiki]. It is used here as one reference base among others: the exact election calendar matters less than the patterns it illustrates.

The Wikimedia movement, which produces Wikipedia, has run large online elections since the mid-2000s and documents them publicly on [https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections Meta-Wiki]. It is used here as one reference base among others: the exact election calendar matters less than the patterns it illustrates. The sourced numbers behind this section (ballots, methods, decision votes) are gathered on the dedicated [[Gov/en/Portal:Voting/Condorcet-History|history and results page]].

* '''Condorcet in production.''' Several Board of Trustees elections of the late 2000s and early 2010s used the [https://en.wikipedia.org/wiki/Schulze_method Schulze method]. The [https://meta.wikimedia.org/wiki/Board_elections/2008/Results/en 2008 election], documented in detail, involved 15 candidates, about 26,000 eligible voters and 3,019 valid ballots; the [https://meta.wikimedia.org/wiki/Board_elections/2009/Results/en 2009] and 2011 elections used the method again. These dates are given as documented examples, not as a complete history, and the point does not depend on them: what matters is that a Condorcet method worked repeatedly at that scale. ~~Notably~~, the ~~2008 ballots contained~~ a real [https://en.wikipedia.org/wiki/Condorcet_paradox Condorcet ~~cycle~~] ~~among mid-ranked candidates, which the Schulze method resolved deterministically: the paradox~~ is not just theoretical, and ~~a well-chosen method handles it~~.

* '''Condorcet in production.''' Several Board of Trustees elections of the late 2000s and early 2010s used the [https://en.wikipedia.org/wiki/Schulze_method Schulze method]. The [https://meta.wikimedia.org/wiki/Board_elections/2008/Results/en 2008 election], documented in detail, involved 15 candidates, about 26,000 eligible voters and 3,019 valid ballots; the [https://meta.wikimedia.org/wiki/Board_elections/2009/Results/en 2009] and 2011 elections used the method again. These dates are given as documented examples, not as a complete history, and the point does not depend on them: what matters is that a Condorcet method worked repeatedly at that scale. The 2008 results page publishes the full pairwise comparison table and a dump of the ballots, so anyone can recompute the count. The page itself does not comment on cycles, but the published table shows a real preference circle among three mid-ranked candidates (Heiskanen preferred to Postlethwaite 841 to 770, Postlethwaite to Saintonge 797 to 769, Saintonge to Heiskanen 745 to 737): the [https://en.wikipedia.org/wiki/Condorcet_paradox Condorcet paradox] is not just theoretical. It did not affect the outcome, since the winner beat every other candidate head to head, and completion rules such as Schulze exist precisely for such cases.

* '''Secret ballots at scale.''' These elections run on [https://www.mediawiki.org/wiki/Extension:SecurePoll SecurePoll], a MediaWiki extension for encrypted secret ballots, administered by an election committee, and also used for the annual [https://en.wikipedia.org/wiki/Wikipedia:Arbitration_Committee_Elections Arbitration Committee elections] on the English Wikipedia. The [https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections_2013/Results 2013 election report] notes operational issues with the tooling while confirming that none affected the security of votes: election infrastructure needs maintenance like any software.

* '''Methods can evolve.''' In [https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2021/Results 2021], Wikimedia switched its Board elections to the [https://en.wikipedia.org/wiki/Single_transferable_vote single transferable vote], using [https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/Single_Transferable_Vote Meek's variant with the Droop quota] in SecurePoll. The stated motivation family is proportionality: when several seats are filled at once, STV lets different parts of the community be represented. The lesson: a community can change its voting method as its needs change, if the method is a documented, revisable choice.

Line 38:

'''Assessment (initial hypothesis).''' How participatory is it? Mozilla is participatory in a meritocratic sense: anyone can gain real authority over a module by contributing, discussions happen in a [https://groups.google.com/a/mozilla.org/g/governance public governance forum], and escalation paths exist. But participation is not electoral: there is no equivalent of Wikimedia's community-elected Board seats or Debian's annual leader election, and the final word belongs to an appointed ultimate decision-maker. How documented is it? Well documented at the level of principles and roles (public policy pages, a public list of [https://wiki.mozilla.org/Modules modules and owners], escalation rules), less documented than Wikimedia or Debian when it comes to decision records: there is no public equivalent of Debian's recomputable tallies, since there are no general votes to tally. For WikiDeal, Mozilla mainly shows that a community can be open and functional without general elections, and at what cost: legitimacy then rests on appointment chains rather than on votes, which is the opposite of the one user, one vote hypothesis explored in this portal.

== Before the ballot: the documented ladder of lighter tools ==

Across these communities, voting sits at the top of a documented ladder of lighter decision tools, and most decisions never climb that high:

* '''Wikipedia: bold, revert, discuss.''' The community documents an explicit escalation path. Editors are encouraged to make [https://en.wikipedia.org/wiki/Wikipedia:BOLD,_revert,_discuss_cycle bold edits]; if an edit is reverted, the next step is not a vote but a discussion with the person who reverted it. The [https://en.wikipedia.org/wiki/Wikipedia:Consensus consensus policy] governs most decisions, a widely cited community page insists that [https://en.wikipedia.org/wiki/Wikipedia:Polling_is_not_a_substitute_for_discussion polling is not a substitute for discussion], and the [https://en.wikipedia.org/wiki/Wikipedia:Dispute_resolution dispute resolution] pages describe a graduated path (talk page, third opinions, structured processes) before any binding decision.

* '''Apache: lazy consensus first.''' The Apache Software Foundation documents [https://community.apache.org/committers/lazyConsensus.html lazy consensus], described as the first and possibly the most important of its consensus-building tools: state an intent publicly, wait an appropriate time (usually 72 hours), and proceed if nobody objects. Its [https://www.apache.org/foundation/voting.html voting process page] presents voting as the way to tell whether consensus has been reached when it is genuinely in question, with different rules for procedural issues, code changes and releases.

* '''IETF: rough consensus, not majority rule.''' The Internet Engineering Task Force builds standards through [https://en.wikipedia.org/wiki/Rough_consensus rough consensus]. [https://www.rfc-editor.org/rfc/rfc7282 RFC 7282] states explicitly that the IETF is supposed not to be run by a majority rule philosophy, and describes consensus as the practice of addressing objections rather than counting heads.

* '''Commons research: graduated mechanisms.''' Elinor Ostrom's studies of long-enduring commons institutions, summarised in [https://en.wikipedia.org/wiki/Elinor_Ostrom her design principles], found that durable communities use graduated sanctions and give members rapid access to low-cost local arenas for conflict resolution: cheap, light mechanisms handle most cases, and heavier procedures are reserved for what the light ones cannot settle.

The reading for WikiDeal (initial hypothesis): a Condorcet ballot is the heaviest tool in this ladder, not a supreme one. It is relevant where a case is complex and where the need to put it to a vote is clearly and widely perceived, and it works precisely because it is not asked to do everything. If a contribution can simply be reverted, no vote is needed; a vote becomes relevant only when a conflict survives revert and discussion.

Line 74:

Line 86:

== What WikiDeal could take from this (initial hypotheses) ==

* Formal votes are rare events even in communities that vote well: a documented ladder of lighter tools (act, revert, discuss, lazy or rough consensus) settles most questions, and the ballot is reserved for what the ladder cannot settle (Wikipedia BRD, Apache lazy consensus, IETF RFC 7282, Ostrom's design principles).

* Simple majority is enough for binary questions; complex multi-option decisions deserve a Condorcet-style count (Schulze), and multi-seat elections a proportional method (STV): this mirrors twenty years of converging practice at Wikimedia and Debian.

* Secret ballots for electing people, public consensus for editorial work: two regimes, both proven at scale.

Line 96:

Line 109:

* Leskovec, Jure; Huttenlocher, Daniel; Kleinberg, Jon (2010). "Governance in Social Media: A case study of the Wikipedia promotion process". ''Proceedings of the Fourth International AAAI Conference on Weblogs and Social Media (ICWSM)''. [https://arxiv.org/abs/1004.3547 Open-access version (arXiv)].

* Mockus, Audris; Fielding, Roy T.; Herbsleb, James D. (2002). "Two Case Studies of Open Source Software Development: Apache and Mozilla". ''ACM Transactions on Software Engineering and Methodology'' 11(3), pages 309 to 346. [https://herbsleb.org/web-pubs/pdfs/mockus-two-2002.pdf Author copy (PDF)].

* Resnick, Pete (2014). "On Consensus and Humming in the IETF". RFC 7282, Internet Engineering Task Force. [https://www.rfc-editor.org/rfc/rfc7282 RFC Editor].

* Ostrom, Elinor (1990). ''Governing the Commons: The Evolution of Institutions for Collective Action''. Cambridge University Press. [https://en.wikipedia.org/wiki/Elinor_Ostrom About the author and the design principles].

* Mozilla governance documentation, verified online: [https://www.mozilla.org/en-US/about/governance/ Governance overview], [https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ Module ownership policy], [https://www.mozilla.org/en-US/about/governance/roles/ Roles and leadership], [https://www.mozilla.org/en-US/about/governance/organizations/ Organizations], [https://wiki.mozilla.org/Modules Module list].

* Community decision-process documentation, verified online: [https://en.wikipedia.org/wiki/Wikipedia:BOLD,_revert,_discuss_cycle Wikipedia bold, revert, discuss cycle], [https://en.wikipedia.org/wiki/Wikipedia:Polling_is_not_a_substitute_for_discussion Wikipedia polling essay], [https://en.wikipedia.org/wiki/Wikipedia:Dispute_resolution Wikipedia dispute resolution], [https://community.apache.org/committers/lazyConsensus.html Apache lazy consensus], [https://www.apache.org/foundation/voting.html Apache voting process].

'''See also:''' [[Gov/en/Portal:Voting/Main|Voting at WikiDeal]] · [[Gov/en/Portal:Voting/Methods|Voting methods]] · [[Gov/en/Portal:Voting/Rules|Voting rules]] · [[Gov/en/Portal:Meta/Licensing-and-Credits|Licensing and credits]]

'''See also:''' [[Gov/en/Portal:Voting/Main|Voting at WikiDeal]] · [[Gov/en/Portal:Voting/Methods|Voting methods]] · [[Gov/en/Portal:Voting/Rules|Voting rules]] · [[Gov/en/Portal:Voting/Condorcet-History|Condorcet history and results]] · [[Gov/en/Portal:Meta/Licensing-and-Credits|Licensing and credits]]

[[Category:Migration June 2026]]