cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [VOTE] Update by-laws: non-technical decisions and other minor changes
Date Mon, 12 Aug 2013 18:01:14 GMT
Bumping the thread for a 3rd +1 vote from the PMC. Our by-laws stipulate we
need 3 +1 PMC votes.

Thanks.


On 5 August 2013 22:43, Noah Slater <nslater@apache.org> 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
>
>


-- 
Noah Slater
https://twitter.com/nslater

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message