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

Hi Sergiu, Indeed it's a good thing to review our voting practices and more generally see if we're using them the right way. Sometimes we use VOTEs when we should use PROPOSAL or DISCUSSION instead and possibly the other way around. I've looked at our latest VOTEs and PROPOSALs. Here they are: 1 [VOTE] Have less [VOTE]s - Sergiu, 23 jan 2 [VOTE] Separate the power of Veto from -1 votes - Sergiu, 23 jan 3 [VOTE] Reduce garbage in the log generated when a migration fails - Denis, 22 jan 4 [VOTE] Add CLIRR exclude for 1 new method in DataMigrationManager interface for 4.4.1 and 4.5M1 - Denis, 22 jan 5 [VOTE] Start using proper version in branches - Vincent, 21 jan 6 [VOTE] Restrict the location of skin resources inside Jars for security - Sergiu, 12 jan 7 [VOTE] ASM 3.x vs 4.x choice - 7 jan, Vincent, 7 jan 8 [VOTE] Merge new Markdown branch from Guillaume Laforge, Vincent, 2 jan 9 [VOTE] New dates for 4.4 releases, Vincent, 21 dec 10 [VOTE] Skip tests while building a release, Edy, 19 dec 11 [VOTE] Start using Mockito instead of JMock, Vincent, 8 dec 12 [VOTE] Make UTF-8 mandatory for a valid installation, Sergiu, 7 dec 13 [Vote] Retire Toucan Skin, Caty, 6 dec 14 [VOTE] Stop shading Rendering Standalone, Vincent, 4 dec 15 [VOTE] Move all lucene plugin classes to internal, Jerome, 28 nov 16 [VOTE] Commit a Release application into platform, 21 nov 17 [VOTE] Retire old query plugin, Thomas, 16 nov Let's see which of these should we have not sent as VOTEs VOTEs that I consider absolutely legit: 1, 2, 8, 9, 11, 12, 13, 14, 15, 16, 17 VOTEs that are ok but could be sent as PROPOSAL or DISCUSSION instead: 3, 5, 6, 7, 10 Now that leaves VOTE number 4. In our practices we have only a few rules regarding the need to VOTE: * Adding a new committer * Removing a committer * Breaking an API without making it legacy I really think we need to be careful when adding or removing APIs because they impact us all as they are extremely hard to change since we're a dev platform. The reason we VOTEd the need to VOTE is because we didn't want to have some API changes (especially API breaking) slipping by by mistake. I'm personally fine to change the VOTE in favor of a Proposal or even better a Notice.

More generally speaking I think we could structure our email threads like this: * [VOTE]: important, others are forced to answer so to be used when needed only and not for asking questions when you're not sure about something * [PROPOSAL] or [DISCUSSION] or [BRAINSTORMING]: something quite important that you wish to discuss with others because there might be different possibilities and you wish to have opinion of others if they're free to help out * [NOTICE]: just telling others about something you're doing just so that they know about it. You're not expecting an answer. FTR here are the last proposals we sent: * [Discussion] Should technical pages hide the bottom tabs?, Sergiu, 20 jan * [Proposal] Add CLA for contributions + Foundation, Vincent, 17 jan * [Proposal] Release XWiki 4.4.1 Monday 21, Vincent, 17 jan * [PROPOSAL] How to translate logs, Thomas, 16 jan * [proposal] 2 new xwiki-contrib projects., Caleb, 8 jan * [Proposal] XWiki 5.x cycle theme, Vincent, 3 jan * [Proposal] Use the XWiki.org JIRA project more, Vincent, 31 dec * FOSDEM talk proposal: "Coping with the proliferation of tools within your community", Sergiu, 21 dec * [Proposal] Create a JIRA project for the XWiki project's infrastructure, Vincent, 19 dec * [Proposal] Jenkins emails configuration, Vincent, 19 dec * References Section update proposal, Benjamin, 18 dec * [Proposal] Stopping the 4.4M1 release till tests are all passing - Commando mode, Vincent, 13 dec * [Proposal] XWiki 4.5 Roadmap dates and 4.x end of cycle, Vincent, 7 dec * [Proposal] Remove old info boxes/warnings for XWiki 1.x and 2.x, Vincent, 4 dec * [PROPOSAL] Include require.js in XWiki by default and make jQuery available through require.js., Caleb, 30 nov * [UX][Proposal] XWiki Mobile App, Caty, 28 nov * [Proposal] Roadmap for 4.4, Vincent, 26 nov * [DISCUSSION] Handling document translations in Solr Search, Edy, 19 nov Now what I think is working very well in our community, much better than in most Apache project (I've also been an Apache Member for over 10 years and been following lots of mailing lists there) is that we're having good discussions between us on the list, which allows us to share code and be responsible for the overall codebase. I wouldn't want to loose that. So to sum up I'm perfectly fine to reduce number of VOTEs based on the extract shown above but I wouldn't agree if the outcome is to reduce the discussion between ourselves. Specifically all VOTEs 3, 4, 5, 6, 7, 10 should be sent as PROPOSAL, DISCUSSION, BRAINSTORMING or NOTICE. That's a 35% decrease :) So +1 to that. Thanks -Vincent On Jan 23, 2013, at 7:04 PM, Sergiu Dumitriu <sergiu(a)xwiki.org> 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. > > > 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 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+-su… > [5] > http://velocity.markmail.org/search/?q=subject%3Avote+date%3A201001-201212+… > [6] > http://maven.markmail.org/search/subject:vote+date:201201-201212+-subject:r… > -- > Sergiu Dumitriu > http://purl.org/net/sergiu