From ee589ff13648721aa68f8e4ed2c011004ec88a35 Mon Sep 17 00:00:00 2001 From: Christopher Tubbs Date: Mon, 22 Jul 2024 20:34:33 -0400 Subject: [PATCH 1/7] Proposed update to bylaws 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. --- contributor/bylaws.md | 422 ++++++++++++------------------ contributor/consensusBuilding.md | 2 +- contributor/contributors-guide.md | 4 - contributor/lazyConsensus.md | 58 ---- contributor/voting.md | 99 ------- 5 files changed, 168 insertions(+), 417 deletions(-) delete mode 100644 contributor/lazyConsensus.md delete mode 100644 contributor/voting.md diff --git a/contributor/bylaws.md b/contributor/bylaws.md index 05158cc46..b16d8087e 100644 --- a/contributor/bylaws.md +++ b/contributor/bylaws.md @@ -5,146 +5,132 @@ redirect_from: - /governance/bylaws --- -This is version 3 of the bylaws. Community work actively continues on the -bylaws, and so key segments of them are subject to change. +This is version 4 of our project's bylaws and is subject to change. # Introduction -This document defines the bylaws under which the Apache Accumulo project -operates. It defines the roles and responsibilities of the project, who may -vote, how voting works, how conflicts are resolved, etc. +Accumulo is a project of the [Apache Software Foundation (ASF)][foundation]. +More details about the Foundation can be found on its pages. -Accumulo is a project of the [Apache Software Foundation][foundation]. The -foundation holds the copyright on Apache code including the code in the -Accumulo codebase. The [foundation FAQ][foundation-faq] explains the operation -and background of the foundation. - -Accumulo is typical of Apache projects in that it operates under a set of -principles, known collectively as the Apache Way. If you are new to Apache +Accumulo is a typical ASF project, operating under a set of principles known +collectively as [the Apache Way][thisistheway]. If you are new to ASF development, please refer to the [Incubator project][incubator] for more -information on how Apache projects operate. Terms used at the ASF are defined -in the [ASF glossary][glossary]. +information on how ASF projects operate. + +Terms used at the ASF are defined in the [ASF glossary][glossary]. + +While this project generally follows standard procedures used by most projects +across the ASF, the purpose of this document is to define bylaws that apply +specifically to the Accumulo project. These bylaws establish ground rules for +handling situations where either there is no standard procedure within the ASF, +or where we've chosen to diverge from those procedures. If a situation is not +covered by these bylaws, then it is assumed that we will follow standard +procedures established by the Foundation. If standard procedures do not exist, +then a decision should be made following a discussion on an appropriate mailing +list for the project. + # Roles and Responsibilities -Apache projects define a set of roles with associated rights and -responsibilities. These roles govern what tasks an individual may perform -within the project. The roles are defined in the following sections. +The roles in this project, and their associated responsibilities, are the +standard roles defined within the Foundation's [own documents][how-it-works]. + +This project establishes the following additional procedures for specific +roles below. -## Users +## Committers -The most important participants in the project are people who use our software. -The majority of our contributors start out as users and guide their development -efforts from the user's perspective. +The Committer role is defined by [the Foundation][how-it-works]. Additional +information can be found on the [Committers page][committer-faq]. -Users contribute to the Apache projects by providing feedback to contributors -in the form of bug reports and feature suggestions. As well, users participate -in the Apache community by helping other users on mailing lists and user -support forums. +Upon acceptance of an invitation to become a committer, it is the accepting +committer's responsibility to update their status on the Accumulo web page +accordingly, and to make updates as needed. -## Contributors +All committers should use their privileges carefully, and ask for help if they +are uncertain about the risks of any action. -All of the volunteers who are contributing time, code, documentation, or -resources to the Accumulo project are considered contributors. A contributor -that makes sustained, welcome contributions to the project may be invited to -become a committer, though the exact timing of such invitations depends on many -factors. +In order to maintain a low barrier to entry, and to encourage project growth +and diversity of perspectives, it is the custom of the Accumulo project to also +invite each committer to become a member of its Project Management Committee +(PMC). However, this is not a requirement and the current PMC may elect to only +invite a contributor to become a committer without inviting them to become a +PMC member, depending on the circumstances. If invited to both, invitees may +also decline the invitation to the PMC role and only accept the committer role. -## Committers +## Project Management Committee (PMC) Member + +The PMC Member role is defined by [the Foundation][how-it-works]. Additional +information can be found in the [PMC Guide][pmc-guide]. -The project's committers are responsible for the project's technical -management. Committers have write access to the project's code repositories and -may cast binding votes on any technical discussion regarding Accumulo. -Committer access is by invitation only and must be approved by consensus -approval of the active PMC members. Upon acceptance of the invitation to become -a committer, it is the accepting member’s responsibility to update their status -on the Accumulo web page accordingly. - -A committer is considered emeritus, meaning inactive, by their own declaration -or by not reviewing patches or committing patches to the project for over six -months. Emeritus members will be recognized by the PMC on the Accumulo web -page, in honor of their past contributions. Emeritus members retain all voting -and commit rights associated with their former designation and can move -themselves out of emeritus status by sending an announcement of their return to -the developer mailing list. It will be the returning member's responsibility to -update their status on the web page accordingly. - -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. - -All Apache committers are required to have a signed [Contributor License -Agreement][icla] (CLA) on file with the Apache Software Foundation. Under the -terms of the CLA 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). -There is a [Committer FAQ][committer-faq] which provides more details on the -requirements for committers. - -It is the custom of the Accumulo project to also invite each committer to -become a member of the Accumulo PMC. - -## Project Management Committee - -The role of the PMC, from a Foundation perspective, is [oversight][pmc-howto]. -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. - -The responsibilities of the PMC include: - -* Deciding what is distributed as products of the Apache Accumulo project. -* Maintaining the project's shared resources, including the code repository, mailing lists, and websites. -* Protecting and ensuring proper use of Apache trademarks by the project and by other parties. -* Speaking on behalf of the project. -* Nominating new PMC members and committers. -* Maintaining these bylaws and other guidelines of the project. +Some specific responsibilities of the PMC for Accumulo include: + +* Voting on releases to determine what is distributed as a product of the Accumulo project +* Maintaining the project's shared resources, including the code repository, mailing lists, and websites +* Protecting ASF trademarks, including the Accumulo name and logo, and ensuring their proper use by others +* Subscribing to the private mailing list and engaging in decisions and discussions +* Speaking on behalf of the project +* Nominating new PMC members and committers +* Maintaining these bylaws and other guidelines of the project In particular, PMC members must understand both our project's criteria and ASF -criteria for voting on a [release][release-management]. See the [PMC -Guide][pmc-guide] for more information on PMC responsibilities. - -Membership of the PMC is by invitation only and must be approved by a consensus -approval of active PMC members. Upon acceptance of the invitation to become a -PMC member, it is the accepting member’s responsibility to update their status -on the Accumulo web page accordingly. - -A PMC member is considered emeritus, meaning inactive, by their own declaration -or by not contributing in any form to the project for over six months. Emeritus -members will be recognized by the PMC on the Accumulo web page, in honor of -their past contributions. Emeritus members retain all voting and commit rights -associated with their former designation and can move themselves out of -emeritus status by sending an announcement of their return to the developer -mailing list. It will be the returning member's responsibility to update their -status on the web page accordingly. - -The chair of the PMC is appointed by the ASF board. The chair is an office -holder of the Apache Software Foundation (Vice President, Apache Accumulo) and -has primary responsibility to the board for the management of the projects -within the scope of the Accumulo PMC. The chair reports to the board quarterly -on developments within the Accumulo project. - -When the current chair of the PMC resigns, the PMC votes to recommend a new -chair using consensus approval, but the decision must be ratified by the Apache -board. - -## Release Manager +criteria for voting on a [release][release-management]. + +Upon acceptance of an invitation to become a PMC member, it is the accepting +member's responsibility to update their status on the Accumulo web page +accordingly, and to make updates as needed. + +Because the PMC is a role within the Foundation, changes to PMC membership +follow criteria established by the board. In general, this means that the board +chooses who gets added or removed from the PMC, but they may delegate that +authority to existing PMC members or the PMC chair. However, it is this +project's practice to collectively make decisions about PMC additions among the +existing PMC members on the project's private mailing list. Accordingly, the +existing PMC members will conduct a vote before inviting new PMC members, so +long as that vote can be done without violating the board's current procedures. +Depending on the current board procedures, this vote may be merely advisory. +Additionally, no vote will be conducted without first being preceeded by a +discussion period of at least 72 hours. + +PMC members may voluntarily resign from the PMC at any time by their own +request, and following the appropriate procedures for PMC membership changes +established by the board. These former members will be recognized as "Emeritus" +PMC members on the Accumulo web site, in honor of their past contributions. +Having resigned from the PMC role, these former members will no longer have any +privileges of PMC membership, such as binding votes for releases or other +project decisions. However, they will retain any committer privileges, and may +retain access to the PMC's private mailing list. Emeritus PMC members, having +voluntarily resigned, may request to rejoin the PMC and restore their +privileges, without a vote of the existing PMC members, provided that all other +procedures for PMC membership changes established by the board are followed. + +## PMC Chair + +The chair of the PMC (PMC Chair) is appointed by the ASF board. The chair is an +office holder of the Apache Software Foundation (Vice President, Apache +Accumulo) and has primary responsibility to the board for the management of the +projects within the scope of the Accumulo PMC. The chair reports to the board +quarterly on developments within the Accumulo project. + +The current PMC members may at any time vote to recommend a new chair (such as +when the current chair declares their desire to resign from the role), but the +decision must be ratified by the Apache board before the recommended person can +assume the role. + +In the event that the PMC Chair is delegated any special authority by the board +to make decisions for the project, that they will first make a good faith +effort to achieve consensus from the existing PMC members, and will act without +such consensus only if necessary. For example, if the board delegates the +authority to make additions to the PMC membership, the chair should follow the +discussion and advisory vote procedure described in the previous section of +these bylaws. + +# Releases The [ASF release process][release-pub] defines the [release manager][release-manager] as an individual responsible for shepherding a new -project release. Any committer may serve as a release manager. The release -manager for a release is chosen as part of the release plan. +project release. Any committer may serve as a release manager by initiating a +release candidate and starting a vote for a release. At a minimum, a release manager is responsible for packaging a release candidate for a vote and signing and publishing an approved release candidate. @@ -154,8 +140,9 @@ An Accumulo release manager is also expected to: * ensure that required release testing is being conducted * track whether the release is on target for its expected release date * adjust release plan dates to reflect the latest estimates -* determine if a re-plan may be needed and, if so, call a vote -* call votes on release candidates +* terminate a release vote by either withdrawing a release candidate from consideration, if needed +* tally the votes and record the vote result after a release vote period has elapsed +* ensure any post-release tasks are performed, such as updating the website and publishing artifacts Details on [making][making] and [verifying][verifying] a release are available on the Accumulo website. @@ -163,10 +150,9 @@ on the Accumulo website. # Decision Making Within the Accumulo project, different types of decisions require different -forms of approval. For example, the previous section describes several -decisions which require 'consensus approval'. This section defines how voting -is performed, the types of approvals, and which types of decision require which -type of approval. +forms of approval. For example, the previous section describes 'consensus' from +the existing PMC members. Consensus in that case can be achieved through a +[consensus approval vote][consensus]. ## Voting @@ -174,142 +160,68 @@ Decisions regarding the project are made by votes on the primary project development mailing list: dev@accumulo.apache.org. Where necessary, PMC voting may take place on the private Accumulo PMC mailing list: private@accumulo.apache.org. Votes are clearly indicated by a subject line -starting with [VOTE]. A vote message may only pertain to a single item’s -approval; multiple items should be separated into multiple messages. Voting is -carried out by replying to the vote mail. A vote may take on one of four forms, -defined below. - -{: .table } -| Vote | Meaning | -|------|---------| -| +1 | *Yes*, *Agree*, or *The action should be performed*. In general, this vote also indicates a willingness on the behalf of the voter to *make it happen*. | -| +0 | This vote indicates a willingness for the action under consideration to go ahead. The voter, however, will not be able to help. | -| -0 | This vote indicates that the voter does not, in general, agree with the proposed action but is not concerned enough to prevent the action going ahead. | -| -1 | *No*, *Disagree*, or *The action should not be performed*. On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. It may also be appropriate for a -1 vote to include an alternative course of action. | - -All participants in the Accumulo project are encouraged to vote. For technical -decisions, only the votes of active committers are binding. Non-binding votes -are still useful for those with binding votes to understand the perception of -an action across the wider Accumulo community. For PMC decisions, only the -votes of active PMC members are binding. - -See the [voting page][voting] for more details on the mechanics of voting. +starting with `[VOTE]`. After the vote period has elapsed, the initiator of the +vote, or their designee, closes it by replying to the thread with the results +of the vote. That result email should use the same subject line preceded by +`[RESULT][VOTE]`. Voting is carried out by replying to the vote mail and +continues until the vote is closed. If a vote thread becomes inactive and +remains open for too long, without a response from the initiator, the PMC Chair +may close the vote. + +All participants in the Accumulo project are encouraged to vote. However, some +votes are considered non-binding (such as votes from non-PMC members during a +release vote). However, non-binding votes are still useful to gain insight into +the community's view of the vote topic. + +Each person gets only a single vote. You can change your vote by replying to +the same vote thread to explain the change prior to the vote being closed. + +For more information on how to vote, see the Foundation's page on +[voting][voting]. + +The Foundation defines voting criteria for procedural issues, code +modifications, and releases. Most formal votes are going to be [consensus +approval][consensus]. Release votes, however, follow [majority +approval][majority]. Other decisions, when necessary, can often be made through +[lazy consensus][lazy]. In the case of an objection for a lazy consensus vote, +or the desire for explicit consensus, one can initiate a formal vote thread. + +All votes should last a minimum of 72 hours. ## Commit Then Review (CTR) -Voting can also be applied to changes to the Accumulo codebase. Under the -Commit Then Review policy, committers can make changes to the codebase without -seeking approval beforehand, and the changes are assumed to be approved unless -an objection is raised. Only if an objection is raised must a vote take place -on the code change. - -For some code changes, committers may wish to get feedback from the community -before making the change. It is acceptable for a committer to seek approval -before making a change if they so desire. - -## Approvals - -These are the types of approvals that can be sought. Different actions require -different types of approvals. - -{: .table } -| Approval Type | Definition | -|-----------------------------------|--------------------------------------------------------------------------------------------------| -| Consensus Approval | A consensus approval vote passes with 3 binding +1 votes and no binding vetoes. | -| Majority Approval | A majority approval vote passes with 3 binding +1 votes and more binding +1 votes than -1 votes. | -| Lazy Approval (or Lazy Consensus) | An action with lazy approval is implicitly allowed unless a -1 vote is received, at which time, depending on the type of action, either majority approval or consensus approval must be obtained. Lazy Approval can be either *stated* or *assumed*, as detailed on the [lazy consensus page][lazy]. | - -## Vetoes - -A valid, binding veto cannot be overruled. If a veto is cast, it must be -accompanied by a valid reason explaining the veto. The validity of a veto, if -challenged, can be confirmed by anyone who has a binding vote. This does not -necessarily signify agreement with the veto, but merely that the veto is valid. - -If you disagree with a valid veto, you must lobby the person casting the veto -to withdraw their veto. If a veto is not withdrawn, the action that has been -vetoed must be reversed in a timely manner. - -## Actions - -This section describes the various actions which are undertaken within the -project, the corresponding approval required for that action and those who have -binding votes over the action. It also specifies the minimum length of time -that a vote must remain open, measured in days. In general, votes should not be -called at times when it is known that interested members of the project will be -unavailable. - -For Code Change actions, a committer may choose to employ assumed or stated -Lazy Approval under the [CTR][ctr] policy. Assumed Lazy Approval has no minimum -length of time before the change can be made. - -{: .table } -| Action | Description | Approval | Binding Votes | Min. Length (days) | -|---------------------------|-------------------------------------------------------------------------------------------------------------|-------------------------------------------------------|--------------------|--------------------| -| Code Change | A change made to a codebase of the project. This includes source code, documentation, website content, etc. | Lazy approval, moving to consensus approval upon veto | Active committers | 1 | -| Release Plan | Defines the timetable and actions for an upcoming release. The plan also nominates a Release Manager. | Lazy approval, moving to majority approval upon veto | Active committers | 3 | -| Release Plan Cancellation | Cancels an active release plan, due to a need to re-plan (e.g., discovery of a major issue). | Majority approval | Active committers | 3 | -| Product Release | Accepts or rejects a release candidate as an official release of the project. | Majority approval | Active PMC members | 3 | -| Adoption of New Codebase | When the codebase for an existing, released product is to be replaced with an alternative codebase. If such a vote fails to gain approval, the existing code base will continue. This also covers the creation of new sub-projects within the project. | Consensus approval | Active PMC members | 7 | -| New Committer | When a new committer is proposed for the project. | Consensus approval | Active PMC members | 3 | -| New PMC Member | When a committer is proposed for the PMC. | Consensus approval | Active PMC members | 3 | -| New PMC Chair | When a new PMC chair is chosen to succeed an outgoing chair. | Consensus approval | Active PMC members | 3 | -| Modifying Bylaws | Modifying this document. | Consensus approval | Active PMC members | 7 | - -No other voting actions are defined; all other actions should presume Lazy -Approval (defaulting to Consensus Approval upon veto). If an action is voted on -multiple times, or if a different approval type is desired, these bylaws should -be amended to include the action. - -For the purposes of the "Adoption of New Codebase" action, the Accumulo -codebase is defined as the Accumulo site content, primary project code, and all -contributed code ("contribs") as they exist in their respective repositories. -Adoption of a new codebase generally refers to the creation of a new contrib -repository, but could cover, for example, a rework of the project site, or -merging a contrib project into the primary codebase. - -Voting actions for the removal of a committer or PMC member are intentionally -not defined. According to ASF rules, [committer status never -expires][committer-terms] and [PMC members can only be removed with approval -from the ASF Board][pmc-removal]. - -# Release Plans - -The approval of a release plan begins the process of creating a new project -release. The process ends when a release candidate is approved. - -An Accumulo release plan consists of at least the following: - -* a version number -* a feature freeze date -* a code freeze date -* a release date -* the choice of a release manager - -After feature freeze, new features should not be accepted for the release. -After code freeze, only critical fixes should be accepted for the release. The -release manager guides the decision on accepting changes. - -All dates in a plan are estimates, as unforeseen issues may require delays. The -release manager may adjust dates as needed. In serious circumstances, the -release manager may opt to call a re-plan vote. +Accumulo follows a commit-then-review (CTR) policy. This only means that it is +not strictly a requirement to achieve consensus prior to committing code +changes to the code repository. Committers can make changes to the codebase +without seeking approval beforehand, and those changes are assumed to be +approved unless an objection is raised afterwards. Only if an objection is +raised must a vote take place on the code change. + +However, just because committers can do this, it does not mean it is a always a +good idea. Committers are expected to use their privileges responsibly and to +minimize risks. Therefore, it is often is a good idea for committers to seek +feedback through code reviews from the community. Code reviews are our standard +practice and strongly encouraged for anything non-trivial. They are also +strongly encouraged for new committers, even if a change is trivial. If +approval is bypassed, and a problem occurs, committers may be expected to +answer questions about their commit in order to understand what went wrong and +how to avoid problems in the future. So, committers should take care to not +abuse the CTR policy, and to use it sparingly and in ways they can justify. +[committer-faq]: https://www.apache.org/dev/committers +[consensus]: https://www.apache.org/foundation/glossary#ConsensusApproval [foundation]: https://www.apache.org/foundation -[foundation-faq]: https://www.apache.org/foundation/faq -[incubator]: https://incubator.apache.org [glossary]: https://www.apache.org/foundation/glossary -[icla]: https://www.apache.org/licenses/icla.txt -[committer-faq]: https://www.apache.org/dev/committers -[pmc-howto]: https://www.apache.org/foundation/how-it-works.html#pmc -[release-management]: https://www.apache.org/dev/release#management +[how-it-works]: https://www.apache.org/foundation/how-it-works +[incubator]: https://incubator.apache.org +[lazy]: https://www.apache.org/foundation/glossary#LazyConsensus +[majority]: https://www.apache.org/foundation/glossary#MajorityApproval +[making]: {{ "/contributor/making-release" | relative_url }} [pmc-guide]: https://www.apache.org/dev/pmc -[release-pub]: https://www.apache.org/dev/release-publishing +[release-management]: https://www.apache.org/dev/release#management [release-manager]: https://www.apache.org/dev/release-publishing#release_manager -[making]: {{ "/contributor/making-release" | relative_url }} +[release-pub]: https://www.apache.org/dev/release-publishing +[thisistheway]: https://www.apache.org/theapacheway [verifying]: {{ "/contributor/verifying-release" | relative_url }} -[voting]: {{ "/contributor/voting" | relative_url }} -[ctr]: #commit-then-review-ctr -[committer-terms]: https://www.apache.org/dev/committers#committer-set-term -[pmc-removal]: https://www.apache.org/dev/pmc#pmc-removal -[lazy]: {{ "/contributor/lazyConsensus" | relative_url }} +[voting]: https://www.apache.org/foundation/voting diff --git a/contributor/consensusBuilding.md b/contributor/consensusBuilding.md index ce8c215cc..c4a0cceaf 100644 --- a/contributor/consensusBuilding.md +++ b/contributor/consensusBuilding.md @@ -50,4 +50,4 @@ or not. Once there is a clear consensus, members of the community can proceed with the work under the [lazy consensus][1] model. -[1]: {{ site.baseurl }}/contributor/lazyConsensus +[1]: https://www.apache.org/foundation/glossary#LazyConsensus diff --git a/contributor/contributors-guide.md b/contributor/contributors-guide.md index 5d27b71b8..3c280b7db 100644 --- a/contributor/contributors-guide.md +++ b/contributor/contributors-guide.md @@ -56,8 +56,6 @@ For details about governance policies for the Accumulo project view the followin - [Bylaws][bylaws] - [Consensus Building][consensus] -- [Lazy Consensus][lazy] -- [Voting][voting] [How to Contribute]: /how-to-contribute/ [newbie-issues]: https://s.apache.org/newbie_accumulo_tickets @@ -69,7 +67,5 @@ For details about governance policies for the Accumulo project view the followin [testing]: /contributor/testing-release [bylaws]: {{ site.baseurl }}/contributor/bylaws [consensus]: {{ site.baseurl }}/contributor/consensusBuilding -[lazy]: {{ site.baseurl }}/contributor/lazyConsensus -[voting]: {{ site.baseurl }}/contributor/voting [IntelliJ]: https://www.jetbrains.com/idea/download [Eclipse]: https://www.eclipse.org/downloads/packages diff --git a/contributor/lazyConsensus.md b/contributor/lazyConsensus.md deleted file mode 100644 index 20c1cc54a..000000000 --- a/contributor/lazyConsensus.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: Lazy Consensus -redirect_from: /governance/lazyConsensus ---- - -The concept of "Lazy Consensus" is very important in our project. Lazy -Consensus means that when you are convinced that you know what the community -would like to see happen you can simply assume that you already have consensus -and get on with the work. You don't have to insist people discuss and/or -approve your plan, and you certainly don't need to call a vote to get approval. -You just assume you have the community's support unless someone says otherwise. - -We have a time machine (Subversion), this means that as long as you commit -(or submit patches) early and often the community has plenty of opportunity -to indicate disapproval. If you believe the community will support your action -you can operate on lazy consensus as long as you are prepared to roll back -any work should a valid objection is raised. - -## Avoiding Unnecessary Discussion - -The key thing about lazy consensus is that it's easier for people to agree, -by doing nothing, than it is to object, which requires an -alternative to be proposed. This has two effects, firstly people are less -likely to object for the sake of it and secondly it cuts down on the amount -of unnecessary mail traffic and discussion. - -Lazy consensus means we can avoid waiting for a community based decision -before proceeding. However, it does require everyone who cares for the health -of the project to watch what is happening, as it is happening. Objecting too -far down the road will cause upset, but objecting (or asking for clarification -of intent) early is likely to be greeted with relief that someone is watching -and cares. - -## Stating Lazy Consensus - -Sometimes a member of the community will believe a specific action is the correct -one for the community but are not sure enough to proceed with the work under the -lazy consensus model. In these circumstances, they can state Lazy Consensus is in -operation. - -What this means is that they make a proposal and state that they will start -implementing it in 72 hours unless someone objects. 72 hours is chosen because -it accounts for different timezones and non-apache commitments. - -In this approach the original proposal is not insisting that there is a discussion -around their proposal, nor are they requesting that the community explicitly -supports their actions. However, this differs from assuming lazy consensus -since it allows space and time to [express support or objections][1] and corrections to -the proposal before work begins. - -## Silence is consent - -People may choose to indicate their support for the actions taken with a +1 -mail - quick and easy to read and reassuring for the implementer. However, -remember, in a lazy consensus world silence is the equivalent to support. This -can take some time to get used to. - -[1]: {{ site.baseurl }}/contributor/consensusBuilding diff --git a/contributor/voting.md b/contributor/voting.md deleted file mode 100644 index 4c633a5f7..000000000 --- a/contributor/voting.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Voting -redirect_from: /governance/voting ---- - -Occasionally a "feel" for consensus is not enough. Sometimes we need to have a -measurable consensus. For example, when voting in new committers or to approve a -release. - -## Preparing for a Vote - -Before calling a vote, it is important to ensure that the community is given time to -discuss the upcoming vote. This will be done by posting an email to the list -indicating the intention to call a vote and the options available. By the time a -vote is called, there should already be [consensus in the community][1]. The vote -itself is, normally, a formality. - -## Calling a Vote - -Once it is time to call the vote a mail is posted with a subject starting with -"[VOTE]". This enables the community members to ensure they do not miss an important -vote thread. It also indicates that this is not consensus building but a formal -vote. The initiator is responsible for the vote. That means also to count the votes -and present the results. Everyone has 1 vote. - -### Casting Your Vote - -The notation used in voting is: - -+1 (means I vote positive) - You can say why you vote positive but it's not a must-have. - - 0 (means I have no strong opinion, aka abstention) - --1 (means I vote negative because of the following reason) - Yes, you must support your objection and provide an alternative course of action - that you are willing and able to implement (where appropriate). - -#### Example for a vote mail: - -``` -Address: private@ -Subject: [VOTE] John Doe should become a regular committer - -Text: -"I would like to propose to vote in John Doe as committer. John has showed in -the last months that he has the skills and oversight for improving things (think -about the last UI change of the "Find" dialog)." - -+1 (means I vote for John) -0 (means I'm not for John but also not against to vote him in) --1 (means I'm not for John because of the following reason(s): - -Voting time frame is finished 72 hours from now until June 30, 12:00 PM UTC. -``` - -#### Example for a reply mail: - -``` -Text: -+1 - -I like his work and want him to stay and to go on with his good improvements. -``` - - -#### Example for a result mail: - -``` -Subject: [VOTE][RESULTS] John Doe should become a regular committer - -Text: -Vote started Thu, Jun 27, 2011 at 12:00 PM UTC, voting is now closed. - -Voting results: - ---- Numbers --- - -+1: 6 - 0: 0 --1: 0 - ---- Details --- - -+1 John -+1 Jane -+1 David -+1 Dolores -+1 Carl -+1 Chris -``` - -[See here for more information][2]
-[See here for more mail templates][3] - - -[1]: consensusBuilding -[2]: https://www.apache.org/foundation/voting -[3]: https://community.apache.org/newcommitter From e3019ec3284488cd464e1378f142d71f5d074dc7 Mon Sep 17 00:00:00 2001 From: Christopher Tubbs Date: Tue, 23 Jul 2024 23:40:57 -0400 Subject: [PATCH 2/7] Apply suggestions from code review Applied suggestions from @keith-turner's code review Co-authored-by: Keith Turner --- contributor/bylaws.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/contributor/bylaws.md b/contributor/bylaws.md index b16d8087e..ad598f815 100644 --- a/contributor/bylaws.md +++ b/contributor/bylaws.md @@ -161,16 +161,16 @@ development mailing list: dev@accumulo.apache.org. Where necessary, PMC voting may take place on the private Accumulo PMC mailing list: private@accumulo.apache.org. Votes are clearly indicated by a subject line starting with `[VOTE]`. After the vote period has elapsed, the initiator of the -vote, or their designee, closes it by replying to the thread with the results -of the vote. That result email should use the same subject line preceded by +vote, or their designee, closes it by replying to the thread with the vote results. + That result email should use the same subject line preceded by `[RESULT][VOTE]`. Voting is carried out by replying to the vote mail and continues until the vote is closed. If a vote thread becomes inactive and remains open for too long, without a response from the initiator, the PMC Chair may close the vote. All participants in the Accumulo project are encouraged to vote. However, some -votes are considered non-binding (such as votes from non-PMC members during a -release vote). However, non-binding votes are still useful to gain insight into +votes are non-binding (such as votes from non-PMC members during a +release vote). Non-binding votes are still useful to gain insight into the community's view of the vote topic. Each person gets only a single vote. You can change your vote by replying to @@ -180,7 +180,7 @@ For more information on how to vote, see the Foundation's page on [voting][voting]. The Foundation defines voting criteria for procedural issues, code -modifications, and releases. Most formal votes are going to be [consensus +modifications, and releases. Most formal votes will be [consensus approval][consensus]. Release votes, however, follow [majority approval][majority]. Other decisions, when necessary, can often be made through [lazy consensus][lazy]. In the case of an objection for a lazy consensus vote, @@ -190,9 +190,8 @@ All votes should last a minimum of 72 hours. ## Commit Then Review (CTR) -Accumulo follows a commit-then-review (CTR) policy. This only means that it is -not strictly a requirement to achieve consensus prior to committing code -changes to the code repository. Committers can make changes to the codebase +Accumulo follows a commit-then-review (CTR) policy. This means that consensus +is not required prior to committing. Committers can make changes to the codebase without seeking approval beforehand, and those changes are assumed to be approved unless an objection is raised afterwards. Only if an objection is raised must a vote take place on the code change. From cd0cbb3f017b526dfeb9cf85c0f628ada7a13060 Mon Sep 17 00:00:00 2001 From: Christopher Tubbs Date: Tue, 23 Jul 2024 23:46:33 -0400 Subject: [PATCH 3/7] Apply formatting changes after code review --- contributor/bylaws.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/contributor/bylaws.md b/contributor/bylaws.md index ad598f815..7eb4c53a3 100644 --- a/contributor/bylaws.md +++ b/contributor/bylaws.md @@ -161,17 +161,17 @@ development mailing list: dev@accumulo.apache.org. Where necessary, PMC voting may take place on the private Accumulo PMC mailing list: private@accumulo.apache.org. Votes are clearly indicated by a subject line starting with `[VOTE]`. After the vote period has elapsed, the initiator of the -vote, or their designee, closes it by replying to the thread with the vote results. - That result email should use the same subject line preceded by +vote, or their designee, closes it by replying to the thread with the vote +results. That result email should use the same subject line preceded by `[RESULT][VOTE]`. Voting is carried out by replying to the vote mail and continues until the vote is closed. If a vote thread becomes inactive and remains open for too long, without a response from the initiator, the PMC Chair may close the vote. All participants in the Accumulo project are encouraged to vote. However, some -votes are non-binding (such as votes from non-PMC members during a -release vote). Non-binding votes are still useful to gain insight into -the community's view of the vote topic. +votes are non-binding (such as votes from non-PMC members during a release +vote). Non-binding votes are still useful to gain insight into the community's +view of the vote topic. Each person gets only a single vote. You can change your vote by replying to the same vote thread to explain the change prior to the vote being closed. @@ -191,9 +191,9 @@ All votes should last a minimum of 72 hours. ## Commit Then Review (CTR) Accumulo follows a commit-then-review (CTR) policy. This means that consensus -is not required prior to committing. Committers can make changes to the codebase -without seeking approval beforehand, and those changes are assumed to be -approved unless an objection is raised afterwards. Only if an objection is +is not required prior to committing. Committers can make changes to the +codebase without seeking approval beforehand, and those changes are assumed to +be approved unless an objection is raised afterwards. Only if an objection is raised must a vote take place on the code change. However, just because committers can do this, it does not mean it is a always a From bbb662749e8e4c74744e13f9a9ad085b9d2a5cbf Mon Sep 17 00:00:00 2001 From: Christopher Tubbs Date: Wed, 7 Aug 2024 03:24:21 -0400 Subject: [PATCH 4/7] Update contributor/bylaws.md Co-authored-by: Dom G. --- contributor/bylaws.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributor/bylaws.md b/contributor/bylaws.md index 7eb4c53a3..b5882bf40 100644 --- a/contributor/bylaws.md +++ b/contributor/bylaws.md @@ -13,7 +13,7 @@ Accumulo is a project of the [Apache Software Foundation (ASF)][foundation]. More details about the Foundation can be found on its pages. Accumulo is a typical ASF project, operating under a set of principles known -collectively as [the Apache Way][thisistheway]. If you are new to ASF +collectively as [The Apache Way][thisistheway]. If you are new to ASF development, please refer to the [Incubator project][incubator] for more information on how ASF projects operate. From 9eb41d5bd1a35023ffeebee3db12ab3bf34ea10b Mon Sep 17 00:00:00 2001 From: Christopher Tubbs Date: Wed, 7 Aug 2024 03:24:39 -0400 Subject: [PATCH 5/7] Update contributor/bylaws.md Co-authored-by: Dom G. --- contributor/bylaws.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributor/bylaws.md b/contributor/bylaws.md index b5882bf40..19920fe73 100644 --- a/contributor/bylaws.md +++ b/contributor/bylaws.md @@ -196,7 +196,7 @@ codebase without seeking approval beforehand, and those changes are assumed to be approved unless an objection is raised afterwards. Only if an objection is raised must a vote take place on the code change. -However, just because committers can do this, it does not mean it is a always a +However, just because committers can do this, it does not mean it is always a good idea. Committers are expected to use their privileges responsibly and to minimize risks. Therefore, it is often is a good idea for committers to seek feedback through code reviews from the community. Code reviews are our standard From ebced610d6f60d138c613bcdc4ff3ed0afe3c08a Mon Sep 17 00:00:00 2001 From: Christopher Tubbs Date: Wed, 7 Aug 2024 03:24:51 -0400 Subject: [PATCH 6/7] Update contributor/bylaws.md Co-authored-by: Dom G. --- contributor/bylaws.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributor/bylaws.md b/contributor/bylaws.md index 19920fe73..7c0a9c66c 100644 --- a/contributor/bylaws.md +++ b/contributor/bylaws.md @@ -198,7 +198,7 @@ raised must a vote take place on the code change. However, just because committers can do this, it does not mean it is always a good idea. Committers are expected to use their privileges responsibly and to -minimize risks. Therefore, it is often is a good idea for committers to seek +minimize risks. Therefore, it is often a good idea for committers to seek feedback through code reviews from the community. Code reviews are our standard practice and strongly encouraged for anything non-trivial. They are also strongly encouraged for new committers, even if a change is trivial. If From 3a7969deee281f13f3887a3c80da79727db2c326 Mon Sep 17 00:00:00 2001 From: Christopher Tubbs Date: Wed, 7 Aug 2024 03:25:11 -0400 Subject: [PATCH 7/7] Update contributor/bylaws.md Co-authored-by: Dom G. --- contributor/bylaws.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributor/bylaws.md b/contributor/bylaws.md index 7c0a9c66c..96dbf8d26 100644 --- a/contributor/bylaws.md +++ b/contributor/bylaws.md @@ -89,7 +89,7 @@ existing PMC members on the project's private mailing list. Accordingly, the existing PMC members will conduct a vote before inviting new PMC members, so long as that vote can be done without violating the board's current procedures. Depending on the current board procedures, this vote may be merely advisory. -Additionally, no vote will be conducted without first being preceeded by a +Additionally, no vote will be conducted without first being preceded by a discussion period of at least 72 hours. PMC members may voluntarily resign from the PMC at any time by their own