Skip to content

Commit

Permalink
Proposed update to bylaws
Browse files Browse the repository at this point in the history
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.
  • Loading branch information
ctubbsii committed Jul 23, 2024
1 parent 227a5fe commit ee589ff
Show file tree
Hide file tree
Showing 5 changed files with 168 additions and 417 deletions.
Loading

0 comments on commit ee589ff

Please sign in to comment.