ctubbsii opened a new pull request, #431:
URL: https://github.com/apache/accumulo-website/pull/431

   Simplify the bylaws by removing extraneous details about the ASF and its 
standard practices, instead of embedding everything into the bylaws. Also align 
them to how we actually operate, removing sections that are either wrong or 
unused.
   
   Notable changes are:
   
   * Bump bylaws to version 4 (if approved)
   * Add link to The Apache Way briefing
   * Simplified introduction to the bylaws themselves
   * Remove redundant role definitions and link to Foundation descriptions
   * Align description about how PMC members are added with the board 
procedures, and write it in a way that preserves our normal voting practice for 
new members while not undermining the board procedures or subtracting from the 
PMC Chair's delegated authority
   * Align the description of Emeritus PMC member privileges with one's actual 
privileges granted as a position within the Foundation (for example, remove the 
part about keeping voting rights... that's not a thing upon resigning from the 
PMC). However, make it clear that we still allow one to stay on the private 
list if they are Emeritus (we can decide to do things differently and remove 
those people... but I wasn't going to propose that change here)
   * Reorder PMC Chair description after PMC member section and clarify 
expectations to make a good faith effort to get consensus from the PMC members
   * Drop everything about formal release plans. We don't ever actually 
construct them formally... the release process is too simple and automated to 
require formal release plans, and this whole section just creates unnecessary 
bureaucracy.
   * However, do add extra information about what kinds of things a release 
manager is expected to do as part of curating a release
   * Drop all the descriptions of voting types and link to glossary
   * Drop descriptions about how voting happens, and link to the Foundation 
page on voting
   * Add details for how a vote subject line is formatted, how the result 
message is formatted, and how votes are closed in our project
   * Drop all the details about the different circumstances where we vote and 
what vote type we use, and simplify it to how we actually work, which is 
essentially consensus approval of at least 3 days for everything, lazy 
consensus on smaller matters, and majority approval for releases. The vote 
circumstances this drops are the release plan creation stuff that we don't use, 
and the adopting new code base... which isn't really a thing we've had to deal 
with and doesn't really require a special line item, as it's just a regular 
consensus approval, which is our basic vote type. This does drop all the vote 
durations to 3 days... if we really want to preserve the 7 days for specific 
circumstances, that can be added back in before this proposal is adopted, but I 
think 3 days is generally enough.
   
   In addition to the proposed changes to the bylaws, this change also includes 
dropping two pages from our docs that are redundant, describing voting in 
general and verbosely explaining lazy consensus. The Foundation pages, 
glossary, and the bylaws themselves are sufficient for these, and don't require 
separate verbose pages to explain.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to