[VOTE] Have less [VOTE]s

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[VOTE] Have less [VOTE]s

Sergiu Dumitriu-3
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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Have less [VOTE]s

Caleb James DeLisle
+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+-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
>

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Have less [VOTE]s

Jérôme Velociter
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+-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
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Have less [VOTE]s

vmassol
Administrator
In reply to this post by Sergiu Dumitriu-3
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 <[hidden email]> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Have less [VOTE]s

Marius Dumitru Florea
In reply to this post by Sergiu Dumitriu-3
On Wed, Jan 23, 2013 at 8:04 PM, Sergiu Dumitriu <[hidden email]> 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
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Have less [VOTE]s

Ecaterina Moraru (Valica)
In reply to this post by vmassol
On Thu, Jan 24, 2013 at 10:37 AM, Vincent Massol <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Have less [VOTE]s

vmassol
Administrator
In reply to this post by vmassol

On Jan 24, 2013, at 9:37 AM, Vincent Massol <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs