On Wed, Jan 23, 2013 at 8:04 PM, Sergiu Dumitriu <[email protected]> wrote: > 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.
+1 > > > 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 Doing real code review (no just code style check) requires background information on the domain targeted by that code. Writing a mail to explain why you choose a particular solution is still a good exercise, even if it doesn't involve any API changes. Thanks, Marius > - 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 committers > > > [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] > http://xwiki.markmail.org/search/?q=subject%3Avote+date%3A201201-201212+-subject%3Are > [5] > http://velocity.markmail.org/search/?q=subject%3Avote+date%3A201001-201212+-subject%3Are > [6] > http://maven.markmail.org/search/subject:vote+date:201201-201212+-subject:re+-subject:result+-subject:cancelled+list:org.apache.maven.dev > -- > Sergiu Dumitriu > http://purl.org/net/sergiu > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
