On 3 January 2014 22:33, jan i <j...@apache.org> wrote: > On Jan 3, 2014 11:59 AM, "sebb" <seb...@gmail.com> wrote: >> >> On 2 January 2014 23:04, sebb <seb...@gmail.com> wrote: >> > On 2 January 2014 19:32, jan i <j...@apache.org> wrote: >> >> Hi. >> >> >> >> This proposal is identical to the one issued before christmas, but >> >> based on a suggestion now formulated as a formal VOTE. >> >> >> >> This change in the bylaws [2] requires 2/3 vote +1 of the PMC members. >> >> >> >> VOTE runs until 19 January 2014. >> >> >> >> Vote +1 if you agree to to following change of bylaws: >> >> >> >> >> >> - Every ASF committer can ask for one or more labs. The lab creation >> >> requires PMC lazy concensus, if no PMC sends a mail with -1 to >> >> l...@apache.org within the lazy consensus period, the lab request is >> >> accepted. >> > >> > The voting period is not stated; I think it probably should be > specified. >> > >> > How about: >> > >> > Every ASF committer can ask for one or more labs. >> > The creation of the lab requires a PMC lazy consensus vote (no -1 >> > votes, 72 hours). >> > >> >> from >> >> - Every ASF committer can ask for one or more labs. The creation of >> >> the lab requires a PMC lazy consensus vote >> >> (at least three +1 and no -1, 72 hours). >> >> >> >> >> >> Reasoning: >> >> >> >> The charter [1] and homepage [2] for labs says: >> >> >> >> - Every ASF committer can ask for one or more labs. The creation of >> >> the lab requires a PMC lazy consensus vote >> >> (at least three +1 and no -1, 72 hours). >> > >> > BTW, I've just realised that merely dropping the word "lazy" would >> > have resolved the ambiguity. >> > However, IMO full consensus approval is too strong a requirement. >> > >> > +1 (non-binding) provided the voting period is defined. >> >> After further thought: >> >> -1 (non-binding) for the following reason: >> >> The original voting rules required a consensus vote, i.e. any -1 was a >> veto, regardless of how many +1s. >> >> The proposed rule requires a lazy consensus vote, with the same -1 veto. >> >> So any PMC member can veto any Lab. >> It would be necessary to get the person to withdraw their vote in >> order to start the Lab. >> >> Release votes are specifically majority votes for that reason - to >> stop a single person blocking a release. >> [However of course an RM normally does not override the -1 if it >> because of a serious issue with the release] >> >> Is that really what is wanted? > > actually, we should not require a vote at all. Today anybody can start a > project at github. We require that only committers can use labs, isnt that > enough ? the more red tape we require the less number of labs will be > created. > > please consider if labs should be easy to use, or so difficult that te > project in reality is unused (as it is right now)
+1 definitely no sense to add complicated rules > > rgds > jan i >> >> Or is something like a lazy majority needed? >> This does not currently exist in the glossary, but one could handle it >> initially as a lazy consensus. >> if that fails (i.e. the vetoer does not change their vote), then the >> vote can be restarted as a majority approval. >> I think it's important in this case to restate the proposal and >> restart the vote so further consideration can be given to the reason >> for the veto(s). >> >> >> However the foundations glossary [3] defines lazy consensus today as: >> >> >> >> *Lazy consensus*(Also called 'lazy approval'.) A decision-making policy >> >> which assumes general consent if no responses are posted within a > defined >> >> period. For example, "I'm going to commit this by lazy consensus if > no-one >> >> objects within the next three days." Also see Consensus >> >> Approval< > http://www.apache.org/foundation/glossary.html#ConsensusApproval>, >> >> Majority >> >> Approval < > http://www.apache.org/foundation/glossary.html#MajorityApproval>, >> >> and the description of the voting >> >> process <http://www.apache.org/foundation/voting.html>. >> >> >> >> >> >> rgds >> >> >> >> jan I. >> >> >> >> >> >> >> >> [1] > http://www.apache.org/foundation/records/minutes/2006/board_minutes_2006_11_15.txt >> >> >> >> >> >> [2] http://labs.apache.org/bylaws.html >> >> [3] http://www.apache.org/foundation/glossary.html >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org >> For additional commands, e-mail: labs-h...@labs.apache.org >> -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org For additional commands, e-mail: labs-h...@labs.apache.org
