On Thu, Jan 24, 2013 at 10:37 AM, Vincent Massol <[email protected]> wrote:
> 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. > > +1 for voting only on the really important matters and to refine more our mails threads in concordance with above classification. Maybe we abused a bit the voting system, but being remote we need a way to properly communicate and ask for feedback/validation/ideas on what we are doing. Thanks, Caty > 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 <[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. > > > > > > 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+-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
