Gov/en/Portal:Voting/Research: Difference between revisions
Soften reliance on Schulze election years, add Mozilla governance section and evaluation research section (verified sources) + link updates |
Precision fix: Mockus et al. 2002 findings described strictly as published (modules, code ownership, core groups) |
||
| Line 56: | Line 56: | ||
* '''O'Mahony and Ferraro (2007)''' followed the Debian community over several years and analysed how it built its governance system. Their evaluation: members created a shared basis of formal authority but deliberately limited it with democratic mechanisms (annual elections, a constitution, recallable leadership), and the community experimented with and revised its own rules over time. The study treats Debian's elections as a working system of legitimacy, not just a formality. | * '''O'Mahony and Ferraro (2007)''' followed the Debian community over several years and analysed how it built its governance system. Their evaluation: members created a shared basis of formal authority but deliberately limited it with democratic mechanisms (annual elections, a constitution, recallable leadership), and the community experimented with and revised its own rules over time. The study treats Debian's elections as a working system of legitimacy, not just a formality. | ||
* '''Leskovec, Huttenlocher and Kleinberg (2010)''' quantitatively evaluated a Wikipedia decision process: requests for adminship, where the community discusses and votes on promoting a member. Analysing large numbers of votes, they show that outcomes are strongly shaped by who votes, how early votes lean, and the relative status of voters and candidates. The evaluation lesson: even a public, well-documented voting process carries social dynamics that raw rules do not capture, so process design should be tested against real behaviour. | * '''Leskovec, Huttenlocher and Kleinberg (2010)''' quantitatively evaluated a Wikipedia decision process: requests for adminship, where the community discusses and votes on promoting a member. Analysing large numbers of votes, they show that outcomes are strongly shaped by who votes, how early votes lean, and the relative status of voters and candidates. The evaluation lesson: even a public, well-documented voting process carries social dynamics that raw rules do not capture, so process design should be tested against real behaviour. | ||
* '''Mockus, Fielding and Herbsleb (2002)''' evaluated the development processes of Apache and Mozilla with quantitative data. For Mozilla they document a process | * '''Mockus, Fielding and Herbsleb (2002)''' evaluated the development processes of Apache and Mozilla with quantitative data (code changes, problem reports, team sizes). For Mozilla, at that time, they document a process with commercial roots, more formal than Apache's, organised in modules with code ownership, and core groups creating most of the new functionality. It is an early, dated snapshot, but it shows that the degree of effective participation can be measured rather than assumed. | ||
Two of the studies already cited above are themselves evaluations: Konieczny (2009) evaluates Wikipedia's resistance to oligarchy, and Shaw and Hill (2014) evaluate the concentration of power across 683 wikis. Taken together, the evaluation literature converges on one point: openness must be measured and maintained through explicit mechanisms, because it degrades silently otherwise. | Two of the studies already cited above are themselves evaluations: Konieczny (2009) evaluates Wikipedia's resistance to oligarchy, and Shaw and Hill (2014) evaluate the concentration of power across 683 wikis. Taken together, the evaluation literature converges on one point: openness must be measured and maintained through explicit mechanisms, because it degrades silently otherwise. | ||