cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [DISCUSS] Apache CloudStack Project Bylaws
Date Thu, 13 Dec 2012 16:19:54 GMT
On Thu, Dec 13, 2012 at 9:58 AM, Sebastien Goasguen <runseb@gmail.com> wrote:
> Chip, some thoughts inline.
>
> Don't mind the pickiness.

Thanks for the review.  Any no, I don't mind the pickiness!

> On Dec 13, 2012, at 3:30 AM, Chip Childers <chip.childers@sungard.com> wrote:
>
>> Hi all,
>>
>> I'd like to start a conversation about our project bylaws.  This is
>> something that an Apache project doesn't absolutely require, but I
>> believe that some of the larger TLP's have found it to be valuable.
>> More specifically, I would like to see us discuss and agree on the
>> contents of the bylaws prior to graduating (hence why I'm bringing it
>> up now).  If others don't agree that this is the time or place, or
>> that they are not needed, then please say so!
>>
>> For the draft below, I started with the Hadoop project's version
>> (found here: http://hadoop.apache.org/bylaws.html ), and then took a
>> stab at editing the contents a bit to match some of the conventions
>> that we have been using as a community already.
>>
>> In the draft, I'm assuming that the CloudStack trademark will be
>> transfered at or before the time of graduation from the incubator, and
>> therefore retained the statements about ASF owning the trademark
>> (which is not yet true AFAIK).
>>
>> I've also retained the references to the PMC, instead of what is
>> currently the PPMC.  For the purpose of this discussion, consider PMC
>> to be equal to the PPMC today (with the obvious qualification that we
>> are under the Incubator PMC today).
>>
>> Section 2.1.4 talks about the PMC being responsible to the board, but
>> that will only be the case after we graduate.
>>
>> Please take a look, and let's start the process of figuring out what's
>> good / bad / otherwise about the draft.  All opinions are welcome!
>>
>> -chip
>>
>>
>> *****************************************************
>> Draft Apache CloudStack Project Bylaws
>> *****************************************************
>>
>> 1. Introduction
>>
>> 1.1. This document defines the bylaws under which the Apache
>> CloudStack project operates. It defines the roles and responsibilities
>> of the project, who may vote, how voting works, how conflicts are
>> resolved, etc.
>>
> I would not use 'etc'. Either list everything it defines or scratch the whole sentence.
> In previous bylaws I was involved with the less the better to avoid room for interpretation.
>

Agreed, let's drop that sentence.

>
>> 1.2. CloudStack is a project of the Apache Software Foundation. The
>> foundation holds the trademark on the name "CloudStack" and copyright
>> on Apache code including the code in the CloudStack codebase. The
>> foundation FAQ explains the operation and background of the
>> foundation.
>>
>> 1.3. CloudStack is typical of Apache projects in that it operates
>> under a set of principles, known collectively as the "Apache Way". If
>> you are new to Apache development, please refer to the Incubator
>> project for more information on how Apache projects operate.
>>
> Maybe:
> CloudStack is an Apache project that operates under a set of principles known collectively
as the "Apache Way".
>
> But that still leaves room for interpretation: What are those principles ?

Well, I think that's honestly the nature of it.  However, the list
that's on the ASF FAQ page is:

"Transparancy, consensus, non-affiliation, respect for fellow
developers, and meritocracy, in no specific order."

Does that work for everyone?

I also think we should drop the statement about "If you are new to Apache..."

>> 2. Roles and Responsibilities
>>
>> Apache projects define a set of roles with associated rights and
>> responsibilities. These roles govern what tasks an individual may
>> perform within the project. The roles are defined in the following
>> sections:
>>
>> 2.1. Users
>>
>> The most important participants in the project are people who use our
>> software. Users contribute to the Apache projects by providing
>> feedback to developers in the form of bug reports and feature
>> suggestions. As well, users participate in the Apache community by
>> helping other users on mailing lists and user support forums.
> Feature requests instead of feature suggestions ?

They are synonymous to me.  Why do you think that "request" is better?

> Is that all users can do ?

Are there other items that you suggest adding?

> What's their responsibilities ?

IMO, I'm not sure a user has any.

>> 2.2. Contributors
>>
>> Contributors are all of the volunteers who are contributing time,
>> code, documentation, or resources to the CloudStack Project.
>
> Devil's advocate hat on: I am contributing time but no code, docs or resources. Am I
a contributor ?

Certainly!  Using you as an example, when you go to a meet-up to help
support the project you are contributing time.

>> A
>> Contributor that makes sustained, welcome contributions to the project
>> may be invited to become a Committer,
> By who ? ( I know you spell it out later, but you may have to write it here)

Let's add: "by the PMC."

>> though the exact timing of such
>> invitations depends on many factors.
>

That's the issue...  it's entirely based on a PMC member deciding to
propose the contributor as a committer.  I'd like to leave this one as
is.

>
>> The form of contribution is not
>> limited to code.
> But is it mandatory ?
>

Nope.

Let's use this sentence instead:  "Contributions are not just code,
but can be any combination of documentation, testing, user support,
code, code reviews, bug reporting, community organizing, or project
marketing."

Does that work for you?

>> It can also include code review, helping out users on
>> the mailing lists, documentation, testing, etc.
>
> In the Users roles you said that "users contribute". Are users contributors ? If yes,
how do users and contributors differ ?

Good point.  Are users actually contributors if they actually
communicate with the project in any way?  Should we drop the user
role?

>>
>> 2.3. Committers
>>
>> The project's Committers are responsible for the project's technical
>> management. Committers have access to all project source control
>> repositories. Committers may cast binding votes on any technical
>> discussion regarding the project (or any sub-project).
>>
>> 2.3.1. Committer access is by invitation only and must be approved by
>> a majority consensus
>
> You only define Lazy consensus and Lazy majority later on.

That should be lazy consensus.

>> of the active PMC members. A Committer is
>> considered emeritus by their own declaration or by not contributing in
>> any form to the project for over six months. An emeritus committer may
>> request reinstatement of commit access from the PMC. Such
>> reinstatement is subject to lazy consensus of active PMC members.
>>
>> 2.3.2. All Apache Committers are required to have a signed Individual
>> Contributor License Agreement (ICLA) on file with the Apache Software
>> Foundation. There is a Committer FAQ which provides more details on
>> the requirements for Committers at Apache.
> Is there such as thing as Committer bylaws ? If yes I would say "Committers abide to
the Apache bylaws" instead of talking about FAQ.

I don't believe there is.

>
>>
>> 2.3.3. A Committer who makes a sustained contribution to the project
>> may be invited to become a member of the PMC. The form of contribution
>> is not limited to code.
>
> But is code mandatory ?

No.

>
>> It can also include code review, helping out
>> users on the mailing lists, documentation, testing, etc.
>
> no etc.

Since we already discuss this in the roles section, I actually think
we should just remove it from here.

>
>>
>> 2.4. Project Management Committee
>>
>> The Project Management Committee (PMC) for Apache CloudStack is
>> responsible to the board and the ASF for the management and oversight
>> of the Apache CloudStack codebase. The responsibilities of the PMC
>> include:
>>
>> - Deciding what is distributed as products of the Apache CloudStack
>> project. In particular all releases must be approved by the PMC
>> - Maintaining the project's shared resources, including the codebase
>> repository, mailing lists, websites.
>> - Speaking on behalf of the project.
>
> Devil's advocate: If I am not in the PMC does this mean I cannot speak "on behalf" ?
> What does this allow a PMC member to say that John Doe could not say ?
>

So this came directly from Hadoop, and I didn't put much thought into
it.  However, I think we should think of this as a statement about the
official member > board > PMC delegation of responsibilities.  The
distinction is that anyone can speak as themselves, noting that they
are part of the CloudStack community.  I think the difference is that
for a press discussion, PMC members are able to say that they are
"from the CloudStack project".  At least this is the way that I think
about it...

>> - Resolving license disputes regarding products of the project
>> - Nominating new PMC members and committers
>> - Maintaining these bylaws and other guidelines of the project
>
> Is the list of responsibilities exhaustive ?

Actually, I think it is, with one exception.  It actually doesn't call
out the primary role of a PMC, to foster and support the project's
community.

>>
>> 2.4.1. Membership of the PMC is by invitation only and must be
>> approved by a lazy consensus of active PMC members. 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. Such reinstatement is subject to
>> lazy consensus of the active PMC members.
>>
>> 2.4.2. The chair of the PMC is appointed by the ASF board. The chair
>> is an office holder of the Apache Software Foundation (Vice President,
>> Apache CloudStack) and has primary responsibility to the board for the
>> management of the projects within the scope of the CloudStack PMC. The
>> chair reports to the board quarterly on developments within the
>> CloudStack project.
>>
>> 2.4.3. The chair of the PMC is rotated annually. When the chair is
>> rotated or if the current chair of the PMC resigns, the PMC votes to
>> recommend a new chair using Single Transferable Vote (STV) voting. See
>> http://wiki.apache.org/general/BoardVoting for specifics. The decision
>> must be ratified by the Apache board.
>>
>> 3. Decision Making
>>
>> Within the CloudStack project, different types of decisions require
>> different forms of approval.
>
> A bit vague.
>

Drop it?

>> For example, the previous section
>> describes several decisions which require "lazy consensus" approval.
>
> no need for example.

Agreed.

>> This section defines how voting is performed, the types of approvals,
>> and which types of decision require which type of approval.
>>
>> 3.1. Voting
>>
>> 3.1.1. Decisions regarding the project are made by votes on the
>> primary project development mailing list
>> (cloudstack-dev@incubator.apache.org).
>
> How about the users ? they don't get to vote ?

AFAIK, all votes for an Apache project have to happen on the dev list
(or private PMC list).

>
>> Where necessary, PMC voting may
>> take place on the private CloudStack PMC mailing list. Votes are
>> clearly indicated by subject line starting with [VOTE].
>
> who can call a vote ?

I guess it depends on the specific vote that's occurring.  Should we
add this per topic below?

>
>> Votes may
>> contain multiple items for approval and these should be clearly
>> separated. Voting is carried out by replying to the vote mail. Voting
>> may take four flavors
>>
>> +1 "Yes," "Agree," or "the action should be performed." In general,
>> this vote also indicates a willingness on the behalf of the voter in
>> "making it happen"
>> +0 This vote indicates a willingness for the action under
>> consideration to go ahead. The voter, however will not be able to
>> help.
>> -0 This vote indicates that the voter does not, in general, agree with
>> the proposed action but is not concerned enough to prevent the action
>> going ahead.
>> -1 This is a negative vote. On issues where consensus is required,
>> this vote counts as a veto. All vetoes must contain an explanation of
>> why the veto is appropriate. Vetoes with no explanation are void. It
>> may also be appropriate for a -1 vote to include an alternative course
>> of action.
> I am not a committer. If I vote -1, does this constitute a veto ?

The concept of binding vs non-binding is what decides that question.
In the case of a contributor voting on a technical topic, the vote is
non-binding and (IMO) therefore not a valid veto.  It's an expression
of opinion.

>
>>
>> 3.1.2. All participants in the CloudStack project are encouraged to
>> show their agreement with or against a particular action by voting.
>> For technical decisions, only the votes of active committers are
>> binding. Non binding votes are still useful for those with binding
>> votes to understand the perception of an action in the wider
>> CloudStack community. For PMC decisions, only the votes of PMC members
>> are binding.
>
> This clarifies 3.1.1 , but is still vague on a non-binding -1
>

Perhaps add: "Non-binding -1 votes are not considered to be vetos for
any decision."

>>
>> 3.1.3. Voting can also be applied to changes made to the CloudStack
>> codebase. These typically take the form of a veto (-1) in reply to the
>> commit message sent when the commit is made.
>
> by a committer
>
>>
>> 3.2. Approvals
>>
>> These are the types of approvals that can be sought. Different actions
>> require different types of approvals
>
> There are three types of approvals that can be sought. Section 3.4 describes actions
and types of approvals needed.

Agreed.

>
>>
>> Lazy Consensus - Lazy consensus requires 3 binding +1 votes and no
>> binding vetoes.
>> Lazy Majority - A lazy majority vote requires 3 binding +1 votes and
>> more binding +1 votes than -1 votes.
>> Lazy 2/3 Majority - Lazy 2/3 majority votes requires at least 3 votes
>> and twice as many +1 votes as -1 votes.
>>
>> 3.3. Vetoes
>>
>> 3.3.1. Vetoes are only possible in a lazy consensus vote.
>>
>> 3.3.2. A valid, binding veto cannot be overruled. If a veto is cast,
>> it must be accompanied by a valid reason explaining the reasons for
>> the veto. The validity of a veto, if challenged, can be confirmed by
>> anyone who has a binding vote. This does not necessarily signify
>> agreement with the veto - merely that the veto is valid.
>>
>> 3.3.3. If you disagree with a valid veto, you must lobby the person
>> casting the veto to withdraw their veto. If a veto is not withdrawn,
>> any action that has been vetoed must be reversed in a timely manner.
> who is you ?
>>
>> 3.4. Actions
>>
>> This section describes the various actions which are undertaken within
>> the project, the corresponding approval required for that action and
>> those who have binding votes over the action.
>>
>> 3.4.1. Technical Decisions
>>
>> Technical decisions should be made by the entire community using
>> consensus gathering, and not through formal voting.  The CloudStack
>> community will assume that silence represents consensus on a proposal.
>>
> Since there is no vote, what is the timeline for considering that consensus has been
reached.
>
>> During the consensus gathering process, technical decisions may be
>> vetoed by any Committer with a valid reason.
>>
>> 3.4.2. Release Plan
>>
>> Defines the timetable and actions for a release.
>
> "timetable and work items " to avoid using "actions" in this "Actions" section.
>

Agreed.

>> The plan also
>> nominates a Release Manager.
>>
>> Lazy majority of active committers
>>
>> 3.4.3. Product Release
>>
>> When a release of one of the project's products is ready, a vote is
>> required to accept the release as an official release of the project.
>>
>> Lazy Majority of active PMC members
>>
>> 3.4.4. Adoption of New Codebase
>>
>> When the codebase for an existing, released product is to be replaced
>> with an alternative codebase. If such a vote fails to gain approval,
>> the existing code base will continue.
>>
>> This also covers the creation of new sub-projects within the project
>>
>> Lazy 2/3 majority of PMC members
>>
>> 3.4.5. New Committer
>>
>> When a new committer is proposed for the project
>>
>> Lazy consensus of active PMC members
>>
>> 3.4.6. New PMC Member
>>
>> When a committer is proposed for the PMC
>>
>> Lazy consensus of active PMC members
>>
>> 3.4.7. Committer Removal
>>
>> When removal of commit privileges is sought. Note: Such actions will
>> also be referred to the ASF board by the PMC chair
>>
>> Lazy 2/3 majority of active PMC members (excluding the committer in
>> question if a member of the PMC).
>>
>> 3.4.8. PMC Member Removal
>>
>> When removal of a PMC member is sought. Note: Such actions will also
>> be referred to the ASF board by the PMC chair.
>>
>> Lazy 2/3 majority of active PMC members (excluding the member in question)
>>
>> 3.4.9. Modifying Bylaws
>>
>> Modifying this document.
>>
>> Lazy majority of active PMC members
>>
>
> Do we need to set a timeframe on updating/reviewing bylaws ?
>

I wasn't suggesting one, but do folks think this is a good idea?

>> 3.5. Voting Timeframes
>>
>> Formal votes are open for a period of at least 72 hours to allow all
>> active voters time to consider the vote.
>>
>> *****************************************************
>
> -sebastien
>
>

Mime
View raw message