Re: Proposed bylaws for the Hadoop project (was: [VOTE])

[Chris Douglas <cd...@apache.org>]

I think Bernd's prediction has come true: it's no longer clear what
form of the bylaws we're voting on. Quick summary:

Proposed, uncontroversial (or at least seconded) modifications to the original:
* Change "3 business days" to "1 week" for votes
* Change "Developer" to "Contributor"
* Change "Lazy approval then lazy consensus" to simply "Lazy
consensus" for source modifications
* Add "testing" and "bug reports" to explicit forms of contributions from Users

Still open/vague:
* State changes to/from emeritus status for committers and PMC members
  * Inactive status for 6 months vs 1 year
  * Vote of the PMC required to restore status to a) Committer b) PMC
* Definition of "adopt a new codebase"
* When to close a vote that has been vetoed

---

I agree with Dhruba's definition of "new codebase" as it concerns
contrib and second Konstantin's interpretation requiring a 2/3 vote of
the PMC for new subprojects.

Concerning vetoes: the advantages to restarting the vote would be to
explicitly reassert its content (as in this thread) or to notify those
who withheld their objections because they were redundant for the
outcome. I don't know if it needs to be written into the bylaws, but a
few days after a veto has been recanted (assuming its premise wasn't
mistaken) seems appropriate to me. The context matters a great deal,
so I hope we can trust in the discretion of the person who called the
vote.

Restoring a committer/PMC member from emeritus should always require a
vote, with the same rules as those new to the role. Asking the person
after an unexplained, idle 6 months and- on request- extending the
grace period to 12 before automatically moving them sounds fair. That
leaves "no response" as a reasonable criterion for moving an inactive
member, so decisions are not blocked for lapses in participation. -C

On Tue, Nov 3, 2009 at 11:49 AM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Mon, Nov 2, 2009 at 20:52, Owen O'Malley <om...@apache.org> wrote:
>> We should have created bylaws when we were established as a PMC back in Jan
>> 2008, but it has become clear that we need to define them. I looked around
>> and the Ant project had bylaws that were both clear and fairly complete. I
>> made some minor edits to match what we do. Please look them over and vote.
>> In a recursive usage, let's use 2/3 majority to approve these bylaws.
>
> A VOTE thread without having a discussion thread first is unlikely to
> not be hijacked by detailed discussion.
> I think it will be more successful to collect input first and then
> vote on something where all important input is featured in.
> As soon as discussions start to evolve on a VOTE thread, nobody knows
> what he is/has been voting for, really.
>
>  Bernd
>

Proposed bylaws for the Hadoop project (was: [VOTE])

[Chris Douglas <cd...@apache.org>]

Sent from the wrong address. -C

---------- Forwarded message ----------
From: Chris Douglas <cd...@apache.org>
Date: Thu, Nov 5, 2009 at 6:04 PM
Subject: Re: Proposed bylaws for the Hadoop project (was: [VOTE])
To: general@hadoop.apache.org


I think Bernd's prediction has come true: it's no longer clear what
form of the bylaws we're voting on. Quick summary:

Proposed, uncontroversial (or at least seconded) modifications to the original:
* Change "3 business days" to "1 week" for votes
* Change "Developer" to "Contributor"
* Change "Lazy approval then lazy consensus" to simply "Lazy
consensus" for source modifications
* Add "testing" and "bug reports" to explicit forms of contributions from Users

Still open/vague:
* State changes to/from emeritus status for committers and PMC members
 * Inactive status for 6 months vs 1 year
 * Vote of the PMC required to restore status to a) Committer b) PMC
* Definition of "adopt a new codebase"
* When to close a vote that has been vetoed

---

I agree with Dhruba's definition of "new codebase" as it concerns
contrib and second Konstantin's interpretation requiring a 2/3 vote of
the PMC for new subprojects.

Concerning vetoes: the advantages to restarting the vote would be to
explicitly reassert its content (as in this thread) or to notify those
who withheld their objections because they were redundant for the
outcome. I don't know if it needs to be written into the bylaws, but a
few days after a veto has been recanted (assuming its premise wasn't
mistaken) seems appropriate to me. The context matters a great deal,
so I hope we can trust in the discretion of the person who called the
vote.

Restoring a committer/PMC member from emeritus should always require a
vote, with the same rules as those new to the role. Asking the person
after an unexplained, idle 6 months and- on request- extending the
grace period to 12 before automatically moving them sounds fair. That
leaves "no response" as a reasonable criterion for moving an inactive
member, so decisions are not blocked for lapses in participation. -C

On Tue, Nov 3, 2009 at 11:49 AM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Mon, Nov 2, 2009 at 20:52, Owen O'Malley <om...@apache.org> wrote:
>> We should have created bylaws when we were established as a PMC back in Jan
>> 2008, but it has become clear that we need to define them. I looked around
>> and the Ant project had bylaws that were both clear and fairly complete. I
>> made some minor edits to match what we do. Please look them over and vote.
>> In a recursive usage, let's use 2/3 majority to approve these bylaws.
>
> A VOTE thread without having a discussion thread first is unlikely to
> not be hijacked by detailed discussion.
> I think it will be more successful to collect input first and then
> vote on something where all important input is featured in.
> As soon as discussions start to evolve on a VOTE thread, nobody knows
> what he is/has been voting for, really.
>
>  Bernd
>