---
tags: governance
---
# Proposal: Default decision making and acceptance process - Last-updated: 2021-04-08

Please see https://github.com/cncf/cnf-wg/discussions/130 for most recent updates
---

----

The default process covers items which do not need additional discussion and community buy-in. Any item not in the listed in the "exception" list be be accepted after approval from a small number of any community member approvals ([see more below](Requesting-changesnew-content-and-getting-Approval)).

Items needing further discussion and approval are the exception. They will use a different decision making process and are listed in the [Additional Approval Items](#Additional-Approval-Items) list below.

The following list only requires 1 reviewer for approval
- Spelling, grammar, and adding new interested parties

Some examples of items using the default process are:
- Adding new interested parties
- New use cases and changes to existing use cases
- Proposing best practices

## Default process

### Requesting changes/new content and getting Approval

The following changes only require 1 reviewer:
- spelling fixes
- grammar fixes
- adding new interested parties

Changes to other content in the CNF WG repository (including new content) for any item not listed in the [Additional Approval Items](#List-of-items-requiring-additional-approval) list require 5 community reviewers to approve.

Any CNF WG community member may be a reviewer. Reviewers may be added by requesting review access (Github READ role works) via a Github issue.

### Example PR process for a change and approval:

1. Fork repo
1. Make change and/or create new content
1. Create PR against main
1. Tag at least 5 reviewers
1. Reviewers will review the PR and give their feedback: approve, request change, comment w/o approval
1. After 5 approvals from reviewers is reached the PR may be merged

### Merging

1. Anyone with merge access can merge the PR after it has 5 approvals from reviewers

## Roles

- Reviewers - Any community member can be a reviewer
- Note: Granting github repo read access allows a reviewer to be tagged in a PR in the reviews section. Alternatively a review can be tagged in the main description or comments for a PR
- reference k8s review best practices https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#why-is-my-pull-request-not-getting-reviewed

Other roles:
- Mergers - Existing contributors with merge access can invite new contributors to be mergers. These are new members are community members who have already had actions showing community engagement such as reviewing and commenting on existing discussions and PRs.
- Note: This name is an example. We could use the name "Maintainer" though that has additional meaning to most people

## List of items requiring additional approval

This list consists of items that require further discussion and approval before being accepted. The decision making process for items in this list is TBD.

Note: This is a temporary name for this list

### Additional Approval Items
1. This list
1. [Charter](https://github.com/cncf/cnf-wg/blob/master/charter.md)
1. [Governance](https://github.com/cncf/cnf-wg/blob/master/governance.md)
1. [Code of Conduct](https://github.com/cncf/cnf-wg/blob/master/code-of-conduct.md)
1. CNF WG "Approved" Best Practices
- This would be Best Practices which the CNF WG promotes in an approved list. Eg. Baseline Best Practices
- Proposing a best practice is okay with the default process. Marking it as accepted and listing it as a CNF WG approved Best Practice requires additional review and approval