Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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