The following is a summary of my updates. There was a lot of (excellent) discussion, so please do point out unintentional omissions, misinterpretations, or errors that are somewhat likely to be there. :)
- Fixed punctuation errors and typos noticed by Christopher. - Voting action changes: - Noted that new actions may be added as needed to the list - Changed the release plan action to lazy consensus, falling back to majority approval) - Added release plan cancellation (re-plan) action, majority approval - Clarified difference between release plan and product release actions - Defined "codebase" using Mike's definition - Noted that committer and PMC removal actions are intentionally not defined, with references - Added release manager role section - Added release plan section, with content definition based on Mike's list - Noted specifically that dates in release plans are estimates
I punted on laying out release guidelines, as we have a page for those  that I could defer to.
I also punted on version numbering, just for now. As with other issues, I can certainly see that as a worthwhile later addition.
Thank you in advance for reviewing. I'm hopeful that we can call a second vote by next week.
I think you are right about the reinstatement actions.
- If a committer cannot lose status, she cannot be denied getting the commit bit back / her password reset after going idle / emeritus. So, no vote is warranted. - An emeritus PMC member can simply declare that she is back via email (the bylaws even say so right now). On Wed, Mar 19, 2014 at 3:01 PM, Christopher <[EMAIL PROTECTED]> wrote: // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
How are we handling proposed changes? Just post a new version? Email description and then some coordinating editor (Bill H?) handles implementation? On Wed, Mar 19, 2014 at 2:50 PM, Bill Havanki <[EMAIL PROTECTED]>wrote:
I removed the reinstatement voting actions, as discussed earlier in this thread. The actions are now purely "New Committer" and "New PMC Member".
I think a diff between the votes is a great idea, easy to do with svn.
Any other feedback or issues with the proposed bylaws? On Wed, Mar 19, 2014 at 4:35 PM, Mike Drob <[EMAIL PROTECTED]> wrote: // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
I was going rewrite it to use singular they instead of the current combination of "his/her" and "his or her". But I haven't found time to do it yet. On Thu, Mar 20, 2014 at 1:10 PM, Bill Havanki <[EMAIL PROTECTED]>wrote:
I took one more pass through the bylaws. Besides fixing a typo and adding a missing comma, the only change I made was to add a "New PMC Chair" voting action. This was already defined in the PMC section as requiring consensus approval, so I just added a row to the voting action table for it. I set the minimum vote period to 3 days, matching the new committer and new PMC member actions. A longer period would also be fine IMO.
I'll tentatively plan to call a vote on Thursday. Thanks, everyone! On Thu, Mar 20, 2014 at 3:44 PM, Sean Busbey <busbey+[EMAIL PROTECTED]>wrote: // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
I was under the impression that the list was both compulsory and exhaustive, and if we need to add/remove actions later then we can bring up a vote on it. On Tue, Mar 25, 2014 at 10:47 AM, Sean Busbey <busbey+[EMAIL PROTECTED]>wrote:
I think "the ASF board removes PMC members" is misleading, so I changed it to "PMC members can only be removed with approval from the ASF Board". I also added a bullet under PMC about protecting Apache trademarks, and a link to the PMC Guide for more detailed information. Does anyone know what "Resolving license disputes regarding products of the project" means? If not, can we remove this bullet? I'm not sure which responsibility this is trying to highlight, so it at least needs clarification.
Otherwise, it seems to be in pretty good shape. On Tue, Mar 25, 2014 at 7:01 AM, Bill Havanki <[EMAIL PROTECTED]>wrote:
The "resolving license disputes" bullet is from the original boilerplate copied from ZooKeeper, so if it does not apply or make sense to us, +1 to dropping it.
I like the verbiage about how undefined voting actions should be run. I wouldn't want a needed vote to be held up because we need to update the bylaws first. On Tue, Mar 25, 2014 at 12:57 PM, Billie Rinaldi <[EMAIL PROTECTED]>wrote: // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
The list being compulsory makes sense to me, but artificially restricting what the PMC or committers can vote on by requiring a meta-vote first is not in line with my expectations around Apache projects in general.
The rule, as I'm used to it, is to seek consensus first in all matters and then use a vote if needed to clear up ambiguity. A bylaws vote for anything we happen to want to vote on seems excessive. On Tue, Mar 25, 2014 at 10:51 AM, Mike Drob <[EMAIL PROTECTED]> wrote:
I removed the "resolving license disputes" bullet from PMC responsibilities, as Billie suggested.
Last call for any other updates before the vote! On Tue, Mar 25, 2014 at 1:51 PM, Sean Busbey <busbey+[EMAIL PROTECTED]>wrote: // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation projects and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext