My apologies for these not making it into the document. I thought that you had already made the changes yourself. Removed the business days thing, that's makes sense.
I added the committer section almost verbatim. I made a few changes to your proposed PMC section because it looked like a lot of that was covered by the bullets we already have. Can you take another look? On Wed, Mar 5, 2014 at 12:24 PM, Billie Rinaldi <[email protected]>wrote: > I think my suggestions of clarifications for committer and PMC member > responsibilities earlier in this thread might have been overlooked, so I'll > repeat them. Also, I have a slight preference for not using business days > for vote lengths since not all of our voters do this as their day job. > > 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. > > > > On Wed, Mar 5, 2014 at 9:14 AM, Bill Havanki <[email protected] > >wrote: > > > Nice! I fixed the bulleted list of PMC responsibilities, which had lost > its > > bullets in translation. > > > > We should clarify the right number of days for the new codebase and bylaw > > modification actions. They were 6, but in my last edit I made them 7 > > because we were considering a minimum of a week. However, the days are > > stated as business days. So, they should instead be 5, unless anyone > thinks > > more business days are required. > > > > > > On Wed, Mar 5, 2014 at 11:50 AM, Mike Drob <[email protected]> wrote: > > > > > I'm taking the current state of the document and uploading it to our > CMS, > > > and adding a caveat about how it is only a draft, has not been > accepted, > > > etc. It is available at http://accumulo.apache.org/bylaws.html > > > > > > This version should be mostly static, unlike the google doc which is > easy > > > to edit anonymously. Please review the document for content, typos, and > > > other changes. I expect a vote to come soon! > > > > > > Mike > > > > > > > > > On Tue, Mar 4, 2014 at 10:36 AM, Bill Havanki < > [email protected] > > > >wrote: > > > > > > > OK, made a bunch of changes: > > > > > > > > - changed code change approval to lazy, then consensus > > > > - changed new codebase approval to consensus > > > > - changed bylaw change approval to majority - this is my preference, > > but > > > > I'm willing to yield and go with consensus at this point, anybody can > > > > change it > > > > - removed vote actions for kicking out committers and PMC members > > > > - removed definitions for 2/3 majority and "full consensus", which > > > weren't > > > > defined by ASF > > > > - added this sentence for C == PMC, feel free to strengthen but I > like > > > the > > > > teeny bit of wiggle room: > > > > > > > > It is the custom of the Accumulo project to also invite each > committer > > to > > > > become a member of the Accumulo PMC. > > > > > > > > - added paragraph on commit access being disabled for routine > security, > > > > using "may" so that we never are required to do it: > > > > > > > > An emeritus committer's commit access may be disabled as part of > > routine > > > > security. Access shall not be removed without notifying the > committer, > > > and > > > > access shall be maintained if the committer wishes to leave it > active. > > A > > > > committer's commit access shall be reactivated upon the committer's > > > request > > > > to the PMC. > > > > > > > > From my POV, these changes might handle all our open issues. I'd like > > to > > > > ask everyone to take another look at the doc and see if we can get > to a > > > > vote and close this effort out. > > > > > > > > Bill H > > > > > > > > > > > > On Thu, Feb 27, 2014 at 1:17 PM, Billie Rinaldi < > > > [email protected] > > > > >wrote: > > > > > > > > > On Thu, Feb 27, 2014 at 6:36 AM, Bill Havanki < > > > [email protected] > > > > > >wrote: > > > > > > > > > > > I implemented the vote renames in the doc. > > > > > > > > > > > > +1 on code change moving to consensus approval after a veto. That > > is > > > > more > > > > > > consistent. > > > > > > +1 to consensus approval for a new codebase, vs. 2/3 majority. > > > > > > -1 to consensus approval, 7-day period for bylaw changes. I don't > > > like > > > > > the > > > > > > veto possibility. I'd prefer majority approval, 7-day period. > > > > > > > > > > > > > > > > I'm neutral on this one. > > > > > > > > > > > > > > > > > > > > > > If we remove the emeritus vote actions, what mechanism is there > for > > > > > kicking > > > > > > out committers or PMC members? > > > > > > > > > > > > > > > > We wouldn't have one, but if necessary we could add it later with a > > > bylaw > > > > > change. Inactive PMC members / committers would still have the > > ability > > > > to > > > > > resign voluntarily. > > > > > > > > > > > > > > > > > > > > > > Re extending votes: something like this? > > > > > > > > > > > > - A vote action can be extended beyond its minimum length by the > > vote > > > > > > caller if its outcome has not been determined. > > > > > > - When it becomes clear that a vote will not reach a definitive > > > > outcome, > > > > > > the vote caller can close the vote, failing the vote action. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 26, 2014 at 4:41 PM, Billie Rinaldi < > > > > > [email protected] > > > > > > >wrote: > > > > > > > > > > > > > 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 > > > > > > > > > > > > | - - - > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > | - - - > > > > > > | Bill Havanki > > > > > > | Solutions Architect, Cloudera Government Solutions > > > > > > | - - - > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > // Bill Havanki > > > > // Solutions Architect, Cloudera Govt Solutions > > > > // 443.686.9283 > > > > > > > > > > > > > > > -- > > // Bill Havanki > > // Solutions Architect, Cloudera Govt Solutions > > // 443.686.9283 > > >
