Re: [xwiki-devs] [VOTE] Have less [VOTE]s

Short story: We should have less VOTEs, since too many votes is tiresome and counter-productive. A vote should be fired only for critical stuff, or when a compromise solution between suboptimal alternatives is needed. Long story: According to the rules [1], a VOTE comes with strong requirements on the committers: every committer must respond to votes, and vote only after carefully analyzing and understanding what's being voted. In theory, this has several benefits: - it ensures the openness, democracy and meritocracy of the community - it ensures that all the affected parties can make their voice heard when changes might affect them - it lets the community know about big changes in the code, even if not everybody votes - it tries to maximize the quality of the code, since every design is first validated by all the sharp minds participating in the project - it tries to maximize the global shared ownership of the code, since every developer gets involved in everyone else's code And all these are good goals, but when too much votes occur, downsides emerge: - decision fatigue [2], which means that votes get less attention, and +1-ing is just an automated process -- +1 after reading just the subject, or +1 if someone trusted already voted - decision paralysis [3] will actually cause committers to stop voting altogether on non-essential issues - developer frustration, when every change has to be discussed at length -- in theory, the vote process rules explicitly say that only major changes must be voted, and even for major changes, only when the committer isn't sure that everybody else will agree with the vote; however, recently there has been an increase in the situations in which things must be voted, and in most weeks several votes are started --- [4] says that 103 votes were started last year, almost two every week - reduced efficiency, less time for actual coding, since a lot of time is spent on trying to understand what's being proposed in the votes - it transforms the democracy into a bureaucracy - it reduces the self-confidence of developers; in theory, a contributor becomes a committer when the other committers consider him/her to have the required knowledge, skills and overall understanding of the XWiki code and guiding principles to be allowed to freely commit their own changes. In practice, most changes still have to be discussed, voted, validated before the actual commit can happen. - while the vote right mean that all committers can say their opinion, it also means that the vote is a two-way obligation, the obligation to have their opinion validated by everybody else, and the obligation to get involved and validate everybody else's code I've been monitoring a few other communities, especially Apache projects, the ones that we're supposedly modeled after, and I haven't seen this huge amount of votes in any of them. Votes are actually exceptional events, when something important happens: - new committers - releases - major infrastructure changes, like switching from Ant to Maven, or from SVN to Git For example, the Velocity project had 15 votes in the past three years [5]. Maven had 125 votes last year, but almost all of them are release votes, one for every plugin, and they have a lot of plugins [6]. So I'm proposing to stick closer to the original voting rules, which means that votes are sent only for major changes (in code, infrastructure or community), and rely more on the lazy consensus advertised in the vote rules [1]. Some of the purposes that the current vote requirements try to address can be accomplished by other means: - API changes can be just announced - code changes should rely on lazy consensus, and committers should spend more time doing commit reviews - we can use feature branches and pull request more often, since a pull request is a request for comments - we can go back to trusting the skills and common sense of our

[1] http://dev.xwiki.org/xwiki/bin/Community/Committership#HVoting [2] http://en.wikipedia.org/wiki/Decision_fatigue [3] http://en.wikipedia.org/wiki/Decision_fatigue#Decision_paralysis [4]

[5]

[6]

-- Sergiu Dumitriu http://purl.org/net/sergiu