Uh... [This is in response to the] quoted thread wherein Sebastian highlights that we have nothing in our by-laws to tell us how to make general non-technical decisions.
On 20 June 2013 14:21, Noah Slater <nsla...@apache.org> wrote: > 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 > -- NS
