I finally got a chance to fully read through the bylaws and this email thread.
+1 to approval for the bylaws. Thanks for writing these up! On Thu, Apr 3, 2014 at 9:59 PM, Sean Busbey <[email protected]>wrote: > Corey, > > Just for clarity, is your +1 to Benson's sentiment or to the Bylaws Vote > for this thread? > > -Sean > > > On Thu, Apr 3, 2014 at 8:58 PM, Corey Nolet <[email protected]> wrote: > > > +1 > > > > > > > > > > On Thu, Apr 3, 2014 at 8:45 PM, Benson Margulies <[email protected] > > >wrote: > > > > > If you're all going to go spelunking in the Apache policy docs, > > > perhaps I can help a bit with context. > > > > > > The original HTTPD project developed a very specific set of policies > > > for controlling _commits to the code base_. The ballet of > > > -1/veto/justification comes out of there. The overall foundation > > > policy is an expectation that all projects will apply that same > > > approach to commits unless they can state a very good reason to do > > > something else. > > > > > > Contrarywise, releases cannot be vetoed. A -1 is just a -1. No veto. > > > Justification is polite, but not required. Proceeding in the face of a > > > -1 is not always a good idea, but the policy envisions it; it > > > envisions that someone might vote -1 because they _might prefer_ to > > > wait for some other change. But they can just be outvoted. > > > > > > Once you get past commits to the codebase and releases, you're more on > > > your own in deciding how to decide. The particular case at hand, these > > > bylaws, is an interesting one. > > > > > > People should be really clear about what they mean when they propose > > > consensus as a process. Yes, a consensus process is a process in which > > > every member of the community has a veto. However, it is also a > > > process in which every member of the community feels a grave weight of > > > responsibility in using that veto. Focussing on the veto in a > > > consensus process is not a good sign. > > > > > > Consensus is a slow, deliberative, process, chosen by communities > > > which value group cohesion over most everything else. It is also a > > > process that presumes that there is a _status quo_ which is always > > > acceptable. The community sticks to the status quo until everyone > > > involved is ready to accept some change. This approach to > > > decision-making is pretty hard to apply to a new group trying to chart > > > a new course. > > > > > > It is _not_ foundation policy to expect communities to choose > > > full-blown consensus as the predominant process. Typically, in my > > > experience, Apache projects do not do full consensus process. Instead, > > > they strive to give everyone a voice and seek consensus, but > > > eventually decide via a majority of some kind. Most of the time, the > > > first part of that (open discussion) achieves a consensus, so that the > > > second part of that becomes a formality. However, from time to time, > > > the community chooses to decide by majority in order to decide. The > > > touchstone of a healthy community is that the minority feel heard and > > > not steamrolled. > > > > > >
