Alan Gates
2010-09-28, 01:18
Alan Gates
2010-10-02, 00:00
Olga Natkovich
2010-10-04, 15:47
Thejas M Nair
2010-10-04, 16:28
Olga Natkovich
2010-10-04, 18:47
Alan Gates
2010-10-05, 20:15
Olga Natkovich
2010-10-05, 20:24
Benjamin Reed
2010-10-05, 20:32
Daniel Dai
2010-10-05, 20:41
Thejas M Nair
2010-10-05, 20:55
Dmitriy Ryaboy
2010-10-05, 21:38
Santhosh Srinivasan
2010-09-28, 02:27
Olga Natkovich
2010-09-28, 23:39
Dmitriy Ryaboy
2010-09-29, 00:20
Alan Gates
2010-09-29, 00:47
Alan Gates
2010-09-29, 05:44
Santhosh Srinivasan
2010-09-29, 17:57
Benjamin Reed
2010-09-29, 21:32
Olga Natkovich
2010-09-30, 16:27
Benjamin Reed
2010-09-29, 21:55
-
[DISCUSS] Apache Pig bylawsAlan Gates 2010-09-28, 01:18
As directed in our vote to become a TLP, we (Pig's PMC) need to set
out bylaws for the project. I have put up a first proposal for these
by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
look and give feedback.
Alan.
out bylaws for the project. I have put up a first proposal for these
by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
look and give feedback.
Alan.
+
Alan Gates 2010-09-28, 01:18
-
Re: [DISCUSS] Apache Pig bylawsAlan Gates 2010-10-02, 00:00
I have drafted a second version of this. I made the following changes:
1. Based on Dmitriy's feedback on clarity for code change votes, I
changed the approval column of the code change row of the voting table
to say:
"Lazy approval (not counting the vote of the contributor), moving to
lazy majority if a -1 is received"
I think this expresses what Dmitriy believed to be the case that every
code change requires a +1 from a committer that is not the contributor
of the code. Note that this is stronger than what I indicated had
been our practice in the past (to allow contributors to +1 committer's
patches). But it seems reasonable. If a contributor knows the code
well enough to give authoritative votes on contributions s/he should
probably be a committer. And as far as I know this was only done on
Zebra because it had only one committer.
2. Based on Dmitriy's feedback on the horrors of rolling back checkins
(done by responding with a -1 on a commit message), I added the
following sentence:
"Note that this should be a rare occurrence. All efforts should be
made to discuss issues when they are still patches before the code is
committed."
3. Based on Olga's feedback of the need for timetables for votes, I
defined a minimum length for each type of vote. All vote lengths are
in business days. I set code changes at 1 day; release plan, product
release, new committer, and new PMC member at 3 days; and adoption of
new code base, committer removal, and PMC member removal at 6 days. I
picked 1 day for code changes because we don't want to wait long
periods of time to get patches in but we should wait at least a day so
that developers all around the world can take a look. I used 3 days
for other common votes as that is the length currently used by
Hadoop. I picked 6 days for the others because these are momentous
votes and 6 days guarantees one week for everyone to consider and
respond.
4. As suggested by Olga I reviewed other Apache projects to find their
requirements for consensus votes. Most of the projects I reviewed had
no bylaws that I could find. httpd and Jakarta had bylaws that
covered voting but none discussed votes such as removing committers or
PMC members that we stipulate would require unanimous votes with no
abstentions. Both Ant and Xerces did have bylaws for this, and both
require unanimous votes with no abstentions to remove a committer or
PMC member. See http://ant.apache.org/bylaws.html, http://jakarta.apache.org/site/decisions.html
, http://httpd.apache.org/dev/guidelines.html, http://xerces.apache.org/charter.html
for details.
Given that we had one speak in favor of lowering this bar (Olga) and 2
speak in favor of the bar where it is (Alan and Santhosh), for the
moment it stays where it is. If others have thoughts on this, please
contribute them.
5. In response to Ben's suggestion on pre-announcing votes, I added
the following sentence to the guidelines on voting:
"In general votes should not be called at times when it is known that
interested members of the project will be unavailable."
This is weaker than what Ben suggested, but I'm not comfortable with
having to pre-announce votes, as we want the project to be able to
move as quickly as possible. Is this strong enough for you Ben?
Alan.
On Sep 27, 2010, at 6:18 PM, Alan Gates wrote:
> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project. I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
> look and give feedback.
>
> Alan.
1. Based on Dmitriy's feedback on clarity for code change votes, I
changed the approval column of the code change row of the voting table
to say:
"Lazy approval (not counting the vote of the contributor), moving to
lazy majority if a -1 is received"
I think this expresses what Dmitriy believed to be the case that every
code change requires a +1 from a committer that is not the contributor
of the code. Note that this is stronger than what I indicated had
been our practice in the past (to allow contributors to +1 committer's
patches). But it seems reasonable. If a contributor knows the code
well enough to give authoritative votes on contributions s/he should
probably be a committer. And as far as I know this was only done on
Zebra because it had only one committer.
2. Based on Dmitriy's feedback on the horrors of rolling back checkins
(done by responding with a -1 on a commit message), I added the
following sentence:
"Note that this should be a rare occurrence. All efforts should be
made to discuss issues when they are still patches before the code is
committed."
3. Based on Olga's feedback of the need for timetables for votes, I
defined a minimum length for each type of vote. All vote lengths are
in business days. I set code changes at 1 day; release plan, product
release, new committer, and new PMC member at 3 days; and adoption of
new code base, committer removal, and PMC member removal at 6 days. I
picked 1 day for code changes because we don't want to wait long
periods of time to get patches in but we should wait at least a day so
that developers all around the world can take a look. I used 3 days
for other common votes as that is the length currently used by
Hadoop. I picked 6 days for the others because these are momentous
votes and 6 days guarantees one week for everyone to consider and
respond.
4. As suggested by Olga I reviewed other Apache projects to find their
requirements for consensus votes. Most of the projects I reviewed had
no bylaws that I could find. httpd and Jakarta had bylaws that
covered voting but none discussed votes such as removing committers or
PMC members that we stipulate would require unanimous votes with no
abstentions. Both Ant and Xerces did have bylaws for this, and both
require unanimous votes with no abstentions to remove a committer or
PMC member. See http://ant.apache.org/bylaws.html, http://jakarta.apache.org/site/decisions.html
, http://httpd.apache.org/dev/guidelines.html, http://xerces.apache.org/charter.html
for details.
Given that we had one speak in favor of lowering this bar (Olga) and 2
speak in favor of the bar where it is (Alan and Santhosh), for the
moment it stays where it is. If others have thoughts on this, please
contribute them.
5. In response to Ben's suggestion on pre-announcing votes, I added
the following sentence to the guidelines on voting:
"In general votes should not be called at times when it is known that
interested members of the project will be unavailable."
This is weaker than what Ben suggested, but I'm not comfortable with
having to pre-announce votes, as we want the project to be able to
move as quickly as possible. Is this strong enough for you Ben?
Alan.
On Sep 27, 2010, at 6:18 PM, Alan Gates wrote:
> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project. I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
> look and give feedback.
>
> Alan.
+
Alan Gates 2010-10-02, 00:00
-
RE: [DISCUSS] Apache Pig bylawsOlga Natkovich 2010-10-04, 15:47
Looks good to me; +1.
Olga
-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 01, 2010 5:00 PM
To: [EMAIL PROTECTED]
Subject: Re: [DISCUSS] Apache Pig bylaws
I have drafted a second version of this. I made the following changes:
1. Based on Dmitriy's feedback on clarity for code change votes, I
changed the approval column of the code change row of the voting table
to say:
"Lazy approval (not counting the vote of the contributor), moving to
lazy majority if a -1 is received"
I think this expresses what Dmitriy believed to be the case that every
code change requires a +1 from a committer that is not the contributor
of the code. Note that this is stronger than what I indicated had
been our practice in the past (to allow contributors to +1 committer's
patches). But it seems reasonable. If a contributor knows the code
well enough to give authoritative votes on contributions s/he should
probably be a committer. And as far as I know this was only done on
Zebra because it had only one committer.
2. Based on Dmitriy's feedback on the horrors of rolling back checkins
(done by responding with a -1 on a commit message), I added the
following sentence:
"Note that this should be a rare occurrence. All efforts should be
made to discuss issues when they are still patches before the code is
committed."
3. Based on Olga's feedback of the need for timetables for votes, I
defined a minimum length for each type of vote. All vote lengths are
in business days. I set code changes at 1 day; release plan, product
release, new committer, and new PMC member at 3 days; and adoption of
new code base, committer removal, and PMC member removal at 6 days. I
picked 1 day for code changes because we don't want to wait long
periods of time to get patches in but we should wait at least a day so
that developers all around the world can take a look. I used 3 days
for other common votes as that is the length currently used by
Hadoop. I picked 6 days for the others because these are momentous
votes and 6 days guarantees one week for everyone to consider and
respond.
4. As suggested by Olga I reviewed other Apache projects to find their
requirements for consensus votes. Most of the projects I reviewed had
no bylaws that I could find. httpd and Jakarta had bylaws that
covered voting but none discussed votes such as removing committers or
PMC members that we stipulate would require unanimous votes with no
abstentions. Both Ant and Xerces did have bylaws for this, and both
require unanimous votes with no abstentions to remove a committer or
PMC member. See http://ant.apache.org/bylaws.html, http://jakarta.apache.org/site/decisions.html
, http://httpd.apache.org/dev/guidelines.html, http://xerces.apache.org/charter.html
for details.
Given that we had one speak in favor of lowering this bar (Olga) and 2
speak in favor of the bar where it is (Alan and Santhosh), for the
moment it stays where it is. If others have thoughts on this, please
contribute them.
5. In response to Ben's suggestion on pre-announcing votes, I added
the following sentence to the guidelines on voting:
"In general votes should not be called at times when it is known that
interested members of the project will be unavailable."
This is weaker than what Ben suggested, but I'm not comfortable with
having to pre-announce votes, as we want the project to be able to
move as quickly as possible. Is this strong enough for you Ben?
Alan.
On Sep 27, 2010, at 6:18 PM, Alan Gates wrote:
> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project. I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
> look and give feedback.
>
> Alan.
Olga
-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 01, 2010 5:00 PM
To: [EMAIL PROTECTED]
Subject: Re: [DISCUSS] Apache Pig bylaws
I have drafted a second version of this. I made the following changes:
1. Based on Dmitriy's feedback on clarity for code change votes, I
changed the approval column of the code change row of the voting table
to say:
"Lazy approval (not counting the vote of the contributor), moving to
lazy majority if a -1 is received"
I think this expresses what Dmitriy believed to be the case that every
code change requires a +1 from a committer that is not the contributor
of the code. Note that this is stronger than what I indicated had
been our practice in the past (to allow contributors to +1 committer's
patches). But it seems reasonable. If a contributor knows the code
well enough to give authoritative votes on contributions s/he should
probably be a committer. And as far as I know this was only done on
Zebra because it had only one committer.
2. Based on Dmitriy's feedback on the horrors of rolling back checkins
(done by responding with a -1 on a commit message), I added the
following sentence:
"Note that this should be a rare occurrence. All efforts should be
made to discuss issues when they are still patches before the code is
committed."
3. Based on Olga's feedback of the need for timetables for votes, I
defined a minimum length for each type of vote. All vote lengths are
in business days. I set code changes at 1 day; release plan, product
release, new committer, and new PMC member at 3 days; and adoption of
new code base, committer removal, and PMC member removal at 6 days. I
picked 1 day for code changes because we don't want to wait long
periods of time to get patches in but we should wait at least a day so
that developers all around the world can take a look. I used 3 days
for other common votes as that is the length currently used by
Hadoop. I picked 6 days for the others because these are momentous
votes and 6 days guarantees one week for everyone to consider and
respond.
4. As suggested by Olga I reviewed other Apache projects to find their
requirements for consensus votes. Most of the projects I reviewed had
no bylaws that I could find. httpd and Jakarta had bylaws that
covered voting but none discussed votes such as removing committers or
PMC members that we stipulate would require unanimous votes with no
abstentions. Both Ant and Xerces did have bylaws for this, and both
require unanimous votes with no abstentions to remove a committer or
PMC member. See http://ant.apache.org/bylaws.html, http://jakarta.apache.org/site/decisions.html
, http://httpd.apache.org/dev/guidelines.html, http://xerces.apache.org/charter.html
for details.
Given that we had one speak in favor of lowering this bar (Olga) and 2
speak in favor of the bar where it is (Alan and Santhosh), for the
moment it stays where it is. If others have thoughts on this, please
contribute them.
5. In response to Ben's suggestion on pre-announcing votes, I added
the following sentence to the guidelines on voting:
"In general votes should not be called at times when it is known that
interested members of the project will be unavailable."
This is weaker than what Ben suggested, but I'm not comfortable with
having to pre-announce votes, as we want the project to be able to
move as quickly as possible. Is this strong enough for you Ben?
Alan.
On Sep 27, 2010, at 6:18 PM, Alan Gates wrote:
> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project. I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
> look and give feedback.
>
> Alan.
+
Olga Natkovich 2010-10-04, 15:47
-
Re: [DISCUSS] Apache Pig bylawsThejas M Nair 2010-10-04, 16:28
The bylaws look good, but I would like to raise two issues -
Shouldn¹t the majority requirement for changing the bylaws be more strict
than those required by the actions in bylaws ?
For example, the bylaw for removing a committer requires a consensus, but
for changing this by-law requires only 2/3rd majority. Ie, effectively,
2/3rd majority can remove a committer !
Should changing the bylaws should require consensus as well?
Should we consider another unlikely situation ? - What if two committers are
unable to communicate for long duration for some reason (stuck on some
lonely island without internet!)? Actions that require consensus approval
would not be possible. (you can't remove a inactive voter and then have
another consensus vote because two voters are missing).
Should we have a maximum duration for casting votes that require consensus ?
(2 months ?)
-Thejas
On 10/1/10 5:00 PM, "Alan Gates" <[EMAIL PROTECTED]> wrote:
> I have drafted a second version of this. I made the following changes:
>
> 1. Based on Dmitriy's feedback on clarity for code change votes, I
> changed the approval column of the code change row of the voting table
> to say:
>
> "Lazy approval (not counting the vote of the contributor), moving to
> lazy majority if a -1 is received"
>
> I think this expresses what Dmitriy believed to be the case that every
> code change requires a +1 from a committer that is not the contributor
> of the code. Note that this is stronger than what I indicated had
> been our practice in the past (to allow contributors to +1 committer's
> patches). But it seems reasonable. If a contributor knows the code
> well enough to give authoritative votes on contributions s/he should
> probably be a committer. And as far as I know this was only done on
> Zebra because it had only one committer.
>
> 2. Based on Dmitriy's feedback on the horrors of rolling back checkins
> (done by responding with a -1 on a commit message), I added the
> following sentence:
>
> "Note that this should be a rare occurrence. All efforts should be
> made to discuss issues when they are still patches before the code is
> committed."
>
> 3. Based on Olga's feedback of the need for timetables for votes, I
> defined a minimum length for each type of vote. All vote lengths are
> in business days. I set code changes at 1 day; release plan, product
> release, new committer, and new PMC member at 3 days; and adoption of
> new code base, committer removal, and PMC member removal at 6 days. I
> picked 1 day for code changes because we don't want to wait long
> periods of time to get patches in but we should wait at least a day so
> that developers all around the world can take a look. I used 3 days
> for other common votes as that is the length currently used by
> Hadoop. I picked 6 days for the others because these are momentous
> votes and 6 days guarantees one week for everyone to consider and
> respond.
>
> 4. As suggested by Olga I reviewed other Apache projects to find their
> requirements for consensus votes. Most of the projects I reviewed had
> no bylaws that I could find. httpd and Jakarta had bylaws that
> covered voting but none discussed votes such as removing committers or
> PMC members that we stipulate would require unanimous votes with no
> abstentions. Both Ant and Xerces did have bylaws for this, and both
> require unanimous votes with no abstentions to remove a committer or
> PMC member. See http://ant.apache.org/bylaws.html,
> http://jakarta.apache.org/site/decisions.html
> , http://httpd.apache.org/dev/guidelines.html,
> http://xerces.apache.org/charter.html
> for details.
>
> Given that we had one speak in favor of lowering this bar (Olga) and 2
> speak in favor of the bar where it is (Alan and Santhosh), for the
> moment it stays where it is. If others have thoughts on this, please
> contribute them.
>
> 5. In response to Ben's suggestion on pre-announcing votes, I added
> the following sentence to the guidelines on voting:
Shouldn¹t the majority requirement for changing the bylaws be more strict
than those required by the actions in bylaws ?
For example, the bylaw for removing a committer requires a consensus, but
for changing this by-law requires only 2/3rd majority. Ie, effectively,
2/3rd majority can remove a committer !
Should changing the bylaws should require consensus as well?
Should we consider another unlikely situation ? - What if two committers are
unable to communicate for long duration for some reason (stuck on some
lonely island without internet!)? Actions that require consensus approval
would not be possible. (you can't remove a inactive voter and then have
another consensus vote because two voters are missing).
Should we have a maximum duration for casting votes that require consensus ?
(2 months ?)
-Thejas
On 10/1/10 5:00 PM, "Alan Gates" <[EMAIL PROTECTED]> wrote:
> I have drafted a second version of this. I made the following changes:
>
> 1. Based on Dmitriy's feedback on clarity for code change votes, I
> changed the approval column of the code change row of the voting table
> to say:
>
> "Lazy approval (not counting the vote of the contributor), moving to
> lazy majority if a -1 is received"
>
> I think this expresses what Dmitriy believed to be the case that every
> code change requires a +1 from a committer that is not the contributor
> of the code. Note that this is stronger than what I indicated had
> been our practice in the past (to allow contributors to +1 committer's
> patches). But it seems reasonable. If a contributor knows the code
> well enough to give authoritative votes on contributions s/he should
> probably be a committer. And as far as I know this was only done on
> Zebra because it had only one committer.
>
> 2. Based on Dmitriy's feedback on the horrors of rolling back checkins
> (done by responding with a -1 on a commit message), I added the
> following sentence:
>
> "Note that this should be a rare occurrence. All efforts should be
> made to discuss issues when they are still patches before the code is
> committed."
>
> 3. Based on Olga's feedback of the need for timetables for votes, I
> defined a minimum length for each type of vote. All vote lengths are
> in business days. I set code changes at 1 day; release plan, product
> release, new committer, and new PMC member at 3 days; and adoption of
> new code base, committer removal, and PMC member removal at 6 days. I
> picked 1 day for code changes because we don't want to wait long
> periods of time to get patches in but we should wait at least a day so
> that developers all around the world can take a look. I used 3 days
> for other common votes as that is the length currently used by
> Hadoop. I picked 6 days for the others because these are momentous
> votes and 6 days guarantees one week for everyone to consider and
> respond.
>
> 4. As suggested by Olga I reviewed other Apache projects to find their
> requirements for consensus votes. Most of the projects I reviewed had
> no bylaws that I could find. httpd and Jakarta had bylaws that
> covered voting but none discussed votes such as removing committers or
> PMC members that we stipulate would require unanimous votes with no
> abstentions. Both Ant and Xerces did have bylaws for this, and both
> require unanimous votes with no abstentions to remove a committer or
> PMC member. See http://ant.apache.org/bylaws.html,
> http://jakarta.apache.org/site/decisions.html
> , http://httpd.apache.org/dev/guidelines.html,
> http://xerces.apache.org/charter.html
> for details.
>
> Given that we had one speak in favor of lowering this bar (Olga) and 2
> speak in favor of the bar where it is (Alan and Santhosh), for the
> moment it stays where it is. If others have thoughts on this, please
> contribute them.
>
> 5. In response to Ben's suggestion on pre-announcing votes, I added
> the following sentence to the guidelines on voting:
+
Thejas M Nair 2010-10-04, 16:28
-
RE: [DISCUSS] Apache Pig bylawsOlga Natkovich 2010-10-04, 18:47
I think having many rules requiring consensus is dangerous - to me it just means "this will never happen" especially as our community grows. As I mentioned before I would rather relax the consensus requirements then adding them in more places.
Olga
-----Original Message-----
From: Thejas M Nair [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 04, 2010 9:28 AM
To: [EMAIL PROTECTED]; Alan Gates
Subject: Re: [DISCUSS] Apache Pig bylaws
The bylaws look good, but I would like to raise two issues -
Shouldn¹t the majority requirement for changing the bylaws be more strict
than those required by the actions in bylaws ?
For example, the bylaw for removing a committer requires a consensus, but
for changing this by-law requires only 2/3rd majority. Ie, effectively,
2/3rd majority can remove a committer !
Should changing the bylaws should require consensus as well?
Should we consider another unlikely situation ? - What if two committers are
unable to communicate for long duration for some reason (stuck on some
lonely island without internet!)? Actions that require consensus approval
would not be possible. (you can't remove a inactive voter and then have
another consensus vote because two voters are missing).
Should we have a maximum duration for casting votes that require consensus ?
(2 months ?)
-Thejas
On 10/1/10 5:00 PM, "Alan Gates" <[EMAIL PROTECTED]> wrote:
> I have drafted a second version of this. I made the following changes:
>
> 1. Based on Dmitriy's feedback on clarity for code change votes, I
> changed the approval column of the code change row of the voting table
> to say:
>
> "Lazy approval (not counting the vote of the contributor), moving to
> lazy majority if a -1 is received"
>
> I think this expresses what Dmitriy believed to be the case that every
> code change requires a +1 from a committer that is not the contributor
> of the code. Note that this is stronger than what I indicated had
> been our practice in the past (to allow contributors to +1 committer's
> patches). But it seems reasonable. If a contributor knows the code
> well enough to give authoritative votes on contributions s/he should
> probably be a committer. And as far as I know this was only done on
> Zebra because it had only one committer.
>
> 2. Based on Dmitriy's feedback on the horrors of rolling back checkins
> (done by responding with a -1 on a commit message), I added the
> following sentence:
>
> "Note that this should be a rare occurrence. All efforts should be
> made to discuss issues when they are still patches before the code is
> committed."
>
> 3. Based on Olga's feedback of the need for timetables for votes, I
> defined a minimum length for each type of vote. All vote lengths are
> in business days. I set code changes at 1 day; release plan, product
> release, new committer, and new PMC member at 3 days; and adoption of
> new code base, committer removal, and PMC member removal at 6 days. I
> picked 1 day for code changes because we don't want to wait long
> periods of time to get patches in but we should wait at least a day so
> that developers all around the world can take a look. I used 3 days
> for other common votes as that is the length currently used by
> Hadoop. I picked 6 days for the others because these are momentous
> votes and 6 days guarantees one week for everyone to consider and
> respond.
>
> 4. As suggested by Olga I reviewed other Apache projects to find their
> requirements for consensus votes. Most of the projects I reviewed had
> no bylaws that I could find. httpd and Jakarta had bylaws that
> covered voting but none discussed votes such as removing committers or
> PMC members that we stipulate would require unanimous votes with no
> abstentions. Both Ant and Xerces did have bylaws for this, and both
> require unanimous votes with no abstentions to remove a committer or
> PMC member. See http://ant.apache.org/bylaws.html,
> http://jakarta.apache.org/site/decisions.html
> , http://httpd.apache.org/dev/guidelines.html,
Olga
-----Original Message-----
From: Thejas M Nair [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 04, 2010 9:28 AM
To: [EMAIL PROTECTED]; Alan Gates
Subject: Re: [DISCUSS] Apache Pig bylaws
The bylaws look good, but I would like to raise two issues -
Shouldn¹t the majority requirement for changing the bylaws be more strict
than those required by the actions in bylaws ?
For example, the bylaw for removing a committer requires a consensus, but
for changing this by-law requires only 2/3rd majority. Ie, effectively,
2/3rd majority can remove a committer !
Should changing the bylaws should require consensus as well?
Should we consider another unlikely situation ? - What if two committers are
unable to communicate for long duration for some reason (stuck on some
lonely island without internet!)? Actions that require consensus approval
would not be possible. (you can't remove a inactive voter and then have
another consensus vote because two voters are missing).
Should we have a maximum duration for casting votes that require consensus ?
(2 months ?)
-Thejas
On 10/1/10 5:00 PM, "Alan Gates" <[EMAIL PROTECTED]> wrote:
> I have drafted a second version of this. I made the following changes:
>
> 1. Based on Dmitriy's feedback on clarity for code change votes, I
> changed the approval column of the code change row of the voting table
> to say:
>
> "Lazy approval (not counting the vote of the contributor), moving to
> lazy majority if a -1 is received"
>
> I think this expresses what Dmitriy believed to be the case that every
> code change requires a +1 from a committer that is not the contributor
> of the code. Note that this is stronger than what I indicated had
> been our practice in the past (to allow contributors to +1 committer's
> patches). But it seems reasonable. If a contributor knows the code
> well enough to give authoritative votes on contributions s/he should
> probably be a committer. And as far as I know this was only done on
> Zebra because it had only one committer.
>
> 2. Based on Dmitriy's feedback on the horrors of rolling back checkins
> (done by responding with a -1 on a commit message), I added the
> following sentence:
>
> "Note that this should be a rare occurrence. All efforts should be
> made to discuss issues when they are still patches before the code is
> committed."
>
> 3. Based on Olga's feedback of the need for timetables for votes, I
> defined a minimum length for each type of vote. All vote lengths are
> in business days. I set code changes at 1 day; release plan, product
> release, new committer, and new PMC member at 3 days; and adoption of
> new code base, committer removal, and PMC member removal at 6 days. I
> picked 1 day for code changes because we don't want to wait long
> periods of time to get patches in but we should wait at least a day so
> that developers all around the world can take a look. I used 3 days
> for other common votes as that is the length currently used by
> Hadoop. I picked 6 days for the others because these are momentous
> votes and 6 days guarantees one week for everyone to consider and
> respond.
>
> 4. As suggested by Olga I reviewed other Apache projects to find their
> requirements for consensus votes. Most of the projects I reviewed had
> no bylaws that I could find. httpd and Jakarta had bylaws that
> covered voting but none discussed votes such as removing committers or
> PMC members that we stipulate would require unanimous votes with no
> abstentions. Both Ant and Xerces did have bylaws for this, and both
> require unanimous votes with no abstentions to remove a committer or
> PMC member. See http://ant.apache.org/bylaws.html,
> http://jakarta.apache.org/site/decisions.html
> , http://httpd.apache.org/dev/guidelines.html,
+
Olga Natkovich 2010-10-04, 18:47
-
Re: [DISCUSS] Apache Pig bylawsAlan Gates 2010-10-05, 20:15
Comments inlined. However, I feel like we're getting stuck in a
rathole on this one issue of consensus and 2/3's votes. So I would
like to ask two questions now:
1) Are there any other issues besides voting we feel should be
discussed before we move to a vote?
2) For those who have expressed concern about the voting, are these
concerns enough to make you not vote for these bylaws, or can you live
with it as is? I am concerned that this discussion could go on with
point and counter point ad infinitum. I'm more interested in having
bylaws than in having perfect bylaws. We can amend them as necessary
as we go.
Alan.
On Oct 4, 2010, at 9:28 AM, Thejas M Nair wrote:
> The bylaws look good, but I would like to raise two issues -
>
> Shouldn¹t the majority requirement for changing the bylaws be more
> strict
> than those required by the actions in bylaws ?
> For example, the bylaw for removing a committer requires a
> consensus, but
> for changing this by-law requires only 2/3rd majority. Ie,
> effectively,
> 2/3rd majority can remove a committer !
> Should changing the bylaws should require consensus as well?
I don't want to make it consensus to change the bylaws, as that would
make changing bylaws _very_ hard. I want removing a committer to be
_very_ hard.
And, in defense of having changing procedure require a lower vote than
the procedure, I would invoke the practices of the US Senate. A
simple majority vote would suffice to remove the need for 3/5 majority
(60 votes) for cloture, yet even when one party has 50 but not 60
votes (as has been common lately) neither has removed it for fear of
having it used against them later. See http://en.wikipedia.org/wiki/Cloture#United_States
for details.
>
> Should we consider another unlikely situation ? - What if two
> committers are
> unable to communicate for long duration for some reason (stuck on some
> lonely island without internet!)? Actions that require consensus
> approval
> would not be possible. (you can't remove a inactive voter and then
> have
> another consensus vote because two voters are missing).
> Should we have a maximum duration for casting votes that require
> consensus ?
> (2 months ?)
My attempt to deal with the Lost scenario was the addition of the
sentence saying that votes should not be called when we knew members
would be unavailable.
Also, I want to clarify the difference between inactive committers/PMC
members and members being removed. Moving to emeritus status is
automatic upon inactivity. ("A PMC member is considered 'emeritus' by
their own declaration or by not contributing in any form to the
project for over six months. An emeritus member may request
reinstatement to the PMC, which will be sufficient to restore him or
her to active PMC member.") Also, moving to emeritus status is not
considered a bad thing. It simply reflects that the person is no
longer able to be a part of the project on a regular basis. Removing
someone by vote is a bad thing, akin to being voted off the island (to
switch island TV show analogies), is certainly not automatic, and
should only happen in extreme circumstances.
Alan.
rathole on this one issue of consensus and 2/3's votes. So I would
like to ask two questions now:
1) Are there any other issues besides voting we feel should be
discussed before we move to a vote?
2) For those who have expressed concern about the voting, are these
concerns enough to make you not vote for these bylaws, or can you live
with it as is? I am concerned that this discussion could go on with
point and counter point ad infinitum. I'm more interested in having
bylaws than in having perfect bylaws. We can amend them as necessary
as we go.
Alan.
On Oct 4, 2010, at 9:28 AM, Thejas M Nair wrote:
> The bylaws look good, but I would like to raise two issues -
>
> Shouldn¹t the majority requirement for changing the bylaws be more
> strict
> than those required by the actions in bylaws ?
> For example, the bylaw for removing a committer requires a
> consensus, but
> for changing this by-law requires only 2/3rd majority. Ie,
> effectively,
> 2/3rd majority can remove a committer !
> Should changing the bylaws should require consensus as well?
I don't want to make it consensus to change the bylaws, as that would
make changing bylaws _very_ hard. I want removing a committer to be
_very_ hard.
And, in defense of having changing procedure require a lower vote than
the procedure, I would invoke the practices of the US Senate. A
simple majority vote would suffice to remove the need for 3/5 majority
(60 votes) for cloture, yet even when one party has 50 but not 60
votes (as has been common lately) neither has removed it for fear of
having it used against them later. See http://en.wikipedia.org/wiki/Cloture#United_States
for details.
>
> Should we consider another unlikely situation ? - What if two
> committers are
> unable to communicate for long duration for some reason (stuck on some
> lonely island without internet!)? Actions that require consensus
> approval
> would not be possible. (you can't remove a inactive voter and then
> have
> another consensus vote because two voters are missing).
> Should we have a maximum duration for casting votes that require
> consensus ?
> (2 months ?)
My attempt to deal with the Lost scenario was the addition of the
sentence saying that votes should not be called when we knew members
would be unavailable.
Also, I want to clarify the difference between inactive committers/PMC
members and members being removed. Moving to emeritus status is
automatic upon inactivity. ("A PMC member is considered 'emeritus' by
their own declaration or by not contributing in any form to the
project for over six months. An emeritus member may request
reinstatement to the PMC, which will be sufficient to restore him or
her to active PMC member.") Also, moving to emeritus status is not
considered a bad thing. It simply reflects that the person is no
longer able to be a part of the project on a regular basis. Removing
someone by vote is a bad thing, akin to being voted off the island (to
switch island TV show analogies), is certainly not automatic, and
should only happen in extreme circumstances.
Alan.
+
Alan Gates 2010-10-05, 20:15
-
RE: [DISCUSS] Apache Pig bylawsOlga Natkovich 2010-10-05, 20:24
I am fine with them "as-is"
Olga
-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 05, 2010 1:16 PM
To: Thejas M Nair
Cc: [EMAIL PROTECTED]
Subject: Re: [DISCUSS] Apache Pig bylaws
Comments inlined. However, I feel like we're getting stuck in a
rathole on this one issue of consensus and 2/3's votes. So I would
like to ask two questions now:
1) Are there any other issues besides voting we feel should be
discussed before we move to a vote?
2) For those who have expressed concern about the voting, are these
concerns enough to make you not vote for these bylaws, or can you live
with it as is? I am concerned that this discussion could go on with
point and counter point ad infinitum. I'm more interested in having
bylaws than in having perfect bylaws. We can amend them as necessary
as we go.
Alan.
On Oct 4, 2010, at 9:28 AM, Thejas M Nair wrote:
> The bylaws look good, but I would like to raise two issues -
>
> Shouldn¹t the majority requirement for changing the bylaws be more
> strict
> than those required by the actions in bylaws ?
> For example, the bylaw for removing a committer requires a
> consensus, but
> for changing this by-law requires only 2/3rd majority. Ie,
> effectively,
> 2/3rd majority can remove a committer !
> Should changing the bylaws should require consensus as well?
I don't want to make it consensus to change the bylaws, as that would
make changing bylaws _very_ hard. I want removing a committer to be
_very_ hard.
And, in defense of having changing procedure require a lower vote than
the procedure, I would invoke the practices of the US Senate. A
simple majority vote would suffice to remove the need for 3/5 majority
(60 votes) for cloture, yet even when one party has 50 but not 60
votes (as has been common lately) neither has removed it for fear of
having it used against them later. See http://en.wikipedia.org/wiki/Cloture#United_States
for details.
>
> Should we consider another unlikely situation ? - What if two
> committers are
> unable to communicate for long duration for some reason (stuck on some
> lonely island without internet!)? Actions that require consensus
> approval
> would not be possible. (you can't remove a inactive voter and then
> have
> another consensus vote because two voters are missing).
> Should we have a maximum duration for casting votes that require
> consensus ?
> (2 months ?)
My attempt to deal with the Lost scenario was the addition of the
sentence saying that votes should not be called when we knew members
would be unavailable.
Also, I want to clarify the difference between inactive committers/PMC
members and members being removed. Moving to emeritus status is
automatic upon inactivity. ("A PMC member is considered 'emeritus' by
their own declaration or by not contributing in any form to the
project for over six months. An emeritus member may request
reinstatement to the PMC, which will be sufficient to restore him or
her to active PMC member.") Also, moving to emeritus status is not
considered a bad thing. It simply reflects that the person is no
longer able to be a part of the project on a regular basis. Removing
someone by vote is a bad thing, akin to being voted off the island (to
switch island TV show analogies), is certainly not automatic, and
should only happen in extreme circumstances.
Alan.
Olga
-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 05, 2010 1:16 PM
To: Thejas M Nair
Cc: [EMAIL PROTECTED]
Subject: Re: [DISCUSS] Apache Pig bylaws
Comments inlined. However, I feel like we're getting stuck in a
rathole on this one issue of consensus and 2/3's votes. So I would
like to ask two questions now:
1) Are there any other issues besides voting we feel should be
discussed before we move to a vote?
2) For those who have expressed concern about the voting, are these
concerns enough to make you not vote for these bylaws, or can you live
with it as is? I am concerned that this discussion could go on with
point and counter point ad infinitum. I'm more interested in having
bylaws than in having perfect bylaws. We can amend them as necessary
as we go.
Alan.
On Oct 4, 2010, at 9:28 AM, Thejas M Nair wrote:
> The bylaws look good, but I would like to raise two issues -
>
> Shouldn¹t the majority requirement for changing the bylaws be more
> strict
> than those required by the actions in bylaws ?
> For example, the bylaw for removing a committer requires a
> consensus, but
> for changing this by-law requires only 2/3rd majority. Ie,
> effectively,
> 2/3rd majority can remove a committer !
> Should changing the bylaws should require consensus as well?
I don't want to make it consensus to change the bylaws, as that would
make changing bylaws _very_ hard. I want removing a committer to be
_very_ hard.
And, in defense of having changing procedure require a lower vote than
the procedure, I would invoke the practices of the US Senate. A
simple majority vote would suffice to remove the need for 3/5 majority
(60 votes) for cloture, yet even when one party has 50 but not 60
votes (as has been common lately) neither has removed it for fear of
having it used against them later. See http://en.wikipedia.org/wiki/Cloture#United_States
for details.
>
> Should we consider another unlikely situation ? - What if two
> committers are
> unable to communicate for long duration for some reason (stuck on some
> lonely island without internet!)? Actions that require consensus
> approval
> would not be possible. (you can't remove a inactive voter and then
> have
> another consensus vote because two voters are missing).
> Should we have a maximum duration for casting votes that require
> consensus ?
> (2 months ?)
My attempt to deal with the Lost scenario was the addition of the
sentence saying that votes should not be called when we knew members
would be unavailable.
Also, I want to clarify the difference between inactive committers/PMC
members and members being removed. Moving to emeritus status is
automatic upon inactivity. ("A PMC member is considered 'emeritus' by
their own declaration or by not contributing in any form to the
project for over six months. An emeritus member may request
reinstatement to the PMC, which will be sufficient to restore him or
her to active PMC member.") Also, moving to emeritus status is not
considered a bad thing. It simply reflects that the person is no
longer able to be a part of the project on a regular basis. Removing
someone by vote is a bad thing, akin to being voted off the island (to
switch island TV show analogies), is certainly not automatic, and
should only happen in extreme circumstances.
Alan.
+
Olga Natkovich 2010-10-05, 20:24
-
Re: [DISCUSS] Apache Pig bylawsBenjamin Reed 2010-10-05, 20:32
i think it is great as it is.
ben
On 10/05/2010 01:24 PM, Olga Natkovich wrote:
> I am fine with them "as-is"
>
> Olga
>
> -----Original Message-----
> From: Alan Gates [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 05, 2010 1:16 PM
> To: Thejas M Nair
> Cc: [EMAIL PROTECTED]
> Subject: Re: [DISCUSS] Apache Pig bylaws
>
> Comments inlined. However, I feel like we're getting stuck in a
> rathole on this one issue of consensus and 2/3's votes. So I would
> like to ask two questions now:
>
> 1) Are there any other issues besides voting we feel should be
> discussed before we move to a vote?
> 2) For those who have expressed concern about the voting, are these
> concerns enough to make you not vote for these bylaws, or can you live
> with it as is? I am concerned that this discussion could go on with
> point and counter point ad infinitum. I'm more interested in having
> bylaws than in having perfect bylaws. We can amend them as necessary
> as we go.
>
> Alan.
>
>
> On Oct 4, 2010, at 9:28 AM, Thejas M Nair wrote:
>
>> The bylaws look good, but I would like to raise two issues -
>>
>> Shouldn�t the majority requirement for changing the bylaws be more
>> strict
>> than those required by the actions in bylaws ?
>> For example, the bylaw for removing a committer requires a
>> consensus, but
>> for changing this by-law requires only 2/3rd majority. Ie,
>> effectively,
>> 2/3rd majority can remove a committer !
>> Should changing the bylaws should require consensus as well?
> I don't want to make it consensus to change the bylaws, as that would
> make changing bylaws _very_ hard. I want removing a committer to be
> _very_ hard.
>
> And, in defense of having changing procedure require a lower vote than
> the procedure, I would invoke the practices of the US Senate. A
> simple majority vote would suffice to remove the need for 3/5 majority
> (60 votes) for cloture, yet even when one party has 50 but not 60
> votes (as has been common lately) neither has removed it for fear of
> having it used against them later. See http://en.wikipedia.org/wiki/Cloture#United_States
> for details.
>
>> Should we consider another unlikely situation ? - What if two
>> committers are
>> unable to communicate for long duration for some reason (stuck on some
>> lonely island without internet!)? Actions that require consensus
>> approval
>> would not be possible. (you can't remove a inactive voter and then
>> have
>> another consensus vote because two voters are missing).
>> Should we have a maximum duration for casting votes that require
>> consensus ?
>> (2 months ?)
> My attempt to deal with the Lost scenario was the addition of the
> sentence saying that votes should not be called when we knew members
> would be unavailable.
>
> Also, I want to clarify the difference between inactive committers/PMC
> members and members being removed. Moving to emeritus status is
> automatic upon inactivity. ("A PMC member is considered 'emeritus' by
> their own declaration or by not contributing in any form to the
> project for over six months. An emeritus member may request
> reinstatement to the PMC, which will be sufficient to restore him or
> her to active PMC member.") Also, moving to emeritus status is not
> considered a bad thing. It simply reflects that the person is no
> longer able to be a part of the project on a regular basis. Removing
> someone by vote is a bad thing, akin to being voted off the island (to
> switch island TV show analogies), is certainly not automatic, and
> should only happen in extreme circumstances.
>
> Alan.
>
ben
On 10/05/2010 01:24 PM, Olga Natkovich wrote:
> I am fine with them "as-is"
>
> Olga
>
> -----Original Message-----
> From: Alan Gates [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 05, 2010 1:16 PM
> To: Thejas M Nair
> Cc: [EMAIL PROTECTED]
> Subject: Re: [DISCUSS] Apache Pig bylaws
>
> Comments inlined. However, I feel like we're getting stuck in a
> rathole on this one issue of consensus and 2/3's votes. So I would
> like to ask two questions now:
>
> 1) Are there any other issues besides voting we feel should be
> discussed before we move to a vote?
> 2) For those who have expressed concern about the voting, are these
> concerns enough to make you not vote for these bylaws, or can you live
> with it as is? I am concerned that this discussion could go on with
> point and counter point ad infinitum. I'm more interested in having
> bylaws than in having perfect bylaws. We can amend them as necessary
> as we go.
>
> Alan.
>
>
> On Oct 4, 2010, at 9:28 AM, Thejas M Nair wrote:
>
>> The bylaws look good, but I would like to raise two issues -
>>
>> Shouldn�t the majority requirement for changing the bylaws be more
>> strict
>> than those required by the actions in bylaws ?
>> For example, the bylaw for removing a committer requires a
>> consensus, but
>> for changing this by-law requires only 2/3rd majority. Ie,
>> effectively,
>> 2/3rd majority can remove a committer !
>> Should changing the bylaws should require consensus as well?
> I don't want to make it consensus to change the bylaws, as that would
> make changing bylaws _very_ hard. I want removing a committer to be
> _very_ hard.
>
> And, in defense of having changing procedure require a lower vote than
> the procedure, I would invoke the practices of the US Senate. A
> simple majority vote would suffice to remove the need for 3/5 majority
> (60 votes) for cloture, yet even when one party has 50 but not 60
> votes (as has been common lately) neither has removed it for fear of
> having it used against them later. See http://en.wikipedia.org/wiki/Cloture#United_States
> for details.
>
>> Should we consider another unlikely situation ? - What if two
>> committers are
>> unable to communicate for long duration for some reason (stuck on some
>> lonely island without internet!)? Actions that require consensus
>> approval
>> would not be possible. (you can't remove a inactive voter and then
>> have
>> another consensus vote because two voters are missing).
>> Should we have a maximum duration for casting votes that require
>> consensus ?
>> (2 months ?)
> My attempt to deal with the Lost scenario was the addition of the
> sentence saying that votes should not be called when we knew members
> would be unavailable.
>
> Also, I want to clarify the difference between inactive committers/PMC
> members and members being removed. Moving to emeritus status is
> automatic upon inactivity. ("A PMC member is considered 'emeritus' by
> their own declaration or by not contributing in any form to the
> project for over six months. An emeritus member may request
> reinstatement to the PMC, which will be sufficient to restore him or
> her to active PMC member.") Also, moving to emeritus status is not
> considered a bad thing. It simply reflects that the person is no
> longer able to be a part of the project on a regular basis. Removing
> someone by vote is a bad thing, akin to being voted off the island (to
> switch island TV show analogies), is certainly not automatic, and
> should only happen in extreme circumstances.
>
> Alan.
>
+
Benjamin Reed 2010-10-05, 20:32
-
Re: [DISCUSS] Apache Pig bylawsDaniel Dai 2010-10-05, 20:41
+1
Olga Natkovich wrote:
> I am fine with them "as-is"
>
> Olga
>
> -----Original Message-----
> From: Alan Gates [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 05, 2010 1:16 PM
> To: Thejas M Nair
> Cc: [EMAIL PROTECTED]
> Subject: Re: [DISCUSS] Apache Pig bylaws
>
> Comments inlined. However, I feel like we're getting stuck in a
> rathole on this one issue of consensus and 2/3's votes. So I would
> like to ask two questions now:
>
> 1) Are there any other issues besides voting we feel should be
> discussed before we move to a vote?
> 2) For those who have expressed concern about the voting, are these
> concerns enough to make you not vote for these bylaws, or can you live
> with it as is? I am concerned that this discussion could go on with
> point and counter point ad infinitum. I'm more interested in having
> bylaws than in having perfect bylaws. We can amend them as necessary
> as we go.
>
> Alan.
>
>
> On Oct 4, 2010, at 9:28 AM, Thejas M Nair wrote:
>
>
>> The bylaws look good, but I would like to raise two issues -
>>
>> Shouldn�t the majority requirement for changing the bylaws be more
>> strict
>> than those required by the actions in bylaws ?
>> For example, the bylaw for removing a committer requires a
>> consensus, but
>> for changing this by-law requires only 2/3rd majority. Ie,
>> effectively,
>> 2/3rd majority can remove a committer !
>> Should changing the bylaws should require consensus as well?
>>
>
> I don't want to make it consensus to change the bylaws, as that would
> make changing bylaws _very_ hard. I want removing a committer to be
> _very_ hard.
>
> And, in defense of having changing procedure require a lower vote than
> the procedure, I would invoke the practices of the US Senate. A
> simple majority vote would suffice to remove the need for 3/5 majority
> (60 votes) for cloture, yet even when one party has 50 but not 60
> votes (as has been common lately) neither has removed it for fear of
> having it used against them later. See http://en.wikipedia.org/wiki/Cloture#United_States
> for details.
>
>
>> Should we consider another unlikely situation ? - What if two
>> committers are
>> unable to communicate for long duration for some reason (stuck on some
>> lonely island without internet!)? Actions that require consensus
>> approval
>> would not be possible. (you can't remove a inactive voter and then
>> have
>> another consensus vote because two voters are missing).
>> Should we have a maximum duration for casting votes that require
>> consensus ?
>> (2 months ?)
>>
>
> My attempt to deal with the Lost scenario was the addition of the
> sentence saying that votes should not be called when we knew members
> would be unavailable.
>
> Also, I want to clarify the difference between inactive committers/PMC
> members and members being removed. Moving to emeritus status is
> automatic upon inactivity. ("A PMC member is considered 'emeritus' by
> their own declaration or by not contributing in any form to the
> project for over six months. An emeritus member may request
> reinstatement to the PMC, which will be sufficient to restore him or
> her to active PMC member.") Also, moving to emeritus status is not
> considered a bad thing. It simply reflects that the person is no
> longer able to be a part of the project on a regular basis. Removing
> someone by vote is a bad thing, akin to being voted off the island (to
> switch island TV show analogies), is certainly not automatic, and
> should only happen in extreme circumstances.
>
> Alan.
>
>
Olga Natkovich wrote:
> I am fine with them "as-is"
>
> Olga
>
> -----Original Message-----
> From: Alan Gates [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 05, 2010 1:16 PM
> To: Thejas M Nair
> Cc: [EMAIL PROTECTED]
> Subject: Re: [DISCUSS] Apache Pig bylaws
>
> Comments inlined. However, I feel like we're getting stuck in a
> rathole on this one issue of consensus and 2/3's votes. So I would
> like to ask two questions now:
>
> 1) Are there any other issues besides voting we feel should be
> discussed before we move to a vote?
> 2) For those who have expressed concern about the voting, are these
> concerns enough to make you not vote for these bylaws, or can you live
> with it as is? I am concerned that this discussion could go on with
> point and counter point ad infinitum. I'm more interested in having
> bylaws than in having perfect bylaws. We can amend them as necessary
> as we go.
>
> Alan.
>
>
> On Oct 4, 2010, at 9:28 AM, Thejas M Nair wrote:
>
>
>> The bylaws look good, but I would like to raise two issues -
>>
>> Shouldn�t the majority requirement for changing the bylaws be more
>> strict
>> than those required by the actions in bylaws ?
>> For example, the bylaw for removing a committer requires a
>> consensus, but
>> for changing this by-law requires only 2/3rd majority. Ie,
>> effectively,
>> 2/3rd majority can remove a committer !
>> Should changing the bylaws should require consensus as well?
>>
>
> I don't want to make it consensus to change the bylaws, as that would
> make changing bylaws _very_ hard. I want removing a committer to be
> _very_ hard.
>
> And, in defense of having changing procedure require a lower vote than
> the procedure, I would invoke the practices of the US Senate. A
> simple majority vote would suffice to remove the need for 3/5 majority
> (60 votes) for cloture, yet even when one party has 50 but not 60
> votes (as has been common lately) neither has removed it for fear of
> having it used against them later. See http://en.wikipedia.org/wiki/Cloture#United_States
> for details.
>
>
>> Should we consider another unlikely situation ? - What if two
>> committers are
>> unable to communicate for long duration for some reason (stuck on some
>> lonely island without internet!)? Actions that require consensus
>> approval
>> would not be possible. (you can't remove a inactive voter and then
>> have
>> another consensus vote because two voters are missing).
>> Should we have a maximum duration for casting votes that require
>> consensus ?
>> (2 months ?)
>>
>
> My attempt to deal with the Lost scenario was the addition of the
> sentence saying that votes should not be called when we knew members
> would be unavailable.
>
> Also, I want to clarify the difference between inactive committers/PMC
> members and members being removed. Moving to emeritus status is
> automatic upon inactivity. ("A PMC member is considered 'emeritus' by
> their own declaration or by not contributing in any form to the
> project for over six months. An emeritus member may request
> reinstatement to the PMC, which will be sufficient to restore him or
> her to active PMC member.") Also, moving to emeritus status is not
> considered a bad thing. It simply reflects that the person is no
> longer able to be a part of the project on a regular basis. Removing
> someone by vote is a bad thing, akin to being voted off the island (to
> switch island TV show analogies), is certainly not automatic, and
> should only happen in extreme circumstances.
>
> Alan.
>
>
+
Daniel Dai 2010-10-05, 20:41
-
Re: [DISCUSS] Apache Pig bylawsThejas M Nair 2010-10-05, 20:55
+1
-Thejas
On 10/5/10 1:15 PM, "Alan Gates" <[EMAIL PROTECTED]> wrote:
Comments inlined. However, I feel like we're getting stuck in a
rathole on this one issue of consensus and 2/3's votes. So I would
like to ask two questions now:
1) Are there any other issues besides voting we feel should be
discussed before we move to a vote?
2) For those who have expressed concern about the voting, are these
concerns enough to make you not vote for these bylaws, or can you live
with it as is? I am concerned that this discussion could go on with
point and counter point ad infinitum. I'm more interested in having
bylaws than in having perfect bylaws. We can amend them as necessary
as we go.
Alan.
On Oct 4, 2010, at 9:28 AM, Thejas M Nair wrote:
> The bylaws look good, but I would like to raise two issues -
>
> Shouldn't the majority requirement for changing the bylaws be more
> strict
> than those required by the actions in bylaws ?
> For example, the bylaw for removing a committer requires a
> consensus, but
> for changing this by-law requires only 2/3rd majority. Ie,
> effectively,
> 2/3rd majority can remove a committer !
> Should changing the bylaws should require consensus as well?
I don't want to make it consensus to change the bylaws, as that would
make changing bylaws _very_ hard. I want removing a committer to be
_very_ hard.
And, in defense of having changing procedure require a lower vote than
the procedure, I would invoke the practices of the US Senate. A
simple majority vote would suffice to remove the need for 3/5 majority
(60 votes) for cloture, yet even when one party has 50 but not 60
votes (as has been common lately) neither has removed it for fear of
having it used against them later. See http://en.wikipedia.org/wiki/Cloture#United_States
for details.
>
> Should we consider another unlikely situation ? - What if two
> committers are
> unable to communicate for long duration for some reason (stuck on some
> lonely island without internet!)? Actions that require consensus
> approval
> would not be possible. (you can't remove a inactive voter and then
> have
> another consensus vote because two voters are missing).
> Should we have a maximum duration for casting votes that require
> consensus ?
> (2 months ?)
My attempt to deal with the Lost scenario was the addition of the
sentence saying that votes should not be called when we knew members
would be unavailable.
Also, I want to clarify the difference between inactive committers/PMC
members and members being removed. Moving to emeritus status is
automatic upon inactivity. ("A PMC member is considered 'emeritus' by
their own declaration or by not contributing in any form to the
project for over six months. An emeritus member may request
reinstatement to the PMC, which will be sufficient to restore him or
her to active PMC member.") Also, moving to emeritus status is not
considered a bad thing. It simply reflects that the person is no
longer able to be a part of the project on a regular basis. Removing
someone by vote is a bad thing, akin to being voted off the island (to
switch island TV show analogies), is certainly not automatic, and
should only happen in extreme circumstances.
Alan.
-Thejas
On 10/5/10 1:15 PM, "Alan Gates" <[EMAIL PROTECTED]> wrote:
Comments inlined. However, I feel like we're getting stuck in a
rathole on this one issue of consensus and 2/3's votes. So I would
like to ask two questions now:
1) Are there any other issues besides voting we feel should be
discussed before we move to a vote?
2) For those who have expressed concern about the voting, are these
concerns enough to make you not vote for these bylaws, or can you live
with it as is? I am concerned that this discussion could go on with
point and counter point ad infinitum. I'm more interested in having
bylaws than in having perfect bylaws. We can amend them as necessary
as we go.
Alan.
On Oct 4, 2010, at 9:28 AM, Thejas M Nair wrote:
> The bylaws look good, but I would like to raise two issues -
>
> Shouldn't the majority requirement for changing the bylaws be more
> strict
> than those required by the actions in bylaws ?
> For example, the bylaw for removing a committer requires a
> consensus, but
> for changing this by-law requires only 2/3rd majority. Ie,
> effectively,
> 2/3rd majority can remove a committer !
> Should changing the bylaws should require consensus as well?
I don't want to make it consensus to change the bylaws, as that would
make changing bylaws _very_ hard. I want removing a committer to be
_very_ hard.
And, in defense of having changing procedure require a lower vote than
the procedure, I would invoke the practices of the US Senate. A
simple majority vote would suffice to remove the need for 3/5 majority
(60 votes) for cloture, yet even when one party has 50 but not 60
votes (as has been common lately) neither has removed it for fear of
having it used against them later. See http://en.wikipedia.org/wiki/Cloture#United_States
for details.
>
> Should we consider another unlikely situation ? - What if two
> committers are
> unable to communicate for long duration for some reason (stuck on some
> lonely island without internet!)? Actions that require consensus
> approval
> would not be possible. (you can't remove a inactive voter and then
> have
> another consensus vote because two voters are missing).
> Should we have a maximum duration for casting votes that require
> consensus ?
> (2 months ?)
My attempt to deal with the Lost scenario was the addition of the
sentence saying that votes should not be called when we knew members
would be unavailable.
Also, I want to clarify the difference between inactive committers/PMC
members and members being removed. Moving to emeritus status is
automatic upon inactivity. ("A PMC member is considered 'emeritus' by
their own declaration or by not contributing in any form to the
project for over six months. An emeritus member may request
reinstatement to the PMC, which will be sufficient to restore him or
her to active PMC member.") Also, moving to emeritus status is not
considered a bad thing. It simply reflects that the person is no
longer able to be a part of the project on a regular basis. Removing
someone by vote is a bad thing, akin to being voted off the island (to
switch island TV show analogies), is certainly not automatic, and
should only happen in extreme circumstances.
Alan.
+
Thejas M Nair 2010-10-05, 20:55
-
Re: [DISCUSS] Apache Pig bylawsDmitriy Ryaboy 2010-10-05, 21:38
+1
On Tue, Oct 5, 2010 at 1:55 PM, Thejas M Nair <[EMAIL PROTECTED]> wrote:
> +1
>
> -Thejas
>
>
>
> On 10/5/10 1:15 PM, "Alan Gates" <[EMAIL PROTECTED]> wrote:
>
> Comments inlined. However, I feel like we're getting stuck in a
> rathole on this one issue of consensus and 2/3's votes. So I would
> like to ask two questions now:
>
> 1) Are there any other issues besides voting we feel should be
> discussed before we move to a vote?
> 2) For those who have expressed concern about the voting, are these
> concerns enough to make you not vote for these bylaws, or can you live
> with it as is? I am concerned that this discussion could go on with
> point and counter point ad infinitum. I'm more interested in having
> bylaws than in having perfect bylaws. We can amend them as necessary
> as we go.
>
> Alan.
>
>
> On Oct 4, 2010, at 9:28 AM, Thejas M Nair wrote:
>
> > The bylaws look good, but I would like to raise two issues -
> >
> > Shouldn't the majority requirement for changing the bylaws be more
> > strict
> > than those required by the actions in bylaws ?
> > For example, the bylaw for removing a committer requires a
> > consensus, but
> > for changing this by-law requires only 2/3rd majority. Ie,
> > effectively,
> > 2/3rd majority can remove a committer !
> > Should changing the bylaws should require consensus as well?
>
> I don't want to make it consensus to change the bylaws, as that would
> make changing bylaws _very_ hard. I want removing a committer to be
> _very_ hard.
>
> And, in defense of having changing procedure require a lower vote than
> the procedure, I would invoke the practices of the US Senate. A
> simple majority vote would suffice to remove the need for 3/5 majority
> (60 votes) for cloture, yet even when one party has 50 but not 60
> votes (as has been common lately) neither has removed it for fear of
> having it used against them later. See
> http://en.wikipedia.org/wiki/Cloture#United_States
> for details.
>
> >
> > Should we consider another unlikely situation ? - What if two
> > committers are
> > unable to communicate for long duration for some reason (stuck on some
> > lonely island without internet!)? Actions that require consensus
> > approval
> > would not be possible. (you can't remove a inactive voter and then
> > have
> > another consensus vote because two voters are missing).
> > Should we have a maximum duration for casting votes that require
> > consensus ?
> > (2 months ?)
>
> My attempt to deal with the Lost scenario was the addition of the
> sentence saying that votes should not be called when we knew members
> would be unavailable.
>
> Also, I want to clarify the difference between inactive committers/PMC
> members and members being removed. Moving to emeritus status is
> automatic upon inactivity. ("A PMC member is considered 'emeritus' by
> their own declaration or by not contributing in any form to the
> project for over six months. An emeritus member may request
> reinstatement to the PMC, which will be sufficient to restore him or
> her to active PMC member.") Also, moving to emeritus status is not
> considered a bad thing. It simply reflects that the person is no
> longer able to be a part of the project on a regular basis. Removing
> someone by vote is a bad thing, akin to being voted off the island (to
> switch island TV show analogies), is certainly not automatic, and
> should only happen in extreme circumstances.
>
> Alan.
>
>
>
>
On Tue, Oct 5, 2010 at 1:55 PM, Thejas M Nair <[EMAIL PROTECTED]> wrote:
> +1
>
> -Thejas
>
>
>
> On 10/5/10 1:15 PM, "Alan Gates" <[EMAIL PROTECTED]> wrote:
>
> Comments inlined. However, I feel like we're getting stuck in a
> rathole on this one issue of consensus and 2/3's votes. So I would
> like to ask two questions now:
>
> 1) Are there any other issues besides voting we feel should be
> discussed before we move to a vote?
> 2) For those who have expressed concern about the voting, are these
> concerns enough to make you not vote for these bylaws, or can you live
> with it as is? I am concerned that this discussion could go on with
> point and counter point ad infinitum. I'm more interested in having
> bylaws than in having perfect bylaws. We can amend them as necessary
> as we go.
>
> Alan.
>
>
> On Oct 4, 2010, at 9:28 AM, Thejas M Nair wrote:
>
> > The bylaws look good, but I would like to raise two issues -
> >
> > Shouldn't the majority requirement for changing the bylaws be more
> > strict
> > than those required by the actions in bylaws ?
> > For example, the bylaw for removing a committer requires a
> > consensus, but
> > for changing this by-law requires only 2/3rd majority. Ie,
> > effectively,
> > 2/3rd majority can remove a committer !
> > Should changing the bylaws should require consensus as well?
>
> I don't want to make it consensus to change the bylaws, as that would
> make changing bylaws _very_ hard. I want removing a committer to be
> _very_ hard.
>
> And, in defense of having changing procedure require a lower vote than
> the procedure, I would invoke the practices of the US Senate. A
> simple majority vote would suffice to remove the need for 3/5 majority
> (60 votes) for cloture, yet even when one party has 50 but not 60
> votes (as has been common lately) neither has removed it for fear of
> having it used against them later. See
> http://en.wikipedia.org/wiki/Cloture#United_States
> for details.
>
> >
> > Should we consider another unlikely situation ? - What if two
> > committers are
> > unable to communicate for long duration for some reason (stuck on some
> > lonely island without internet!)? Actions that require consensus
> > approval
> > would not be possible. (you can't remove a inactive voter and then
> > have
> > another consensus vote because two voters are missing).
> > Should we have a maximum duration for casting votes that require
> > consensus ?
> > (2 months ?)
>
> My attempt to deal with the Lost scenario was the addition of the
> sentence saying that votes should not be called when we knew members
> would be unavailable.
>
> Also, I want to clarify the difference between inactive committers/PMC
> members and members being removed. Moving to emeritus status is
> automatic upon inactivity. ("A PMC member is considered 'emeritus' by
> their own declaration or by not contributing in any form to the
> project for over six months. An emeritus member may request
> reinstatement to the PMC, which will be sufficient to restore him or
> her to active PMC member.") Also, moving to emeritus status is not
> considered a bad thing. It simply reflects that the person is no
> longer able to be a part of the project on a regular basis. Removing
> someone by vote is a bad thing, akin to being voted off the island (to
> switch island TV show analogies), is certainly not automatic, and
> should only happen in extreme circumstances.
>
> Alan.
>
>
>
>
+
Dmitriy Ryaboy 2010-10-05, 21:38
-
RE: [DISCUSS] Apache Pig bylawsSanthosh Srinivasan 2010-09-28, 02:27
Looks good at a first glance. Changes to remove references to "Lazy consensus..." is neat.
Santhosh
-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 27, 2010 6:18 PM
To: [EMAIL PROTECTED]
Subject: [DISCUSS] Apache Pig bylaws
As directed in our vote to become a TLP, we (Pig's PMC) need to set out bylaws for the project. I have put up a first proposal for these by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a look and give feedback.
Alan.
Santhosh
-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 27, 2010 6:18 PM
To: [EMAIL PROTECTED]
Subject: [DISCUSS] Apache Pig bylaws
As directed in our vote to become a TLP, we (Pig's PMC) need to set out bylaws for the project. I have put up a first proposal for these by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a look and give feedback.
Alan.
+
Santhosh Srinivasan 2010-09-28, 02:27
-
RE: [DISCUSS] Apache Pig bylawsOlga Natkovich 2010-09-28, 23:39
Alan,
Thanks for the proposal. Looks good! I have a couple of comments/questions:
(1) I think all votes need to have a time boundary. For releases and committers, we used to use 3 business days. I am fine if we choose different/longer times and different time periods for different types of votes but I think we should state what they are in the document.
(2) Seems like consensus and even 2/3 votes is very hard to achieve. I wonder if simple majority would do just as well for all the cases we have.
Olga
-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 27, 2010 6:18 PM
To: [EMAIL PROTECTED]
Subject: [DISCUSS] Apache Pig bylaws
As directed in our vote to become a TLP, we (Pig's PMC) need to set
out bylaws for the project. I have put up a first proposal for these
by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
look and give feedback.
Alan.
Thanks for the proposal. Looks good! I have a couple of comments/questions:
(1) I think all votes need to have a time boundary. For releases and committers, we used to use 3 business days. I am fine if we choose different/longer times and different time periods for different types of votes but I think we should state what they are in the document.
(2) Seems like consensus and even 2/3 votes is very hard to achieve. I wonder if simple majority would do just as well for all the cases we have.
Olga
-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 27, 2010 6:18 PM
To: [EMAIL PROTECTED]
Subject: [DISCUSS] Apache Pig bylaws
As directed in our vote to become a TLP, we (Pig's PMC) need to set
out bylaws for the project. I have put up a first proposal for these
by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
look and give feedback.
Alan.
+
Olga Natkovich 2010-09-28, 23:39
-
Re: [DISCUSS] Apache Pig bylawsDmitriy Ryaboy 2010-09-29, 00:20
A couple of notes:
I've been operating under the assumption that at least 1 "+1" committer vote
(not including author of contribution) is required for codebase changes.
This is a sensible rule imho.. but apparently not a real one :). Thoughts?
Vetoes in response to a commit message -- seems like one should be able to
veto *before* a commit message, too. Nobody likes reverting codebases.
Inactive / Emeritus committers -- does everyone listed as initial committer
actually pass the 6-month requirement? I think Ben Reed and Giri might not,
which would make things awkward right off the bat.
Distinction between PMC and Committer list -- right now they are identical,
correct? Are they normally very different in other projects? Is that the
sort of thing that develops over time, and the initial groups tend to be the
same?
Thanks,
-Dmitriy
On Tue, Sep 28, 2010 at 4:39 PM, Olga Natkovich <[EMAIL PROTECTED]> wrote:
> Alan,
>
> Thanks for the proposal. Looks good! I have a couple of comments/questions:
>
> (1) I think all votes need to have a time boundary. For releases and
> committers, we used to use 3 business days. I am fine if we choose
> different/longer times and different time periods for different types of
> votes but I think we should state what they are in the document.
> (2) Seems like consensus and even 2/3 votes is very hard to achieve. I
> wonder if simple majority would do just as well for all the cases we have.
>
> Olga
>
> -----Original Message-----
> From: Alan Gates [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 27, 2010 6:18 PM
> To: [EMAIL PROTECTED]
> Subject: [DISCUSS] Apache Pig bylaws
>
> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project. I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
> look and give feedback.
>
> Alan.
>
I've been operating under the assumption that at least 1 "+1" committer vote
(not including author of contribution) is required for codebase changes.
This is a sensible rule imho.. but apparently not a real one :). Thoughts?
Vetoes in response to a commit message -- seems like one should be able to
veto *before* a commit message, too. Nobody likes reverting codebases.
Inactive / Emeritus committers -- does everyone listed as initial committer
actually pass the 6-month requirement? I think Ben Reed and Giri might not,
which would make things awkward right off the bat.
Distinction between PMC and Committer list -- right now they are identical,
correct? Are they normally very different in other projects? Is that the
sort of thing that develops over time, and the initial groups tend to be the
same?
Thanks,
-Dmitriy
On Tue, Sep 28, 2010 at 4:39 PM, Olga Natkovich <[EMAIL PROTECTED]> wrote:
> Alan,
>
> Thanks for the proposal. Looks good! I have a couple of comments/questions:
>
> (1) I think all votes need to have a time boundary. For releases and
> committers, we used to use 3 business days. I am fine if we choose
> different/longer times and different time periods for different types of
> votes but I think we should state what they are in the document.
> (2) Seems like consensus and even 2/3 votes is very hard to achieve. I
> wonder if simple majority would do just as well for all the cases we have.
>
> Olga
>
> -----Original Message-----
> From: Alan Gates [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 27, 2010 6:18 PM
> To: [EMAIL PROTECTED]
> Subject: [DISCUSS] Apache Pig bylaws
>
> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project. I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
> look and give feedback.
>
> Alan.
>
+
Dmitriy Ryaboy 2010-09-29, 00:20
-
Re: [DISCUSS] Apache Pig bylawsAlan Gates 2010-09-29, 00:47
On Sep 28, 2010, at 5:20 PM, Dmitriy Ryaboy wrote:
> A couple of notes:
>
> I've been operating under the assumption that at least 1 "+1"
> committer vote
> (not including author of contribution) is required for codebase
> changes.
> This is a sensible rule imho.. but apparently not a real one :).
> Thoughts?
I think this is what is meant by saying a code change requires lazy
consensus. The rules we've really been running under is that any code
changes must have at least one +1 besides the author. If the author
is a committer, we have not required the other +1 to be one. But if
the author is not a committer we have required that the +1 come from a
committer. Making this clear would be good.
>
> Vetoes in response to a commit message -- seems like one should be
> able to
> veto *before* a commit message, too. Nobody likes reverting codebases.
Yeah, we never check in code over a -1. Again, I can make this more
clear. Reverting code is like going to war. By the time you're there
you know something went way wrong to get you there.
>
> Inactive / Emeritus committers -- does everyone listed as initial
> committer
> actually pass the 6-month requirement? I think Ben Reed and Giri
> might not,
> which would make things awkward right off the bat.
Before I proposed the initial PMC list I checked that everyone on the
proposed list passed the test (including Ben and Giri). That's why I
went through and had a bunch of people moved to the emeritus list
before I proposed moving Pig to a TLP.
>
> Distinction between PMC and Committer list -- right now they are
> identical,
> correct? Are they normally very different in other projects? Is that
> the
> sort of thing that develops over time, and the initial groups tend
> to be the
> same?
Different projects handle it differently. I would propose that we
maintain a distinction. If we don't I feel it will be hard to add
committers, because at least for me the bar for PMC is higher than the
bar for committers.
Alan.
>
> Thanks,
> -Dmitriy
>
+
Alan Gates 2010-09-29, 00:47
-
Re: [DISCUSS] Apache Pig bylawsAlan Gates 2010-09-29, 05:44
On Sep 28, 2010, at 4:39 PM, Olga Natkovich wrote:
> Alan,
>
> Thanks for the proposal. Looks good! I have a couple of comments/
> questions:
>
> (1) I think all votes need to have a time boundary. For releases and
> committers, we used to use 3 business days. I am fine if we choose
> different/longer times and different time periods for different
> types of votes but I think we should state what they are in the
> document.
Seems fine. For votes that require everyone to vote is two weeks long
enough? It seems like all lazy votes can be 3 days.
> (2) Seems like consensus and even 2/3 votes is very hard to achieve.
> I wonder if simple majority would do just as well for all the cases
> we have.
Consensus votes are only prescribed for removing PMC members or
committers. Unanimity (minus the one being removed obviously) seems
good in this case. It prevents power blocks from developing and
ensures that this only happens when it is obvious to everyone that it
needs to happen.
2/3s votes are only required for new code bases (basically new
subprojects) and modifications of the bylaws. I'm ok with dropping
this to simple majority if others agree.
Alan.
>
> Olga
>
> -----Original Message-----
> From: Alan Gates [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 27, 2010 6:18 PM
> To: [EMAIL PROTECTED]
> Subject: [DISCUSS] Apache Pig bylaws
>
> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project. I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
> look and give feedback.
>
> Alan.
+
Alan Gates 2010-09-29, 05:44
-
RE: [DISCUSS] Apache Pig bylawsSanthosh Srinivasan 2010-09-29, 17:57
I like the bylaws as they stand now. Consensus for removal and 2/3 votes for new code bases and change in bylaws makes sense as these activities are not frequent occurrences.
Santhosh
-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 28, 2010 10:44 PM
To: [EMAIL PROTECTED]
Subject: Re: [DISCUSS] Apache Pig bylaws
On Sep 28, 2010, at 4:39 PM, Olga Natkovich wrote:
> Alan,
>
> Thanks for the proposal. Looks good! I have a couple of comments/
> questions:
>
> (1) I think all votes need to have a time boundary. For releases and
> committers, we used to use 3 business days. I am fine if we choose
> different/longer times and different time periods for different types
> of votes but I think we should state what they are in the document.
Seems fine. For votes that require everyone to vote is two weeks long enough? It seems like all lazy votes can be 3 days.
> (2) Seems like consensus and even 2/3 votes is very hard to achieve.
> I wonder if simple majority would do just as well for all the cases we
> have.
Consensus votes are only prescribed for removing PMC members or committers. Unanimity (minus the one being removed obviously) seems good in this case. It prevents power blocks from developing and ensures that this only happens when it is obvious to everyone that it needs to happen.
2/3s votes are only required for new code bases (basically new
subprojects) and modifications of the bylaws. I'm ok with dropping this to simple majority if others agree.
Alan.
>
> Olga
>
> -----Original Message-----
> From: Alan Gates [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 27, 2010 6:18 PM
> To: [EMAIL PROTECTED]
> Subject: [DISCUSS] Apache Pig bylaws
>
> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project. I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
> look and give feedback.
>
> Alan.
Santhosh
-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 28, 2010 10:44 PM
To: [EMAIL PROTECTED]
Subject: Re: [DISCUSS] Apache Pig bylaws
On Sep 28, 2010, at 4:39 PM, Olga Natkovich wrote:
> Alan,
>
> Thanks for the proposal. Looks good! I have a couple of comments/
> questions:
>
> (1) I think all votes need to have a time boundary. For releases and
> committers, we used to use 3 business days. I am fine if we choose
> different/longer times and different time periods for different types
> of votes but I think we should state what they are in the document.
Seems fine. For votes that require everyone to vote is two weeks long enough? It seems like all lazy votes can be 3 days.
> (2) Seems like consensus and even 2/3 votes is very hard to achieve.
> I wonder if simple majority would do just as well for all the cases we
> have.
Consensus votes are only prescribed for removing PMC members or committers. Unanimity (minus the one being removed obviously) seems good in this case. It prevents power blocks from developing and ensures that this only happens when it is obvious to everyone that it needs to happen.
2/3s votes are only required for new code bases (basically new
subprojects) and modifications of the bylaws. I'm ok with dropping this to simple majority if others agree.
Alan.
>
> Olga
>
> -----Original Message-----
> From: Alan Gates [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 27, 2010 6:18 PM
> To: [EMAIL PROTECTED]
> Subject: [DISCUSS] Apache Pig bylaws
>
> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project. I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
> look and give feedback.
>
> Alan.
+
Santhosh Srinivasan 2010-09-29, 17:57
-
Re: [DISCUSS] Apache Pig bylawsBenjamin Reed 2010-09-29, 21:32
i also like them! excellent work.
ben
On 09/29/2010 10:57 AM, Santhosh Srinivasan wrote:
> I like the bylaws as they stand now. Consensus for removal and 2/3 votes for new code bases and change in bylaws makes sense as these activities are not frequent occurrences.
>
> Santhosh
>
> -----Original Message-----
> From: Alan Gates [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 28, 2010 10:44 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [DISCUSS] Apache Pig bylaws
>
>
> On Sep 28, 2010, at 4:39 PM, Olga Natkovich wrote:
>
>> Alan,
>>
>> Thanks for the proposal. Looks good! I have a couple of comments/
>> questions:
>>
>> (1) I think all votes need to have a time boundary. For releases and
>> committers, we used to use 3 business days. I am fine if we choose
>> different/longer times and different time periods for different types
>> of votes but I think we should state what they are in the document.
> Seems fine. For votes that require everyone to vote is two weeks long enough? It seems like all lazy votes can be 3 days.
>
>> (2) Seems like consensus and even 2/3 votes is very hard to achieve.
>> I wonder if simple majority would do just as well for all the cases we
>> have.
> Consensus votes are only prescribed for removing PMC members or committers. Unanimity (minus the one being removed obviously) seems good in this case. It prevents power blocks from developing and ensures that this only happens when it is obvious to everyone that it needs to happen.
>
> 2/3s votes are only required for new code bases (basically new
> subprojects) and modifications of the bylaws. I'm ok with dropping this to simple majority if others agree.
>
> Alan.
>
>> Olga
>>
>> -----Original Message-----
>> From: Alan Gates [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, September 27, 2010 6:18 PM
>> To: [EMAIL PROTECTED]
>> Subject: [DISCUSS] Apache Pig bylaws
>>
>> As directed in our vote to become a TLP, we (Pig's PMC) need to set
>> out bylaws for the project. I have put up a first proposal for these
>> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
>> look and give feedback.
>>
>> Alan.
ben
On 09/29/2010 10:57 AM, Santhosh Srinivasan wrote:
> I like the bylaws as they stand now. Consensus for removal and 2/3 votes for new code bases and change in bylaws makes sense as these activities are not frequent occurrences.
>
> Santhosh
>
> -----Original Message-----
> From: Alan Gates [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 28, 2010 10:44 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [DISCUSS] Apache Pig bylaws
>
>
> On Sep 28, 2010, at 4:39 PM, Olga Natkovich wrote:
>
>> Alan,
>>
>> Thanks for the proposal. Looks good! I have a couple of comments/
>> questions:
>>
>> (1) I think all votes need to have a time boundary. For releases and
>> committers, we used to use 3 business days. I am fine if we choose
>> different/longer times and different time periods for different types
>> of votes but I think we should state what they are in the document.
> Seems fine. For votes that require everyone to vote is two weeks long enough? It seems like all lazy votes can be 3 days.
>
>> (2) Seems like consensus and even 2/3 votes is very hard to achieve.
>> I wonder if simple majority would do just as well for all the cases we
>> have.
> Consensus votes are only prescribed for removing PMC members or committers. Unanimity (minus the one being removed obviously) seems good in this case. It prevents power blocks from developing and ensures that this only happens when it is obvious to everyone that it needs to happen.
>
> 2/3s votes are only required for new code bases (basically new
> subprojects) and modifications of the bylaws. I'm ok with dropping this to simple majority if others agree.
>
> Alan.
>
>> Olga
>>
>> -----Original Message-----
>> From: Alan Gates [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, September 27, 2010 6:18 PM
>> To: [EMAIL PROTECTED]
>> Subject: [DISCUSS] Apache Pig bylaws
>>
>> As directed in our vote to become a TLP, we (Pig's PMC) need to set
>> out bylaws for the project. I have put up a first proposal for these
>> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
>> look and give feedback.
>>
>> Alan.
+
Benjamin Reed 2010-09-29, 21:32
-
RE: [DISCUSS] Apache Pig bylawsOlga Natkovich 2010-09-30, 16:27
On the consensus issue, should we check how other projects do this?
Olga
-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 28, 2010 10:44 PM
To: [EMAIL PROTECTED]
Subject: Re: [DISCUSS] Apache Pig bylaws
On Sep 28, 2010, at 4:39 PM, Olga Natkovich wrote:
> Alan,
>
> Thanks for the proposal. Looks good! I have a couple of comments/
> questions:
>
> (1) I think all votes need to have a time boundary. For releases and
> committers, we used to use 3 business days. I am fine if we choose
> different/longer times and different time periods for different
> types of votes but I think we should state what they are in the
> document.
Seems fine. For votes that require everyone to vote is two weeks long
enough? It seems like all lazy votes can be 3 days.
> (2) Seems like consensus and even 2/3 votes is very hard to achieve.
> I wonder if simple majority would do just as well for all the cases
> we have.
Consensus votes are only prescribed for removing PMC members or
committers. Unanimity (minus the one being removed obviously) seems
good in this case. It prevents power blocks from developing and
ensures that this only happens when it is obvious to everyone that it
needs to happen.
2/3s votes are only required for new code bases (basically new
subprojects) and modifications of the bylaws. I'm ok with dropping
this to simple majority if others agree.
Alan.
>
> Olga
>
> -----Original Message-----
> From: Alan Gates [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 27, 2010 6:18 PM
> To: [EMAIL PROTECTED]
> Subject: [DISCUSS] Apache Pig bylaws
>
> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project. I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
> look and give feedback.
>
> Alan.
Olga
-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 28, 2010 10:44 PM
To: [EMAIL PROTECTED]
Subject: Re: [DISCUSS] Apache Pig bylaws
On Sep 28, 2010, at 4:39 PM, Olga Natkovich wrote:
> Alan,
>
> Thanks for the proposal. Looks good! I have a couple of comments/
> questions:
>
> (1) I think all votes need to have a time boundary. For releases and
> committers, we used to use 3 business days. I am fine if we choose
> different/longer times and different time periods for different
> types of votes but I think we should state what they are in the
> document.
Seems fine. For votes that require everyone to vote is two weeks long
enough? It seems like all lazy votes can be 3 days.
> (2) Seems like consensus and even 2/3 votes is very hard to achieve.
> I wonder if simple majority would do just as well for all the cases
> we have.
Consensus votes are only prescribed for removing PMC members or
committers. Unanimity (minus the one being removed obviously) seems
good in this case. It prevents power blocks from developing and
ensures that this only happens when it is obvious to everyone that it
needs to happen.
2/3s votes are only required for new code bases (basically new
subprojects) and modifications of the bylaws. I'm ok with dropping
this to simple majority if others agree.
Alan.
>
> Olga
>
> -----Original Message-----
> From: Alan Gates [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 27, 2010 6:18 PM
> To: [EMAIL PROTECTED]
> Subject: [DISCUSS] Apache Pig bylaws
>
> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project. I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
> look and give feedback.
>
> Alan.
+
Olga Natkovich 2010-09-30, 16:27
-
Re: [DISCUSS] Apache Pig bylawsBenjamin Reed 2010-09-29, 21:55
one small thing that i'm not sure exactly how to address. you don't
want voting intervals to be too long because they can slow down the
release if issues come up and you need to keep restarting the vote. on
the other hand, a short interval means that people may miss it.
it might be nice to have something about a announcement time frame for a
vote. something like an announcement for an upcoming vote must be made
at least a week in advance. that way people don't miss it. for example
the following scenario would be valid: on the 1st you announce that you
have a vote coming up for a release on the 8th. issues come up on the
7th and delay the vote until the 10th. on the 10th the voting starts.
there is a issue that comes up during voting and you restart the vote on
the 15th. on the 18th the vote passes.
i'm not really sure how to state it in the bylaws. (i said up front that
i wasn't sure how to address it :)
ben
On 09/27/2010 06:18 PM, Alan Gates wrote:
> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project. I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
> look and give feedback.
>
> Alan.
want voting intervals to be too long because they can slow down the
release if issues come up and you need to keep restarting the vote. on
the other hand, a short interval means that people may miss it.
it might be nice to have something about a announcement time frame for a
vote. something like an announcement for an upcoming vote must be made
at least a week in advance. that way people don't miss it. for example
the following scenario would be valid: on the 1st you announce that you
have a vote coming up for a release on the 8th. issues come up on the
7th and delay the vote until the 10th. on the 10th the voting starts.
there is a issue that comes up during voting and you restart the vote on
the 15th. on the 18th the vote passes.
i'm not really sure how to state it in the bylaws. (i said up front that
i wasn't sure how to address it :)
ben
On 09/27/2010 06:18 PM, Alan Gates wrote:
> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project. I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a
> look and give feedback.
>
> Alan.
+
Benjamin Reed 2010-09-29, 21:55
