[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 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+-sub... [5] http://velocity.markmail.org/search/?q=subject%3Avote+date%3A201001-201212+-... [6] http://maven.markmail.org/search/subject:vote+date:201201-201212+-subject:re... -- Sergiu Dumitriu http://purl.org/net/sergiu
+1 fewer votes. Of course this [VOTE] doesn't change official policy so it is merely an expression of agreement that less bureaucracy would be better. I often recuse myself from voting if the topic at hand is in my judgement not one which would not benefit from my opinion. Thanks, Caleb On 01/23/2013 01:04 PM, Sergiu Dumitriu 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+-sub... [5] http://velocity.markmail.org/search/?q=subject%3Avote+date%3A201001-201212+-... [6] http://maven.markmail.org/search/subject:vote+date:201201-201212+-subject:re...
Le 23/01/13 21:46, Caleb James DeLisle a écrit :
+1 fewer votes. Of course this [VOTE] doesn't change official policy so it is merely an expression of agreement that less bureaucracy would be better.
I could not help but think of http://www.youtube.com/watch?v=YawagQ6lLrA I'm +1 for less +1s :) Jerome
I often recuse myself from voting if the topic at hand is in my judgement not one which would not benefit from my opinion.
Thanks, Caleb
On 01/23/2013 01:04 PM, Sergiu Dumitriu 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+-sub... [5] http://velocity.markmail.org/search/?q=subject%3Avote+date%3A201001-201212+-... [6] http://maven.markmail.org/search/subject:vote+date:201201-201212+-subject:re...
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 <[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+-sub... [5] http://velocity.markmail.org/search/?q=subject%3Avote+date%3A201001-201212+-... [6] http://maven.markmail.org/search/subject:vote+date:201201-201212+-subject:re... -- Sergiu Dumitriu http://purl.org/net/sergiu
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+-sub...
[5]
http://velocity.markmail.org/search/?q=subject%3Avote+date%3A201001-201212+-...
[6]
http://maven.markmail.org/search/subject:vote+date:201201-201212+-subject:re...
-- Sergiu Dumitriu http://purl.org/net/sergiu
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jan 24, 2013, at 9: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.
Actually after thinking more about this and talking with Thomas I think it's enough to do this: * Send a Notice/Proposal email when the committer judges that he's making some important changes * No obligation to send anything when breaking "small" APIs (for example as was the case a few days ago by Denis) because he/she'll have to change the pom.xml anyway and since committers are supposed to review commits, there's a good chance that other committers will notice it and ask questions if need be. This is really what's important to me: that the change doesn't go unnoticed before the release is done. What we also need to do is improve our release script so that the CLIRR part of the Release Notes is fully generated by it. What's missing ATM are separating breakages by topic and extracting the reason for the breakage out of the pom.xml. I can think of 3 ways: * improve the script so that it extracts the reasons and prints them one below another and then further down adds the full list of method/class/field breakages * have the script just generates the list of method/class/field breakages and add a link in the RN to the pom.xml files that contain the explanations (the user will need to read them if he/she wants the details) * have developers edit the RN whenever they edit the pom.xml to add a new violation so that the CLIRR part of the RN is created as a we progress and so that it's not up to the RM to spend the 15 more minutes necessary ATM to do so. Of course we need to finish our discussion about: * young apis * defensive programming (opening apis when required vs opening by default) * SPI vs API Thanks -Vincent
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 <[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+-sub... [5] http://velocity.markmail.org/search/?q=subject%3Avote+date%3A201001-201212+-... [6] http://maven.markmail.org/search/subject:vote+date:201201-201212+-subject:re... -- Sergiu Dumitriu http://purl.org/net/sergiu
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+-sub... [5] http://velocity.markmail.org/search/?q=subject%3Avote+date%3A201001-201212+-... [6] http://maven.markmail.org/search/subject:vote+date:201201-201212+-subject:re... -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (6)
-
Caleb James DeLisle -
Ecaterina Moraru (Valica) -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol