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) 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 >
