On Wed, Feb 26, 2014 at 10:15 AM, Mike Drob <[email protected]> wrote:
> Great input, Billie! I had expected that you would be able to provide more > ASF references than I had been able to find on my own. Responses inline. > > Mike > > On Wed, Feb 26, 2014 at 12:29 PM, Billie Rinaldi <[email protected]> > wrote: > > > I have some issues with the proposed bylaws. The main one is that it > > chooses arbitrary names for approval types that do not match Apache's > > definitions [1][2]. I believe we should stick with Apache's definitions. > > I also see no reason to change the general guidelines provided for which > > types of approval are needed in various scenarios. > > > > I hadn't seen the voting page before, thanks! I did an unscientific > sampling of other Apache projects and it looks like ZK, Hadoop, Pig, and > Hive all use very similar bylaws, including the approval types and action > types. This didn't surprise me, and I understand that we should still > follow ASF examples over Hadoop examples. However, I was interested to see > Ant have similar bylaws as well. Then there is another group, including > HTTPD, HttpComponents, and Struts, that have very different looking bylaws. > Most groups with bylaws look like one of these two templates. > > I have no issue with dropping the "consensus" approval type to line up more > with ASF definitions. What do you propose the new threshold for revoking > committer/PMC be? I also have no issue with dropping the "2/3 majority" > (although Hadoop has an interesting spin on it; still lazy, but twice as > many +1 as -1) - what would be the new threshold for modifying bylaws and > accepting an existing code base. The code base situation came up recently > with raccumulo and that was never properly resolved, I think, so this is a > good time to think about that. > > +1 on renaming to Consensus Approval and Majority Approval as per the ASF > glossary. > -0 on renaming Lazy Approval to Lazy Consensus. The glossary definition > calls them out as equivalent and like the parallelism from "X Approval" > naming. I think it is easier to remember. > I agree Lazy Approval is fine. I wouldn't mind an extra sentence in the text saying that Lazy Approval is sometimes also called Lazy Consensus (so that it's clear that any approval mechanism starting with "Lazy" means the same thing). Regarding what types of approval are needed for what actions: - In ASF guidelines, code changes are vetoable (that is, everyone has to agree). Thus I suggest making the approval Lazy Approval, falling back to Consensus Approval if a -1 is received. (The current doc says it falls back to Majority Approval.) - Majority approval is fine for release plan and product release. - Consensus approval is fine for new committers and PMC members. - The remaining actions are new codebase, modifying bylaws, and emeritus issues. How about Consensus for new codebase and modifying bylaws (perhaps with a 7-day minumum vote instead of 3-day), and drop the emeritus issues? Do we want to add explicitly that any unfinished vote can be extended if no -1s have been received? > > > > Another major departure in the proposed bylaws is that it gives > committers > > binding votes in some situations, while typically only PMC members have > > binding votes. Since our policy is for all PMC members to be committers, > > we don't need to alter the standard responsibilities of committers. > > > > I had been under the impression that committers should have binding say > on > code change but no procedural votes. Turns out that is backwards, according > to the ASF voting page. I think this document can be written in such a way > to describe C and PMC roles as separate sets of responsibilities without > conflicting with our current notion that C == PMC. I don't know if we will > always have that be the case, but I can imagine a case where an individual > might accept the C invitation but not the PMC one. > > Also, the described responsibilities of committers and PMC members are > > misleading in that they leave out (or fail to clarify) some of the most > > important responsibilities of those roles. > > > > Just to make sure I understand: committers are stewards of the code and PMC > are stewards of the project? > The main responsibilities I want to call out are the following. Committers: Under the terms of the Contributor License Agreement that all committers must sign, a committer's primary responsibility is to ensure that all code committed to Apache Accumulo is licensed appropriately and meets those criteria set forth in the CLA (including both original works and patches committed on behalf of other contributors). PMC members: The function of the PMC is to vote on community-related decisions, such as on new PMC members, committers and on releases. In particular, PMC members must understand both our project's criteria and ASF criteria for voting on a release (http://www.apache.org/dev/release.html, http://www.apache.org/dev/release.html#what, http://www.apache.org/dev/release.html#what-must-every-release-contain, http://www.apache.org/dev/release.html#approving-a-release). The following two paragraphs may also be useful (copied from http://apache.org/foundation/how-it-works.html#pmc): The role of the PMC from a Foundation perspective is oversight. The main role of the PMC is not code and not coding - but to ensure that all legal issues are addressed, that procedure is followed, and that each and every release is the product of the community as a whole. That is key to our litigation protection mechanisms. Secondly the role of the PMC is to further the long term development and health of the community as a whole, and to ensure that balanced and wide scale peer review and collaboration does happen. Within the ASF we worry about any community which centers around a few individuals who are working virtually uncontested. We believe that this is detrimental to quality, stability, and robustness of both code and long term social structures. > > > > I don't have any particular feeling on whether we should introduce the > > concept of emeritus committers or not. It seems the major reason for > > wanting to do so is to keep 2/3 majority votes managable, but I am not > > actually sure we need to introduce the concept of a 2/3 majority vote. > We > > could just use a standard veto-able vote (Apache Consensus Approval), > > perhaps with a longer time frame to ensure that everyone has a chance to > > weigh in. > > > > If we drop "consensus" and "2/3 majority" as defined in the document then > we should also drop emeritus. I agree with your interpretation of intent. > > > > > [1]: https://www.apache.org/foundation/voting.html > > [2]: https://www.apache.org/foundation/glossary.html > > > > > > On Tue, Feb 18, 2014 at 6:49 AM, Mike Drob <[email protected]> wrote: > > > > > Thanks for putting it in a Google Doc, Arshak! > > > > > > What issues do y'all see with this document in it's current state? > > > Personally, I think it looks fine and would be willing to start a vote > on > > > it, but I get the impression that east coast weather has prevented some > > > folk from looking at it, so maybe another couple of days is fine. > > > > > > Mike > > > > > > > > > On Sun, Feb 16, 2014 at 7:18 AM, Arshak Navruzyan <[email protected]> > > > wrote: > > > > > > > Oops, yes of course! It's editable. > > > > > > > > > > > > > > > > > > > > On Sat, Feb 15, 2014 at 7:01 PM, Bill Havanki < > > [email protected] > > > > >wrote: > > > > > > > > > Thanks Arshak! Can you either allow editing or commenting? > > > > > > > > > > > > > > > On Fri, Feb 14, 2014 at 6:10 PM, Arshak Navruzyan < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > Say no more ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/1uR8vhIQcKGA6IEtbbF5D7UL_e6WGtfXMUQHp8Fwvg_E/edit?usp=sharing > > > > > > > > > > > > > > > > > > On Fri, Feb 14, 2014 at 1:54 PM, Christopher < > [email protected]> > > > > > wrote: > > > > > > > > > > > > > Perhaps some ambitious volunteer could start a collaborative > > draft > > > of > > > > > > > Accumulo's bylaws in Google Docs or something, using ZK as a > > > starting > > > > > > > point. After it stabilizes a bit, we could push it to the > project > > > > > > > webpage as a draft and vote on it? > > > > > > > > > > > > > > -- > > > > > > > Christopher L Tubbs II > > > > > > > http://gravatar.com/ctubbsii > > > > > > > > > > > > > > > > > > > > > On Fri, Feb 14, 2014 at 2:11 PM, Mike Drob < > [email protected]> > > > > > wrote: > > > > > > > > I didn't get that impression from reading their document. > > While C > > > > and > > > > > > PMC > > > > > > > > are two distinct roles, there is nothing stating that there > > > cannot > > > > be > > > > > > > > overlap, and the fact that there is 100% overlap is entirely > > > > > > orthogonal. > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Feb 14, 2014 at 10:23 AM, Josh Elser < > > > [email protected] > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > >> This would change the existing Committer == PMC, no? > > > > > > > >> > > > > > > > >> That's the biggest thing I noticed scanning over the > document. > > > > > > > >> > > > > > > > >> > > > > > > > >> On 2/14/14, 1:19 PM, Mike Drob wrote: > > > > > > > >> > > > > > > > >>> I think we should have some Bylaws, as that gives us more > > > > structure > > > > > > to > > > > > > > >>> operate under. > > > > > > > >>> > > > > > > > >>> I propose that we adopt the ZooKeeper bylaws, replacing all > > > > > > references > > > > > > > to > > > > > > > >>> ZK with Accumulo. > > > > > > > >>> > > > > > > > >>> http://zookeeper.apache.org/bylaws.html > > > > > > > >>> > > > > > > > >>> What say ye? > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> Mike > > > > > > > >>> > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > | - - - > > > > > | Bill Havanki > > > > > | Solutions Architect, Cloudera Government Solutions > > > > > | - - - > > > > > > > > > > > > > > >
