Remove the CB construct and all references to CBs (#17)

* Remove the CB construct and all references to CBs

* Add project graduation to the life cycle document

Author: kborchers

BasePolicies/CB-Charter.md

@@ -1,13 +1,12 @@
-## Collaboration Board, Working Group and Project Code of Conduct
+## Working Group and Project Code of Conduct
 
-Every Collaboration Board (CB), Working Group (WG) or other defined governing
-body must have a Code of Conduct. By default, all repositories under the JS
-Foundation owned GitHub organizations fall under the
-[JS Foundation Code of Conduct][], but CBs, WGs and other defined governing
-bodies can choose to define their own alternative policy. If the governing body
-does choose it's own Code of Conduct, it must be documented in a
-`CODE_OF_CONDUCT.md` file located in the root of any repository under their
-stewardship.
+Every Working Group (WG) or other defined governing body must have a Code of
+Conduct. By default, all repositories under the JS Foundation owned GitHub
+organizations fall under the [JS Foundation Code of Conduct][], but WGs and
+other defined governing bodies can choose to define their own alternative
+policy. If the governing body does choose it's own Code of Conduct, it must be
+documented in a `CODE_OF_CONDUCT.md` file located in the root of any repository
+under their stewardship.
 
 Note that the Code of Conduct adopted by any governing body will be evaluated by
 the TAC prior to ratifying the proposed charter. If that Code of Conduct is
@@ -24,3 +23,4 @@ body's repository. Should the governing body choose not to adopt the recommended
 changes, the governing body's charter may be revoked.
 
 [JS Foundation Code of Conduct]: https://js.foundation/conduct/
+

BasePolicies/CODE_OF_CONDUCT.md

@@ -18,11 +18,6 @@ contributors can be involved in decision making.
 request.
 * A **Committer** is a subset of contributors who have been given write
 access to the repository.
-* A **Collaboration Board (CB)** is a group of committers and other
-representatives from the Project(s) community representing the required
-technical and advisory expertise to guide the Project(s) in policy review and
-enforcement, to encourage openness and a participatory environment and to
-resolve rare technical disputes.
 
 # Logging Issues
 
@@ -41,7 +36,7 @@ Project's Code of Conduct.
 
 Any change to resources in this repository must be through pull requests. This
 applies to all changes to documentation, code, binary files, etc. Even long term
-committers and TAC/CB members must use pull requests.
+committers and TAC members must use pull requests.
 
 No pull request can be merged without being reviewed.
 
@@ -65,8 +60,8 @@ addressing concerns being expressed by discussion, compromise on the proposed
 change, or withdrawal of the proposed change.
 
 If a contribution is controversial and committers cannot agree about how to get
-it to land or if it should land then it should be escalated to the CB. It is
-expected that only a small minority of issues be brought to the CB for
+it to land or if it should land then it should be escalated to the TAC. It is
+expected that only a small minority of issues be brought to the TAC for
 resolution and that discussion and compromise among Committers be the default
 resolution mechanism.
 
@@ -80,24 +75,4 @@ Committers are expected to follow this policy and continue to send pull
 requests, go through proper review, and have other Committers merge their pull
 requests.
 
-# CB Process
-
-The CB uses a "consensus seeking" process for issues that are escalated to the
-CB. The group tries to find a resolution that has no open objections among CB
-members. If a consensus cannot be reached that has no objections then a majority
-wins vote is called. It is also expected that the majority of decisions made by
-the CB are via a consensus seeking process and that voting is only used as a
-last-resort.
-
-Resolution may involve returning the issue to Committers with suggestions on how
-to move forward towards a consensus. It is not expected that a meeting of the
-CB will resolve all issues on its agenda during that meeting and may prefer to
-continue the discussion happening among the Committers.
-
-Members can be added to the CB at any time. Any Committer can nominate another
-Committer or other qualified community member to the CB and the CB uses its
-standard consensus seeking process to evaluate whether or not to add this new
-member. Members who do not participate consistently at the level of a majority
-of the other members are expected to resign.
-
 [JS Foundation CLA]: https://js.foundation/CLA/

BasePolicies/CONTRIBUTING.md

@@ -1,33 +1,32 @@
-## CB, WG and Project Governance
+## Working Group and Project Governance
 
 Every technical governing body in the Foundation must have a documented
 governance model that describes its basic operation. This must be documented in
 the appropriate repository and referenced by the `README.md`.
 
-## Starting a CB or WG
+## Starting a Working Group
 
-A Collaboration Board (CB) or Working Group (WG) is established by first
-defining a charter that can be ratified by the Technical Advisory Committee
-(TAC). A charter is a *statement of purpose*, a *list of responsibilities* and a
-*list of initial membership*.
+A Working Group (WG) is established by first defining a charter that can be
+ratified by the Technical Advisory Committee (TAC). A charter is a *statement
+of purpose*, a *list of responsibilities* and a *list of initial membership*.
 
 A technical governing body needs 3 initial members. These should be individuals
 already undertaking the work described in the charter.
 
 The list of responsibilities should be specific. The only recourse the TAC has
-over a CB or WG is to revoke the entire charter and take on the work previously
-done by the CB or WG themselves or charter a new CB or WG to take on that work.
+over a WG is to revoke the entire charter and take on the work previously done
+by the WG themselves or charter a new WG to take on that work.
 
 If the responsibilities described in the charter are currently undertaken by
 another governing body then the charter will additionally have to be ratified by
 that governing body.
 
-Additional information for starting a CB or WG can be found in the relevant
-charter template in this directory.
+Additional information for starting a WG can be found in the WG charter template
+in this directory.
 
 ## Meetings
 
-The CB or WG shall meet regularly using tools that enable participation by the
+The WG shall meet regularly using tools that enable participation by the
 community (e.g. quarterly on a Google Hangout On Air, or through any other
 appropriate means selected by the membership). The meeting shall be directed by
 a moderator chosen by the membership. Minutes or an appropriate recording shall
@@ -37,9 +36,9 @@ Items are added to the meeting agenda that are considered contentious or are
 modifications of governance, contribution policy or membership.
 
 Any community member or contributor can ask that something be added to the next
-meeting's agenda by logging a GitHub Issue. Any Collaborator, CB or WG member or
-the moderator can add the item to the agenda by adding the **CB-agenda** or
-**WG-agenda** tag to the issue.
+meeting's agenda by logging a GitHub Issue. Any Collaborator, WG member or the
+moderator can add the item to the agenda by adding the **WG-agenda** tag to the
+issue.
 
 Prior to each meeting the moderator will share the Agenda with members. Members
 can add any items they like to the agenda at the beginning of each meeting.
@@ -56,9 +55,9 @@ if desired.
 
 ## Consensus Seeking Process
 
-CBs and WGs follow a [Consensus Seeking][] decision-making model. When an agenda
-item has appeared to reach a consensus the moderator will ask "Does anyone
-object?" as a final call for dissent from the consensus.
+WGs follow a [Consensus Seeking][] decision-making model. When an agenda item
+has appeared to reach a consensus the moderator will ask "Does anyone object?"
+as a final call for dissent from the consensus.
 
 If an agenda item cannot reach a consensus, a member can call for either a
 closing vote or a vote to table the issue to the next meeting. The call for a
@@ -68,9 +67,9 @@ discussion will continue. Simple majority wins.
 ## Bootstrap Governance
 
 Once the TAC ratifies a charter, the governing body inherits the following
-documentation for governance, contribution, conduct and an MIT LICENSE. The
-governing body is free to change these documents through their own governance
-process, hence the term "bootstrap". It is recommended when starting a CB or WG
-that the appropriate template found in this directory be used.
+documentation for governance, contribution, conduct and an APACHE 2.0 LICENSE.
+The governing body is free to change these documents through their own
+governance process, hence the term "bootstrap". It is recommended when starting
+a WG that the appropriate template found in this directory be used.
 
 [Consensus Seeking]: http://en.wikipedia.org/wiki/Consensus-seeking_decision-making

BasePolicies/Governance.md

@@ -1,25 +1,25 @@
-## Collaboration Board and Working Group Moderation Policy
+## Working Group Moderation Policy
 
-Every Collaboration Board (CB) and Working Group (WG) must have a Moderation
-Policy. By default, all repositories under the JS Foundation owned GitHub
-organizations fall under the [JS Foundation Moderation Policy][], but CBs,
-WGs and other technical governing bodies can choose to define their own
-alternative policy. If the governing body does choose it's own Moderation
-Policy, it must be documented in a `ModerationPolicy.md` file located in the
-root of any repository under their stewardship.
+Every Working Group (WG) must have a Moderation Policy. By default, all
+repositories under the JS Foundation owned GitHub organizations fall under the
+[JS Foundation Moderation Policy][], but WGs and other technical governing
+bodies can choose to define their own alternative policy. If the governing body
+does choose it's own Moderation Policy, it must be documented in a
+`ModerationPolicy.md` file located in the root of any repository under their
+stewardship.
 
 Note that the Moderation Policy adopted by a governing body will be evaluated by
 the TAC prior to ratifying the proposed charter. If that Moderation Policy is
 considered to be weaker than, or diverges too significantly from, the
 [JS Foundation Moderation Policy][], the TAC may defer accepting the charter
 until corrections are made.
 
-Likewise, if the Moderation Policy changes after the CB or WG has already been
+Likewise, if the Moderation Policy changes after the WG has already been
 chartered and the TAC determines that the updated Moderation Policy is weaker
 than, or diverges too significantly from, the
-[JS Foundation Moderation Policy][], the TAC, CB or any Collaborator may
-request that further corrections be made by opening an issue or a PR in the CB's
-or WG's repository. Should the CB or WG choose not to adopt the recommended
-changes, the CB's or WG's charter may be revoked.
+[JS Foundation Moderation Policy][], the TAC or any Collaborator may request
+that further corrections be made by opening an issue or a PR in the WG's
+repository. Should the WG choose not to adopt the recommended changes, the WG's
+charter may be revoked.
 
 [JS Foundation Moderation Policy]: https://github.com/JSFoundation/TAC/blob/master/Moderation-Policy.md

BasePolicies/ModerationPolicy.md

@@ -1,47 +1,35 @@
-## Establishing a new Collaboration Board or Working Group
+## Establishing a new Working Group
 
-A Collaboration Board (CB) or Working Group (WG) is established by first
+A Working Group (WG) is established by first
 defining a charter that can be ratified by the Technical Advisory Committee
 (TAC). A charter is a *statement of purpose*, a *list of responsibilities* and a
-*list of initial membership*.
-
-A WG needs at least 3 initial members while a CB's initial membership is
-determined by the number of Projects involved and is defined in the CB's
-Governance.md. These should be individuals already undertaking the work
-described in the charter.
+*list of initial membership*. A WG needs at least 3 initial members. These
+should be individuals already undertaking the work described in the charter.
 
 The list of responsibilities should be specific. The only recourse the TAC has
 over a WG is to revoke the entire charter and take on the work previously done
-by the working group themselves. The only recourse the TAC has over a CB is to
-revoke the entire charter and either move the projects into other CB(s), into
-the At-large Projects or back into mentorship when necessary.
-
-If the responsibilities described in the charter are currently undertaken by
-another CB or WG then the charter will additionally have to be ratified by that
-CB or WG.
+by the working group themselves. If any of the responsibilities described in the
+charter are currently undertaken by another WG then the charter will
+additionally have to be ratified by that WG.
 
-You can submit a CB or WG charter for ratification by sending a Pull Request to
-the TAC's README.md for new CBs while new WGs send a Pull Request to the TAC's
-WORKING_GROUPS.md document. The CB or WG is considered to be chartered once that
-PR lands. Once ratified the list of members should be maintained in the CB's or
+You can submit a WG charter for ratification by sending a Pull Request to
+the TAC's WORKING_GROUPS.md document. The WG is considered to be chartered once
+that PR lands. Once ratified the list of members should be maintained in the
 WG's README.
 
-### Base Policies for new Collaboration Boards and Working Groups
+### Base Policies for new Working Groups
 
-Once the TAC ratifies a charter, the new CB or WG inherits the policies
-established by the TAC for governance, contribution, conduct and an MIT LICENSE.
-New CBs and WGs are free to change these documents through their own governance
-process but should retain at least the spirit of the original versions. The
-documents and templates in this directory are provided to help bootstrap that
-process:
+Once the TAC ratifies a charter, the new WG inherits the policies established by
+the TAC for governance, contribution, conduct and an APACHE 2.0 LICENSE. New WGs
+are free to change these documents through their own governance process but
+should retain at least the spirit of the original versions. The documents and
+templates in this directory are provided to help bootstrap that process:
 
-* [CB Charter Template][]
 * [WG Charter Template][]
 * [Governance Template][]
 * [Code of Conduct][]
 * [Moderation Policy][]
 
-[CB Charter Template]: CB-Charter.md
 [WG Charter Template]: WG-Charter.md
 [Governance Template]: Governance.md
 [Code of Conduct]: CODE_OF_CONDUCT.md