Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: error (nike.apache.org: local policy)
Date: Tue, 6 Aug 2013 15:03:37 -0400
From: Chip Childers <chip.childers@sungard.com>
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Update by-laws: non-technical decisions and other minor
 changes
Message-ID: <20130806190337.GK39316@USLT-205755.sungardas.corp>
References: 
 <CAPaJBx4y7FLErTrVTpwGEkMN2aBK2pRjpr9P8i+b_qD9Bdtx2w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAPaJBx4y7FLErTrVTpwGEkMN2aBK2pRjpr9P8i+b_qD9Bdtx2w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

+1

On Mon, Aug 05, 2013 at 10:43:22PM +0100, Noah Slater wrote:
> Hi dev,
> 
> I have some more by-law changes to propose. This is essentially round 2 for
> these changes. I incorporated feedback from the last thread.
> 
> Per the by-laws, we're using a lazy majority for this vote. Please cast
> your vote now. I will tally the results in 72 hours.
> 
> Here's my changelog:
> 
> * Removed some spurious &nbsp; entities
> 
> * Added "A technical decision is any decision that involves changes to the
> source code
> that we distribute in our official releases." to � 3.4.1 (Technical
> Decisions).
> 
> * Added "discussion-lead" before "consensus gathering" in this section.
> 
> * With the improved definition, I have tightened up the wording so that
> technical decisions must be made on @dev.
> 
> * Added � 3.4.2, Non-Technical Decisions. Non-technical decisions are
> defined as in the inverse of technical decisions. They can be made on
> whatever list is appropriate. Formal voting will use a lazy 2/3 majority.
> Votes cannot be vetoed.
> 
> * Changed � 3.4.3. (Release Plan) to limit decisions to @dev.
> 
> * Changed � 3.4.4. (Product Release) to limit decisions to @dev.
> 
> * Changed � 3.4.5. (Adoption of New Codebase) to limit decisions to @dev.
> 
> * Changed � 3.4.10. (Modifying Bylaws) to limit decisions to @dev.
> 
> * Added an Oxford comma to the final paras of � 3.4.1. and � 3.4.2.
> 
> * Section renumbering to accommodate � 3.4.2.
> 
> And here's the patch:
> 
> Index: bylaws.mdtext
> ===================================================================
> --- bylaws.mdtext (revision 1510739)
> +++ bylaws.mdtext (working copy)
> @@ -198,41 +198,64 @@
> 
>  3.4.1. Technical Decisions
> 
> +A technical decision is any decision that involves changes to the source
> code
> +that we distribute in our official releases.
> +
>  Technical decisions should normally be made by the entire community using
> -consensus&nbsp;gathering, and not through formal voting.
> +discussion-lead consensus gathering, and not through formal voting.
> 
> -Technical decisions must be made on a project development mailing list.
> +Technical decisions must be made on the project development mailing list.
> 
>  During the consensus gathering process, technical decisions may be vetoed
> by
>  any Committer with a valid reason.
> 
>  If a formal vote is started for a technical decision, the vote will be
> held as
> -a lazy&nbsp;consensus&nbsp;of active committers.
> +a lazy consensus of active committers.
> 
> -Any user, contributor, committer or PMC member can initiate a technical
> +Any user, contributor, committer, or PMC member can initiate a technical
>  decision making process.
> 
> -3.4.2. Release Plan
> +3.4.2. Non-Technical Decisions
> 
> +A non-technical decisions is any decision that does not involve changes to
> the
> +source code that we distribute in our official releases.
> +
> +Non-technical decisions should normally be made by the entire community
> using
> +discussion-lead consensus-building, and not through formal voting.
> +
> +Non-technical decisions can be made on whichever project mailing list is
> most
> +appropriate.
> +
> +Non-technical decisions cannot be vetoed, but if there is strong opposition
> +a formal vote can be used to resolve the dispute.
> +
> +If a formal vote is started for a non-technical decision, the vote will be
> held
> +as a lazy 2/3 majority of active committers.
> +
> +Any user, contributor, committer, or PMC member can initiate a
> non-technical
> +decision making process.
> +
> +3.4.3. Release Plan
> +
>  Defines the timetable and work items for a release. The plan also
> nominates a
>  Release Manager.
> 
>  A lazy majority of active committers is required for approval.
> 
> -Any active committer or PMC member may call a vote. The vote must occur on
> a
> +Any active committer or PMC member may call a vote. The vote must occur on
> the
>  project development mailing list.
> 
> -3.4.3. Product Release
> +3.4.4. 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 is required for approval.
> 
> -Any active committer or PMC member may call a vote. The vote must occur on
> a
> +Any active committer or PMC member may call a vote. The vote must occur on
> the
>  project development mailing list.
> 
> -3.4.4. Adoption of New Codebase
> +3.4.5. 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
> @@ -242,10 +265,10 @@
> 
>  Lazy 2/3 majority of active PMC members.
> 
> -Any active committer or PMC member may call a vote. The vote must occur on
> a
> +Any active committer or PMC member may call a vote. The vote must occur on
> the
>  project development mailing list.
> 
> -3.4.5. New Committer
> +3.4.6. New Committer
> 
>  When a new committer is proposed for the project.
> 
> @@ -254,7 +277,7 @@
>  Any active PMC member may call a vote. The vote must occur on the PMC
> private
>  mailing list.
> 
> -3.4.6. New PMC Member
> +3.4.7. New PMC Member
> 
>  When a committer is proposed for the PMC.
> 
> @@ -263,7 +286,7 @@
>  Any active PMC member may call a vote. The vote must occur on the PMC
> private
>  mailing list.
> 
> -3.4.7. Committer Removal
> +3.4.8. Committer Removal
> 
>  When removal of commit privileges is sought. Note: Such actions will also
> be
>  referred to the ASF board by the PMC chair
> @@ -274,7 +297,7 @@
>  Any active PMC member may call a vote. The vote must occur on the PMC
> private
>  mailing list.
> 
> -3.4.8. PMC Member Removal
> +3.4.9. 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.
> @@ -284,13 +307,13 @@
>  Any active PMC member may call a vote. The vote must occur on the PMC
> private
>  mailing list.
> 
> -3.4.9. Modifying Bylaws
> +3.4.10. Modifying Bylaws
> 
>  Modifying this document.
> 
>  Lazy majority of active PMC members
> 
> -Any active committer or PMC member may call a vote. The vote must occur on
> a
> +Any active committer or PMC member may call a vote. The vote must occur on
> the
>  project development mailing list.
> 
>  3.5. Voting Timeframes
> 
> -- 
> Noah Slater
> https://twitter.com/nslater