metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lyle <dlyle65...@gmail.com>
Subject Re: [DISCUSS] Bylaws discussion
Date Thu, 14 Jul 2016 18:37:13 GMT
What does "Votes relating to code changes are not subject to a strict
timetable but should be made as timely as possible" mean to you?

One issue I'm concerned about with lazy consensus is having adequate time
to review a code change. Requiring 2 +1's has been pain sometimes, but it
kind of makes sure everyone gets a look. Is there a better way to achieve
that aim? Is that even a valuable aim?

-D...


On Thu, Jul 14, 2016 at 11:43 AM, Nick Allen <nick@nickallen.org> wrote:

> I think lazy consensus for code modification is appropriate for where we
> are at with Metron.  As the community matures, we can revisit if needed.
>
> I am a +1 on the bylaws as you have them written.
>
> On Thu, Jul 14, 2016 at 10:53 AM, Casey Stella <cestella@gmail.com> wrote:
>
> > We do not currently have bylaws, so we default we are in sort of nebulous
> > territory from what I can tell.  Take the voting on code modifications,
> for
> > instance, we are bound by the rules here
> > <http://www.apache.org/foundation/voting.html>, from my understanding
> > (since we don't have voted-in bylaws):
> > >
> > > For code-modification votes, +1 votes are in favour of the proposal,
> but
> > > -1 votes are vetos <http://www.apache.org/foundation/voting.html#Veto>
> > and
> > > kill the proposal dead until all vetoers withdraw their -1 votes.
> > >
> > > Unless a vote has been declared as using lazy consensus
> > > <http://www.apache.org/foundation/voting.html#LazyConsensus> , three
> +1
> > > votes are required for a code-modification proposal to pass.
> > >
> > > We, however, have adopted a de facto 2 +1's for code modification.  The
> > bylaws that we put up originally state a lazy consensus of 1 +1 is
> > sufficient.
> >
> > What I propose is that we figure out what they SHOULD be and abide by the
> > stated bylaws that we advertise.
> > There is not a good way to see the diff because we abide by de facto
> rules
> > that do not seem to be written down.
> >
> > I would read the original proposed bylaws and see if you see differences
> in
> > how we act day-to-day and if you're ok with those differences.  If not,
> > then bring it up on this thread and we can hash it out.
> >
> > I am not champing at the bit for a vote, but I would like us to have
> > bylaws, so I wanted to make sure this wasn't a "consensus of silence"
> > situation.  I think we can stand a bit of discussion on this and thus far
> > there has been only crickets.
> >
> > Casey
> >
> >
> > On Thu, Jul 14, 2016 at 10:42 AM, Nick Allen <nick@nickallen.org> wrote:
> >
> > > I don't quite understand the proposal.  How do these bylaws differ from
> > > what is already in-place?  Is there a way I can see the diff between
> what
> > > we have now?
> > >
> > > On Thu, Jul 14, 2016 at 10:09 AM, Casey Stella <cestella@gmail.com>
> > wrote:
> > >
> > > > Ok, it's been a month of crickets.  I'm going to put this up for a
> > vote.
> > > >
> > > > On Thu, Jun 16, 2016 at 11:29 AM, Casey Stella <cestella@gmail.com>
> > > wrote:
> > > >
> > > > > I'd like to get the Apache bylaws that we have on the website
> > discussed
> > > > > and possibly voted in.
> > > > >
> > > > > Does anyone have anything to object to in the bylaws as listed here
> > > > > <
> > >
> https://cwiki.apache.org/confluence/display/METRON/Apache+Metron+Bylaws
> > > > >?
> > > > >
> > > > > Casey
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Nick Allen <nick@nickallen.org>
> > >
> >
>
>
>
> --
> Nick Allen <nick@nickallen.org>
>

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