Devs, I would like to call a vote on the following modification to our by-laws. This is in response to the
Summary of changes: * Addition of "3.4.2. Non-Technical Decisions" section. This specifies that non-technical decisions can be made on any appropriate list (i.e. marketing@) and also allows us to vote on them with lazy 2/3 majority. * Changed "The vote must occur on a project development mailing list." to "The vote must occur on the project development mailing list." in several places. This makes it explicit that these decisions must be made on the dev@list. * Minor rewordings, typographical changes, corrections, section renumbering, etc. (I would separate out the minor changes for a separate change, but as we're voting on each change to this file, I want to reduce voting churn.) 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. Diff we're voting on: Index: bylaws.mdtext =================================================================== --- bylaws.mdtext (revision 1494950) +++ bylaws.mdtext (working copy) @@ -203,9 +203,9 @@ 3.4.1. Technical Decisions Technical decisions should normally be made by the entire community -using consensus gathering, and not through formal voting. +using discussion-lead consensus-building, 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. @@ -213,30 +213,47 @@ If a formal vote is started for a technical decision, the vote will be held as a lazy consensus of active committers. -Any user, contributor, committer or PMC member can initiate a technical desicion +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 +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 @@ -246,10 +263,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. @@ -258,7 +275,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. @@ -267,7 +284,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 @@ -278,7 +295,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. @@ -288,13 +305,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 On 20 June 2013 13:14, Noah Slater <nsla...@apache.org> wrote: > Sebastian, > > Thanks for the wrap up. I am happy with the way we proceeded here. It was > a good compromise. > > As for the process stuff: Apache — as a community — uses > discussion-lead consensus-based decision-making. (And formal voting is just > one manifestation of that.) This should permeate everything we do. Every > list, in other words. > > So the question isn't "where can votes happen?" (answer: everywhere Apache > people exist!) but "where must certain types of decision be made?" > > I think we've established through past discussions around event > organising, etc, that any sort of decision-making process in relation to > marketing, the website, events, and branding, can, and probably should, > happen on marketing@. There is no need to CC dev@. > > Any general, project-level stuff can be handled on dev@. In fact, "when > in doubt, do it on dev@" is a decent rule of thumb. > > Perhaps we have not documented that marketing@ list is a suitable forum > for certain types of decision making. It would probably be a good idea to > do so. (But not doing so in the short term does not make existing decisions > invalid. There is plenty of evidence in the mailing list archives to > demonstrate the PMC is happy with this.) > > As for the by-laws. I agree. I will post a patch in a few minutes. > > > > On 17 June 2013 21:05, Rohit Yadav <bhais...@apache.org> wrote: > >> On Tue, Jun 18, 2013 at 12:30 AM, Chip Childers >> <chip.child...@sungard.com>wrote: >> >> > Adding Rohit via his a.o address. >> > >> >> Thanks, yes please refrain from using my old/new corporate email >> addresses. >> >> I'll stick to my initial vote and would propose listing the books on the >> wiki immediately. >> >> Cheers. >> >> >> >> > On Mon, Jun 17, 2013 at 02:52:31PM -0400, Sebastien Goasguen wrote: >> > > Ilya, Rohit, Joe, Noah, >> > > >> > > I am re-sending this with you in CC to make sure you read it. >> > > >> > > Since there was little response the wiki link has been established >> > already, but I would like to get feedback on explicitly modifying the >> > bylaws to explain that marketing topics happen on the marketing list and >> > that Lazy majority or Lazy 2/3 majority will be required. >> > > >> > > -sebastien >> > > >> > > On Jun 12, 2013, at 6:12 AM, Sebastien Goasguen <run...@gmail.com> >> > wrote: >> > > >> > > > Hi, (note only marketing@) >> > > > >> > > > Apologies for a belated wrap up of this important vote. Please reply >> > in-line. >> > > > >> > > > [RESULTS]: >> > > > >> > > > +1 : 24 (Sebastien, Giles, Nguyen, Ryan, Kelly, Geoff, Roland, Alex, >> > Nehal, Sapm4kev, Gaspare, Kelcey, José,OutbackDingo, Todd, Eric, David, >> > Kimihiko, Radhika, Clayton, Chip, Chiradeep, Tariq, Mark) >> > > > >> > > > >> > > > -0 : 2 (Noah, Joe also vote +0) >> > > > >> > > > -1: 2 (Rohit, Ilya) >> > > > >> > > > [SUMMARY]: >> > > > >> > > > Rohit would be +1 on listing in the wiki, Ilya would be +0 on >> listing >> > in the wiki. >> > > > So it seems that we would have unanimous consensus for listing on >> the >> > wiki, even though there is a strong majority for the website. >> > > > >> > > > [DISCUSS]: >> > > > >> > > > I felt it was important to poll folks that are only on dev@ or >> users@and the results show that some folks who have never voted, got >> engaged in >> > this VOTE. This is a very positive side effect despite the confusion >> that I >> > created by bcc all lists. >> > > > >> > > > Our bylaws [1] do not cover votes on non-technical matters, so while >> > we have lazy majority on this vote it seems that this situation is not >> > covered by the bylaws. Moreover section 3.1.1 of bylaws says that >> decisions >> > on the project happen on dev@, so it seems that votes even on >> marketing@are not allowed (unsure about this). >> > > > >> > > > I propose the following: >> > > > >> > > > 1-To move forward without having to re-cast a vote, I propose to >> list >> > immediately the books on the Wiki, and inform Packt. I just created the >> > page [2] >> > > > 2- If people agree that we have a bylaw "loophole", we need to >> modify >> > the bylaws to allow votes on marketing@ and agree on using Lazy >> majority >> > or Lazy 2/3 majority. >> > > > >> > > > Once we agree, I will inform users@ and dev@ and invite folks who >> > participated in this vote to join marketing@ >> > > > >> > > > 3- We could then re-cast a vote to list on the website >> > > > >> > > > [1] http://cloudstack.apache.org/bylaws.html >> > > > [2] >> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Books >> > > > >> > > > Ps: fwiw, I think this is overly complicated but the only way >> forward >> > in the apache way. >> > > > >> > > > -Sebastien >> > > >> > > >> > >> > > > > -- > NS > -- NS
