├── .github └── settings.yml ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── CONTRIBUTOR_LADDER.md ├── DESIGN-PROPOSALS.md ├── GOVERNANCE-elections.md ├── GOVERNANCE-maintainer.md ├── GOVERNANCE-subprojects.md ├── GOVERNANCE.md ├── LICENSE ├── MAINTAINERS.md ├── README-template.md ├── README.md └── REVIEWING.md /.github/settings.yml: -------------------------------------------------------------------------------- 1 | repository: 2 | # See https://developer.github.com/v3/repos/#edit for all available settings. 3 | 4 | # The name of the repository. Changing this will rename the repository 5 | name: project-template 6 | 7 | # A short description of the repository that will show up on GitHub 8 | description: CNCF Project Template 9 | 10 | # A URL with more information about the repository 11 | homepage: https://cncf.io/projects 12 | 13 | # The branch used by default for pull requests and when the repository is cloned/viewed. 14 | default_branch: main 15 | 16 | # This repository is a template that others can use to start a new repository. 17 | is_template: true 18 | 19 | # Collaborators: give specific users access to this repository. 20 | # see /governance/roles.md for details on write access policy 21 | # note that the permissions below may provide wider access than needed for 22 | # a specific role, and we trust these individuals to act according to their 23 | # role. If there are questions, please contact one of the chairs. 24 | collaborators: 25 | # Chairs and Admin Help 26 | - username: justaugustus 27 | permission: admin 28 | 29 | - username: jberkus 30 | permission: admin 31 | 32 | - username: parispittman 33 | permission: admin 34 | 35 | - username: idvoretskyi 36 | permission: admin 37 | 38 | - username: caniszczyk 39 | permission: admin 40 | 41 | - username: carolynvs 42 | permission: admin 43 | 44 | # Contributors 45 | # all permissions except admin 46 | 47 | - username: mattklein123 48 | permission: push 49 | 50 | - username: thisisnotapril 51 | permission: push 52 | 53 | - username: karenhchu 54 | permission: push 55 | 56 | - username: dims 57 | permission: push 58 | 59 | - username: geekygirldawn 60 | permission: push 61 | 62 | - username: iennae 63 | permission: push 64 | 65 | # Current TOC liaisons 66 | - username: mattfarina 67 | permission: push 68 | 69 | - username: kgamanji 70 | permission: push 71 | 72 | labels: 73 | - name: help-wanted 74 | color: ffff54 75 | - name: good first issue 76 | color: ff8c00 77 | - name: wg/governance 78 | color: 2f4f4f 79 | - name: wg/maintainer 80 | color: 00ffff 81 | - name: wg/contribgrowth 82 | color: ff00ff 83 | - name: needs-toc-approval 84 | description: Requires approval from the TOC before merging to main 85 | color: b60205 86 | 87 | # additional colors in this palette: 88 | # 7f0000 , 1e90ff, ffdab9, ff69b4 89 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | We follow the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md). 4 | 5 | 10 | Please contact [INSERT EMAIL ADDRESS] or the [CNCF Code of Conduct Committee](mailto:conduct@cncf.io) 11 | in order to report violations of the Code of Conduct. 12 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing Guide 2 | 3 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#introduction) 4 | 5 | * [New Contributor Guide](#contributing-guide) 6 | * [Ways to Contribute](#ways-to-contribute) 7 | * [Find an Issue](#find-an-issue) 8 | * [Ask for Help](#ask-for-help) 9 | * [Pull Request Lifecycle](#pull-request-lifecycle) 10 | * [Development Environment Setup](#development-environment-setup) 11 | * [Sign Your Commits](#sign-your-commits) 12 | * [Pull Request Checklist](#pull-request-checklist) 13 | 14 | Welcome! We are glad that you want to contribute to our project! 💖 15 | 16 | As you get started, you are in the best position to give us feedback on areas of 17 | our project that we need help with including: 18 | 19 | * Problems found during setting up a new developer environment 20 | * Gaps in our Quickstart Guide or documentation 21 | * Bugs in our automation scripts 22 | 23 | If anything doesn't make sense, or doesn't work when you run it, please open a 24 | bug report and let us know! 25 | 26 | ## Ways to Contribute 27 | 28 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#ways-to-contribute) 29 | 30 | We welcome many different types of contributions including: 31 | 32 | * New features 33 | * Builds, CI/CD 34 | * Bug fixes 35 | * Documentation 36 | * Issue Triage 37 | * Answering questions on Slack/Mailing List 38 | * Web design 39 | * Communications / Social Media / Blog Posts 40 | * Release management 41 | 42 | Not everything happens through a GitHub pull request. Please come to our 43 | [meetings](TODO) or [contact us](TODO) and let's discuss how we can work 44 | together. 45 | 46 | ### Come to Meetings 47 | 48 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#come-to-meetings) 49 | 50 | Absolutely everyone is welcome to come to any of our meetings. You never need an 51 | invite to join us. In fact, we want you to join us, even if you don’t have 52 | anything you feel like you want to contribute. Just being there is enough! 53 | 54 | You can find out more about our meetings [here](TODO). You don’t have to turn on 55 | your video. The first time you come, introducing yourself is more than enough. 56 | Over time, we hope that you feel comfortable voicing your opinions, giving 57 | feedback on others’ ideas, and even sharing your own ideas, and experiences. 58 | 59 | ## Find an Issue 60 | 61 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#find-an-issue) 62 | 63 | We have good first issues for new contributors and help wanted issues suitable 64 | for any contributor. [good first issue](TODO) has extra information to 65 | help you make your first contribution. [help wanted](TODO) are issues 66 | suitable for someone who isn't a core maintainer and is good to move onto after 67 | your first pull request. 68 | 69 | Sometimes there won’t be any issues with these labels. That’s ok! There is 70 | likely still something for you to work on. If you want to contribute but you 71 | don’t know where to start or can't find a suitable issue, you can ⚠️ **explain how people can ask for an issue to work on**. 72 | 73 | Once you see an issue that you'd like to work on, please post a comment saying 74 | that you want to work on it. Something like "I want to work on this" is fine. 75 | 76 | ## Ask for Help 77 | 78 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#ask-for-help) 79 | 80 | The best way to reach us with a question when contributing is to ask on: 81 | 82 | ⚠️ **Pick the way(s) that you prefer people ask for help** 83 | 84 | * The original github issue 85 | * The developer mailing list 86 | * Our Slack channel 87 | 88 | ## Pull Request Lifecycle 89 | 90 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#pull-request-lifecycle) 91 | 92 | ⚠️ **Explain your pull request process** 93 | 94 | ## Development Environment Setup 95 | 96 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#development-environment-setup) 97 | 98 | ⚠️ **Explain how to set up a development environment** 99 | 100 | ## Sign Your Commits 101 | 102 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#sign-your-commits) 103 | 104 | ⚠️ **Keep either the DCO or CLA section depending on which you use** 105 | 106 | ### DCO 107 | Licensing is important to open source projects. It provides some assurances that 108 | the software will continue to be available based under the terms that the 109 | author(s) desired. We require that contributors sign off on commits submitted to 110 | our project's repositories. The [Developer Certificate of Origin 111 | (DCO)](https://probot.github.io/apps/dco/) is a way to certify that you wrote and 112 | have the right to contribute the code you are submitting to the project. 113 | 114 | You sign-off by adding the following to your commit messages. Your sign-off must 115 | match the git user and email associated with the commit. 116 | 117 | This is my commit message 118 | 119 | Signed-off-by: Your Name 120 | 121 | Git has a `-s` command line option to do this automatically: 122 | 123 | git commit -s -m 'This is my commit message' 124 | 125 | If you forgot to do this and have not yet pushed your changes to the remote 126 | repository, you can amend your commit with the sign-off by running 127 | 128 | git commit --amend -s 129 | 130 | ### CLA 131 | We require that contributors have signed our Contributor License Agreement (CLA). 132 | 133 | ⚠️ **Explain how to sign the CLA** 134 | 135 | ## Pull Request Checklist 136 | 137 | When you submit your pull request, or you push new commits to it, our automated 138 | systems will run some checks on your new code. We require that your pull request 139 | passes these checks, but we also have more criteria than just that before we can 140 | accept and merge it. We recommend that you check the following things locally 141 | before you submit your code: 142 | 143 | ⚠️ **Create a checklist that authors should use before submitting a pull request** 144 | -------------------------------------------------------------------------------- /CONTRIBUTOR_LADDER.md: -------------------------------------------------------------------------------- 1 | # Contributor Ladder Template 2 | 3 | This is a light contributor ladder template for CNCF projects that requires editing before it is ready to use. Read the markdown comments, ``, for additional guidance. The raw markdown uses `TODO` to identify areas that require customization. 4 | 5 | Particularly, this file provides you with a menu of options for your project. Most projects have 3-4 defined contributor roles. We have outlined more roles below than you may need, so select what makes sense for the structure and size of your project. Other roles should be deleted, or combined into an adjacent role. 6 | 7 | 8 | 9 | 10 | * [Contributor Ladder](#contributor-ladder-template) 11 | * [Community Participant](#community-participant) 12 | * [Contributor](#contributor) 13 | * [Organization Member](#organization-member) 14 | * [Reviewer](#reviewer) 15 | * [Maintainer](#maintainer) 16 | * [Inactivity](#inactivity) 17 | * [Involuntary Removal](#involuntary-removal-or-demotion) 18 | * [Stepping Down/Emeritus Process](#stepping-downemeritus-process) 19 | * [Contact](#contact) 20 | 21 | 22 | ## Contributor Ladder 23 | 24 | Hello! We are excited that you want to learn more about our project contributor ladder! This contributor ladder outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the "ladder" and advance up it as their involvement in the project grows. Our project members are happy to help you advance along the contributor ladder. 25 | 26 | Each of the contributor roles below is organized into lists of three types of things. "Responsibilities" are things that a contributor is expected to do. "Requirements" are qualifications a person needs to meet to be in that role, and "Privileges" are things contributors on that level are entitled to. 27 | 28 | 29 | ### Community Participant 30 | 33 | 34 | Description: A Community Participant engages with the project and its community, contributing their time, thoughts, etc. Community participants are usually users who have stopped being anonymous and started being active in project discussions. 35 | 36 | * Responsibilities: 37 | * Must follow the [CNCF CoC](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) 38 | * How users can get involved with the community: 39 | * Participating in community discussions 40 | * Helping other users 41 | * Submitting bug reports 42 | * Commenting on issues 43 | * Trying out new releases 44 | * Attending community events 45 | * [TODO: Other examples of non-contribution participation] 46 | 47 | 48 | ### Contributor 49 | 50 | 51 | Description: A Contributor contributes directly to the project and adds value to it. Contributions need not be code. People at the Contributor level may be new contributors, or they may only contribute occasionally. 52 | 53 | * Responsibilities include: 54 | * Follow the CNCF CoC 55 | * Follow the project contributing guide 56 | * Requirements (one or several of the below): 57 | * Report and sometimes resolve issues 58 | * Occasionally submit PRs 59 | * Contribute to the documentation 60 | * Show up at meetings, takes notes 61 | * Answer questions from other community members 62 | * Submit feedback on issues and PRs 63 | * Test releases and patches and submit reviews 64 | * Run or helps run events 65 | * Promote the project in public 66 | * Help run the project infrastructure 67 | * [TODO: other small contributions] 68 | * Privileges: 69 | * Invitations to contributor events 70 | * Eligible to become an Organization Member 71 | 72 | 73 | ### Organization Member 74 | 77 | 78 | Description: An Organization Member is an established contributor who regularly participates in the project. Organization Members have privileges in both project repositories and elections, and as such are expected to act in the interests of the whole project. 79 | 80 | An Organization Member must meet the responsibilities and has the requirements of a Contributor, plus: 81 | 82 | * Responsibilities include: 83 | * Continues to contribute regularly, as demonstrated by having at least [TODO: Number] [TODO: Metric] a year, as demonstrated by [TODO: contributor metrics source]. 84 | * Requirements: 85 | * Must have successful contributions to the project, including at least one of the following: 86 | * [TODO: Number] accepted PRs, 87 | * Reviewed [TODO: Number] PRs, 88 | * Resolved and closed [TODO: Number] Issues, 89 | * Become responsible for a key project management area, 90 | * Or some equivalent combination or contribution 91 | * Must have been contributing for at least [TODO: Number] months 92 | * Must be actively contributing to at least one project area 93 | * Must have two sponsors who are also Organization Members, at least one of whom does not work for the same employer 94 | * [TODO: other requirements] 95 | 96 | * Privileges: 97 | * May be assigned Issues and Reviews 98 | * May give commands to CI/CD automation 99 | * Entitled to vote in the [TODO: appropriate election] 100 | * Can be added to [TODO: Repo Host] teams 101 | * Can recommend other contributors to become Org Members 102 | * [TODO: Other Privileges] 103 | 104 | 105 | The process for a Contributor to become an Organization Member is as follows: 106 | 107 | 108 | 1. 109 | 2. 110 | 3. 111 | 112 | ### Reviewer 113 | 114 | 115 | Description: A Reviewer has responsibility for specific code, documentation, test, or other project areas. They are collectively responsible, with other Reviewers, for reviewing all changes to those areas and indicating whether those changes are ready to merge. They have a track record of contribution and review in the project. 116 | 117 | Reviewers are responsible for a "specific area." This can be a specific code directory, driver, chapter of the docs, test job, event, or other clearly-defined project component that is smaller than an entire repository or subproject. Most often it is one or a set of directories in one or more Git repositories. The "specific area" below refers to this area of responsibility. 118 | 119 | Reviewers have all the rights and responsibilities of an Organization Member, plus: 120 | 121 | * Responsibilities include: 122 | * Following the reviewing guide 123 | * Reviewing most Pull Requests against their specific areas of responsibility 124 | * Reviewing at least [TODO: Number] PRs per year 125 | * Helping other contributors become reviewers 126 | * Requirements: 127 | * Experience as a Contributor for at least [TODO: Number] months 128 | * Is an Organization Member 129 | * Has reviewed, or helped review, at least [TODO: Number] Pull Requests 130 | * Has analyzed and resolved test failures in their specific area 131 | * Has demonstrated an in-depth knowledge of the specific area 132 | * Commits to being responsible for that specific area 133 | * Is supportive of new and occasional contributors and helps get useful PRs in shape to commit 134 | * Additional privileges: 135 | * Has GitHub or CI/CD rights to approve pull requests in specific directories 136 | * Can recommend and review other contributors to become Reviewers 137 | 138 | 139 | 140 | 141 | The process of becoming a Reviewer is: 142 | 143 | 1. The contributor is nominated by opening a PR against the appropriate repository, which adds their GitHub username to the OWNERS file for one or more directories. 144 | 2. At least two members of the team that owns that repository or main directory, who are already Approvers, approve the PR. 145 | 146 | 147 | ### Maintainer 148 | 149 | 150 | 151 | Description: Maintainers are very established contributors who are responsible for the entire project. As such, they have the ability to approve PRs against any area of the project, and are expected to participate in making decisions about the strategy and priorities of the project. 152 | 153 | A Maintainer must meet the responsibilities and requirements of a Reviewer, plus: 154 | 155 | * Responsibilities include: 156 | * Reviewing at least [TODO: Number] PRs per year, especially PRs that involve multiple parts of the project 157 | * Mentoring new Reviewers 158 | * Writing refactoring PRs 159 | * Participating in CNCF maintainer activities 160 | * Determining strategy and policy for the project 161 | * Participating in, and leading, community meetings 162 | * Requirements 163 | * Experience as a Reviewer for at least [TODO: Number] months 164 | * Demonstrates a broad knowledge of the project across multiple areas 165 | * Is able to exercise judgment for the good of the project, independent of their employer, friends, or team 166 | * Mentors other contributors 167 | * Can commit to spending at least [TODO: Number] hours per month working on the project 168 | * Additional privileges: 169 | * Approve PRs to any area of the project 170 | * Represent the project in public as a Maintainer 171 | * Communicate with the CNCF on behalf of the project 172 | * Have a vote in Maintainer decision-making meetings 173 | 174 | 175 | Process of becoming a maintainer: 176 | 177 | 1. Any current Maintainer may nominate a current Reviewer to become a new Maintainer, by opening a PR against the root of the [TODO: main repository name] adding the nominee as an Approver in the OWNERS file. 178 | 2. The nominee will add a comment to the PR testifying that they agree to all requirements of becoming a Maintainer. 179 | 3. A majority of the current Maintainers must then approve the PR. 180 | 181 | 185 | 186 | 187 | 198 | 199 | 200 | ## Inactivity 201 | 202 | It is important for contributors to be and stay active to set an example and show commitment to the project. Inactivity is harmful to the project as it may lead to unexpected delays, contributor attrition, and a lost of trust in the project. 203 | 204 | * Inactivity is measured by: 205 | * Periods of no contributions for longer than [TODO: Number] months 206 | * Periods of no communication for longer than [TODO: Number] months 207 | * Consequences of being inactive include: 208 | * Involuntary removal or demotion 209 | * Being asked to move to Emeritus status 210 | 211 | ## Involuntary Removal or Demotion 212 | 213 | Involuntary removal/demotion of a contributor happens when responsibilities and requirements aren't being met. This may include repeated patterns of inactivity, extended period of inactivity, a period of failing to meet the requirements of your role, and/or a violation of the Code of Conduct. This process is important because it protects the community and its deliverables while also opens up opportunities for new contributors to step in. 214 | 215 | 217 | Involuntary removal or demotion is handled through a vote by a majority of the current Maintainers. 218 | 219 | ## Stepping Down/Emeritus Process 220 | If and when contributors' commitment levels change, contributors can consider stepping down (moving down the contributor ladder) vs moving to emeritus status (completely stepping away from the project). 221 | 222 | Contact the Maintainers about changing to Emeritus status, or reducing your contributor level. 223 | 224 | ## Contact 225 | * For inquiries, please reach out to: 226 | * 227 | -------------------------------------------------------------------------------- /DESIGN-PROPOSALS.md: -------------------------------------------------------------------------------- 1 | # Design Proposal Template 2 | 3 | **Authors**: alice alice@example.com, bob jones bob@example.com 4 | 5 | **Begin Design Discussion**: YYYY-MM-DD 6 | 7 | **(optional) Status: **implementable, accepted, deferred, rejected, withdrawn, or replaced 8 | 9 | **Checklist**: 10 | 11 | What goes in this checklist is highly dependent on how your project manages their PRs. The Checklist is intended to serve as a final review for the feature before cutting the release where the feature is available. 12 | 13 | - [ ] Prerequisite 1 14 | - [ ] Prerequisite 2 15 | - [ ] Component 1 16 | - [ ] Component 2 17 | - [ ] Docs 18 | - [ ] Tests 19 | 20 | 21 | 22 | ## Summary/Abstract 23 | 24 | Provide a high-level summary of the proposed change. Keep it short. 25 | 26 | This design process establishes a series of standard practices for planning and recording features or changes proposed for the project. The intent is to provide the project a consistent means to track decisions for historical reference and future plans while fully capturing how the feature or change will come to be. Additional benefits include making the process of building the release changelog easier and faster when the feature or change is ready to be released. It is a combination of a feature and effort-tracking document, a product requirements document, and a design document. 27 | 28 | ## Background 29 | 30 | ### Motivation and problem space 31 | 32 | Describe the need, problem, and motivation for the feature or change and any context required to understand the motivation. 33 | 34 | ### Impact and desired outcome 35 | 36 | Describe any potential impact this feature or change would have. Readers should be able to understand why the feature or change is important. Briefly describe the desired outcome if the change or feature were implemented as designed. 37 | 38 | ### Prior discussion and links 39 | 40 | Often these proposals start as an issue, forum post, email and it's helpful to link to those resources in this section to provide context and credit the right people for the idea. 41 | 42 | It is vital for projects to be able to track the chain of custody for a proposed enhancement from conception through implementation which can sometimes be difficult to do in a single Github issue, especially when it is a larger design decision or cuts across multiple areas of the project. 43 | 44 | The purpose of the design proposal processes is to reduce the amount of "siloed knowledge" in a community. By moving decisions from a smattering of mailing lists, video calls, slack messages, GitHub exchanges, and hallway conversations into a well tracked artifact, the process aims to enhance communication and discoverability. 45 | 46 | ## (Optional) User/User Story 47 | 48 | Define who your the intended users of the feature or change are. Detail the things that your users will be able to do with the feature if it is implemented. Include as much detail as possible so that people can understand the "how" of the system. This can also be combined with the prior sections. 49 | 50 | ## Goals 51 | 52 | List the desired goal or goals that the design is intended to achieve. These goals can be leveraged to structure and scope the design and discussions and may be reused as the "definition of done" - the criteria you use to know the implementation of the design has succeeded in accomplishing its goals. 53 | 54 | ## Non-Goals 55 | 56 | Describe what is out of scope for the design proposal. Listing non-goals helps to focus discussion and make progress. 57 | 58 | ## Proposal 59 | 60 | This is where we get down to the specifics of what the proposal actually is. It should have enough detail that reviewers can understand exactly what you're proposing, but should not include things like API designs or implementation. This section should expand on the desired outcome and include details on how to measure success. 61 | 62 | ## Design Details 63 | 64 | This section should contain enough information to allow the following to occur: 65 | * potential contributors understand how the feature or change should be implemented 66 | * users or operators understand how the feature of change is expected to function and interact with other components of the project 67 | * users or operators can take action to pre-plan any needed changes within their architecture that impacted by the upcoming feature or change if it's approved for implementation 68 | * decisions or opinions on a specific approach are fully discussed and explained 69 | * users, operators, and contributors can gain a comprehensive understanding of compatibility of the feature or change with past releases of the project. 70 | 71 | This may include API specs (though not always required), code snippets, data flow diagrams, sequence diagrams, etc. 72 | 73 | If there's any ambiguity about HOW your proposal will be implemented, this is the place to discuss them. This can also be combined with the proposal section above. It should also address how the solution is backward compatible and how to deal with these incompatibilities, possibly with defaulting or migrations. It may be useful to refer back to the goals and non-goals to assist in articulating the "why" behind your approach. 74 | 75 | ## Impacts / Key Questions 76 | 77 | List crucial impacts and key questions, some of which may still be open. They likely require discussion and are required to understand the trade-offs of the design. During the lifecycle of a design proposal, discussion on design aspects can be moved into this section. After reading through this section, it should be possible to understand any potentially negative or controversial impact of the design. It should also be possible to derive the key design questions: X vs Y. 78 | 79 | This will also help people understand the caveats to the proposal, other important details that didn't come across above, and alternatives that could be considered. It can also be a good place to talk about core concepts and how they relate. It can be helpful to explicitly list the pros and cons of each decision. Later, this information can be reused to update project documentation, guides, and Frequently Asked Questions (FAQs). 80 | 81 | ### Pros 82 | Pros are defined as the benefits and positive aspects of the design as described. It should further reinforce how and why the design meets its goals and intended outcomes. This is a good place to check for any assumptions that have been made in the design. 83 | ### Cons 84 | Cons are defined as the negative aspects or disadvantages of the design as described. This section has the potential to capture outstanding challenge areas or future improvements needed for the project and could be referenced in future PRs and issues. This is also a good place to check for any assumptions that have been made in the design. 85 | ## Risks and Mitigations 86 | 87 | Describe the risks of this proposal and how they can be mitigated. This should be broadly scoped and describe how it will impact the larger ecosystem and potentially adopters of the project; such as if adopters need to immediately update, or support a new port or protocol. It should include drawbacks to the proposed solution. 88 | 89 | ### Security Considerations 90 | 91 | When attempting to identify security implications of the changes, consider the following questions: 92 | * Does the change alter the permissions or access of users, services, components - this could be an improvement or downgrade or even just a different way of doing it? 93 | * Does the change alter the flow of information, events, and logs stored, processed, or transmitted? 94 | * Does the change increase the 'surface area' exposed - meaning, if an operator of the project or user were to go rogue or be uninformed in its operation, do they have more areas that could be manipulated unfavorably? 95 | * What existing security features, controls, or boundaries would be affected by this change? 96 | 97 | This section can also be combined into the one above. 98 | 99 | 100 | ## (Optional) Future Milestones 101 | 102 | List things that the design will enable but that are out of scope for now. This can help understand the greater impact of a proposal without requiring to extend the scope of a proposal unnecessarily. 103 | 104 | ## (Optional) Implementation Details 105 | 106 | Some projects may desire to track the implementation details in the design proposal. Some sections may include: 107 | 108 | ### Testing Plan 109 | 110 | An overview on the approaches used to test the implementation. 111 | 112 | ### Update/Rollback Compatibility 113 | 114 | How the design impacts update compatibility and how users can test rollout and rollback. 115 | 116 | ### Scalability 117 | 118 | Describe how the design scales, especially how changes API calls, resource usage, or impacts SLI/SLOs. 119 | 120 | ### Implementation Phases/History 121 | 122 | Describe the development and implementation phases planned to break up the work and/or record them here as they occur. Provide enough detail so readers may track the major milestones in the lifecycle of the design proposal and correlate them with issues, PRs, and releases occurring within the project. 123 | -------------------------------------------------------------------------------- /GOVERNANCE-elections.md: -------------------------------------------------------------------------------- 1 | # Steering Committee Governance 2 | 3 | [Instructions](https://contribute.cncf.io/maintainers/templates/governance-elections/) 4 | 5 | 6 | 7 | The [TODO: PROJECTNAME] Steering Committee is the governing body of the [TODO: PROJECTNAME] project, 8 | providing decision-making and oversight pertaining to the project bylaws, 9 | sub-organizations, and financial planning. The Steering Committee also defines 10 | the project values and structure. 11 | 12 | This governance is an open, living document, and will continue to 13 | evolve as the community and project change. 14 | 15 | - [Values](#values) 16 | - [Charter](#charter) 17 | - [Delegated authority](#delegated-authority) 18 | - [Committee Meetings](#committee-meetings) 19 | - [Committee Members](#committee-members) 20 | - [Decision process](#decision-process) 21 | - [Getting in touch](#getting-in-touch) 22 | - [Elections](#election-procedure) 23 | - [Timeline](#timeline) 24 | - [Election Officer(s)](#election-officers) 25 | - [Eligibility to Vote](#eligibility-to-vote) 26 | - [Candidate Eligibility](#candidate-eligibility) 27 | - [Voting Procedure](#voting-procedure) 28 | - [Limitations on Company Representation](#limitations-on-company-representation) 29 | - [Vacancies](#vacancies) 30 | - [Changes to the charter](#changes-to-the-charter) 31 | - [Authority, Facilitation, and Decision Making](#authority-facilitation-and-decision-making) 32 | 33 | ## Values 34 | 35 | [TODO: REPLACE the values below with your project's actual values] 36 | 37 | The [TODO: PROJECTNAME] and its leadership embrace the following values: 38 | 39 | * Openness: Communication and decision-making happens in the open and is discoverable for future 40 | reference. As much as possible, all discussions and work take place in public 41 | forums and open repositories. 42 | 43 | * Fairness: All stakeholders have the opportunity to provide feedback and submit 44 | contributions, which will be considered on their merits. 45 | 46 | * Community over Product or Company: Sustaining and growing our community takes 47 | priority over shipping code or sponsors' organizational goals. Each 48 | contributor participates in the project as an individual. 49 | 50 | * Inclusivity: We innovate through different perspectives and skill sets, which 51 | can only be accomplished in a welcoming and respectful environment. 52 | 53 | * Participation: Responsibilities within the project are earned through 54 | participation, and there is a clear path up the contributor ladder into leadership 55 | positions. 56 | 57 | 58 | ## Charter 59 | 60 | The following responsibilities and powers belong to the Steering Committee. 61 | 62 | Technical governance is expected to be performed by the Maintainers of the 63 | various project areas and subprojects, as defined in the appropriate OWNERS files. 64 | 65 | * Delegate ownership of, responsibility for and authority over areas of the 66 | project to specific entities. 67 | * Define, evolve, and defend the vision, mission and the values of the project. 68 | * Charter and refine policy for defining new community groups, and establish 69 | transparency and accountability policies for such groups 70 | * Define and evolve project and group governance structures and policies. 71 | * Act as a final escalation point for disputes in any project repository or 72 | group. 73 | * Request funds and other support from the CNCF (e.g. marketing, press, etc.) 74 | * Coordinate with the CNCF regarding usage of the [TODO: PROJECTNAME] brand and deciding 75 | project scope, core requirements, and conformance, as well as how that brand 76 | can be used in relation to other efforts or vendors. 77 | * Decide, for the purpose of elections, who is a member of standing, and what 78 | privileges that entails. 79 | * Control and delegate access to and establish processes regarding all project 80 | repositories, resources, and assets. 81 | * Appointing the members of the Code of Conduct Committee in order to ensure 82 | responsiveness, diversity, and good judgement. 83 | 84 | ## Delegated authority 85 | 86 | The Steering Committee may choose to delegate its authority to other committees 87 | as-needed. The committee currently recognizes this delegated authority for: 88 | 89 | - [TODO: List of Delegated Authorities] 90 | 91 | ## Committee Meetings 92 | 93 | The Steering Committee meets [TODO: frequency of meetings], or as-needed. 94 | Meetings are held online, and are public by default. 95 | 96 | Given the private nature of some of these discussions (e.g. privacy, private 97 | emails to the committee, code of conduct violations, escalations, disputes 98 | between members, security reports, etc.) some meetings are held in private. 99 | 100 | Meeting notes are available to members of the 101 | [developer mailing list](TODO). 102 | Public meetings will be recorded and the recordings made available publicly. 103 | 104 | Questions and proposals for changes to governance or community procedures are posted as 105 | [issues in the community repo](TODO), and 106 | the Steering Committee invites your feedback there. See 107 | [Getting in touch](#getting-in-touch) for other options. 108 | 109 | ## Committee members 110 | 111 | Seats on the Steering Committee are held by an individual, not by their 112 | employer. 113 | 114 | The current membership of the committee is currently (listed alphabetically by 115 | first name): 116 | 117 | |   | Member | Organization | 118 | | -------------------------------------------------------------- | ---------------- | ------------ | 119 | 120 | 121 | ## Decision process 122 | 123 | The Steering Committee desires to always reach consensus. 124 | 125 | Decisions requiring a vote include: issuing written policy, amending existing 126 | written policy, creating, removing, or modifying a working group, all spending, 127 | hiring, and contracting, official responses to publicly raised issues, or any 128 | other decisions that at least two of the members present decide require a vote. 129 | 130 | Decisions are made in meetings when a quorum of more than half of the members 131 | are present (and all members have been informed of the meeting), and may pass 132 | with more than half the members of the committee supporting it. 133 | 134 | ## Getting in touch 135 | 136 | There are two ways to raise issues to the steering committee for decision: 137 | 138 | 1. Emailing the Steering Committee at 139 | [steering@project.org](TODO). 140 | This is a private discussion list to which all members of the committee have 141 | access. 142 | 2. Open an issue on [the community repository](TODO) and indicate that you would like 143 | attention from the steering committee. 144 | 145 | ## Composition 146 | 147 | The steering committee has [TODO: Number] seats. These seats are 148 | open to any project contributor. See 149 | [candidate eligibility](#candidate-eligibility) for a definition. 150 | 151 | Steering Committee members serve for [TODO: Service Period] terms, staggered in order to 152 | preserve continuity. Every year either [TODO:Number] or [TODO:Remainder] 153 | contributor seats are elected. 154 | 155 | ## Election Procedure 156 | 157 | ### Timeline 158 | 159 | Steering Committee elections are held annually. Six weeks or more before the 160 | election, the Steering Committee will appoint Election Officer(s) (see below). 161 | Four weeks or more before the election, the Election Officer(s) will issue a 162 | call for nominations, publish the list of voters, and open the call for 163 | exceptions. Three days before the election the call for nominations and exceptions 164 | will be closed. The election will be open for voting not less than two weeks and 165 | not more than four. The results of the election will be announced within one 166 | week of closing the election. New Steering Committee members will take office on 167 | [TODO: Date] of each year. 168 | 169 | ### Election Officer(s) 170 | 171 | Six weeks or more before the election, the Steering Committee will appoint 172 | between one and three Election Officer(s) to administer the election. Elections 173 | Officers will be community members in good standing who are eligible to 174 | vote, are not running for Steering in that election, who are not currently part 175 | of the Steering Committee and can make a public promise of impartiality. They 176 | will be responsible for: 177 | 178 | - Making all announcements associated with the election 179 | - Preparing and distributing electronic ballots 180 | - Judging exception requests 181 | - Assisting candidates in preparing and sharing statements 182 | - Tallying voting results according to the rules in this charter 183 | 184 | ### Eligibility to Vote 185 | 186 | Anyone who has at least [TODO:Number] contributions in the last 12 months is 187 | eligible to vote in the Steering election. Contributions are defined as opening PRs, 188 | reviewing and commenting on PRs, opening and commenting on issues, writing 189 | design docs, commenting on design docs, helping people on community forums, participating 190 | in working groups, and other efforts that help advance the project. 191 | 192 | [This dashboard](TODO: Devstats link) 193 | shows only GitHub based contributions and does not capture all the contributions 194 | we value. We expect this metric not to capture everyone who should be eligible 195 | to vote. If a community member has had significant contributions over the past 196 | year but is not captured in Devstats, 197 | they will be able to submit an exception form to the Elections Officer(s) who 198 | will then review and determine whether this member should be eligible to vote. 199 | All exceptions, and the reasons for them, will be recorded and saved by the 200 | officers. 201 | 202 | The electoral roll of all eligible voters will be captured at [TODO: Github election 203 | location] and the voters’ guide will 204 | be captured at [TODO: Github Election info location], 205 | similar to the 206 | [Kubernetes election process](https://github.com/kubernetes/steering/blob/master/elections.md). 207 | 208 | We are committed to an inclusive process and will adapt future eligibility 209 | requirements based on community feedback. 210 | 211 | ### Candidate Eligibility 212 | 213 | Community members must be eligible to vote in order to stand for election (this 214 | includes voters who qualify for an exception). Candidates may self-nominate or 215 | be nominated by another eligible member. There are no term limits for Steering 216 | Committee members. Nothing prevents a qualified member from serving on both Steering 217 | and other groups simultaneously. 218 | 219 | To run for a seat, a candidate must additionally be at least a 220 | project Member as defined in 221 | [ROLES.md](TODO: Link to your contributor ladder). 222 | 223 | ### Voting Procedure 224 | 225 | Elections will be held using a time-limited 226 | [Condorcet](https://en.wikipedia.org/wiki/Condorcet_method) ranking on 227 | using the IRV method. The top vote-getters will be elected to the open seats, 228 | with the exceptions for company representation discussed below. 229 | 230 | ### Limitations on Company Representation 231 | 232 | No more than [TODO: Number] seats may be held by employees of the same organization (or 233 | conglomerate, in the case of companies owning each other). If an 234 | election results in greater than [TODO: Number] employees of the same organization being 235 | selected, the lowest vote getters from any particular employer will be removed until 236 | representation on the committee is down to two. 237 | 238 | If employers change because of job changes, acquisitions, or other events, in a 239 | way that would yield too many seats being held by employees of the same 240 | organization, sufficient members of the committee must resign until only [TODO: Number] 241 | employees of the same employer are left. If it is impossible to find sufficient 242 | members to resign, all employees of that organization will be removed and new 243 | special elections held. In the event of a question of company membership (for 244 | example evaluating independence of corporate subsidiaries) a majority of all 245 | non-involved Steering Committee members will decide. 246 | 247 | ## Vacancies 248 | 249 | In the event of a resignation or other loss of an elected SC member, the 250 | candidate with the next most votes from the previous election will be offered 251 | the seat, provided that person otherwise qualifies to join the SC. This process 252 | will continue until the seat is filled. 253 | 254 | In case this fails to fill the seat, a special election for that position will 255 | be held as soon as possible, unless the regular SC election is less than 7 weeks 256 | away. Eligible voters from the most recent election will vote in the special 257 | election. Eligibility will not be redetermined at the time of the special 258 | election. Any replacement SC member will serve out the remainder of the term for 259 | the person they are replacing, regardless of the length of that remainder. 260 | 261 | ## Changes to the charter 262 | 263 | Changes to this charter may be proposed via a PR on the charter itself. 264 | Amendments are accepted with majority consent of the committee as per the 265 | [decision process](#decision-process) outlined above. 266 | 267 | Proposals and amendments to the charter are available for at least a period of 268 | one week for comments and questions before a vote will occur. 269 | 270 | ## Authority, Facilitation, and Decision Making 271 | 272 | Ideally most decisions will be made at the lowest possible level within the 273 | project: within individual working groups. When this is not possible, Steering 274 | can help facilitate a conversation to work through the contended issue. When 275 | facilitation by the SC does not resolve the contention, the SC may have to 276 | make a decision. 277 | 278 | Note that if the committee is called to resolve contended decisions regularly, it is a 279 | symptom of a larger problem in the community that will need to be addressed. 280 | -------------------------------------------------------------------------------- /GOVERNANCE-maintainer.md: -------------------------------------------------------------------------------- 1 | # [TODO:PROJECTNAME] Project Governance 2 | 3 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/governance-maintainer/) 4 | 5 | 6 | 7 | The [TODO:PROJECTNAME] project is dedicated to creating [TODO:Goals of project]. 8 | This governance explains how the project is run. 9 | 10 | - [Values](#values) 11 | - [Maintainers](#maintainers) 12 | - [Becoming a Maintainer](#becoming-a-maintainer) 13 | - [Meetings](#meetings) 14 | - [CNCF Resources](#cncf-resources) 15 | - [Code of Conduct Enforcement](#code-of-conduct) 16 | - [Security Response Team](#security-response-team) 17 | - [Voting](#voting) 18 | - [Modifications](#modifying-this-charter) 19 | 20 | ## Values 21 | 22 | The [TODO: PROJECTNAME] and its leadership embrace the following values: 23 | 24 | * Openness: Communication and decision-making happens in the open and is discoverable for future 25 | reference. As much as possible, all discussions and work take place in public 26 | forums and open repositories. 27 | 28 | * Fairness: All stakeholders have the opportunity to provide feedback and submit 29 | contributions, which will be considered on their merits. 30 | 31 | * Community over Product or Company: Sustaining and growing our community takes 32 | priority over shipping code or sponsors' organizational goals. Each 33 | contributor participates in the project as an individual. 34 | 35 | * Inclusivity: We innovate through different perspectives and skill sets, which 36 | can only be accomplished in a welcoming and respectful environment. 37 | 38 | * Participation: Responsibilities within the project are earned through 39 | participation, and there is a clear path up the contributor ladder into leadership 40 | positions. 41 | 42 | ## Maintainers 43 | 44 | [TODO: PROJECTNAME] Maintainers have write access to the [project GitHub repository](TODO). 45 | They can merge their own patches or patches from others. The current maintainers 46 | can be found in [MAINTAINERS.md](./MAINTAINERS.md). Maintainers collectively manage the project's 47 | resources and contributors. 48 | 49 | This privilege is granted with some expectation of responsibility: maintainers 50 | are people who care about the [TODO: PROJECTNAME] project and want to help it grow and 51 | improve. A maintainer is not just someone who can make changes, but someone who 52 | has demonstrated their ability to collaborate with the team, get the most 53 | knowledgeable people to review code and docs, contribute high-quality code, and 54 | follow through to fix issues (in code or tests). 55 | 56 | A maintainer is a contributor to the project's success and a citizen helping 57 | the project succeed. 58 | 59 | The collective team of all Maintainers is known as the Maintainer Council, which 60 | is the governing body for the project. 61 | 62 | ### Becoming a Maintainer 63 | 64 | To become a Maintainer you need to demonstrate the following: 65 | 66 | * commitment to the project: 67 | * participate in discussions, contributions, code and documentation reviews 68 | for [TODO: Time Period] or more, 69 | * perform reviews for [TODO:Number] non-trivial pull requests, 70 | * contribute [TODO:Number] non-trivial pull requests and have them merged, 71 | * ability to write quality code and/or documentation, 72 | * ability to collaborate with the team, 73 | * understanding of how the team works (policies, processes for testing and code review, etc), 74 | * understanding of the project's code base and coding and documentation style. 75 | 76 | 77 | A new Maintainer must be proposed by an existing maintainer by sending a message to the 78 | [developer mailing list](TODO: List Link). A simple majority vote of existing Maintainers 79 | approves the application. Maintainers nominations will be evaluated without prejudice 80 | to employer or demographics. 81 | 82 | Maintainers who are selected will be granted the necessary GitHub rights, 83 | and invited to the [private maintainer mailing list](TODO). 84 | 85 | ### Removing a Maintainer 86 | 87 | Maintainers may resign at any time if they feel that they will not be able to 88 | continue fulfilling their project duties. 89 | 90 | Maintainers may also be removed after being inactive, failure to fulfill their 91 | Maintainer responsibilities, violating the Code of Conduct, or other reasons. 92 | Inactivity is defined as a period of very low or no activity in the project 93 | for a year or more, with no definite schedule to return to full Maintainer 94 | activity. 95 | 96 | A Maintainer may be removed at any time by a 2/3 vote of the remaining maintainers. 97 | 98 | Depending on the reason for removal, a Maintainer may be converted to Emeritus 99 | status. Emeritus Maintainers will still be consulted on some project matters, 100 | and can be rapidly returned to Maintainer status if their availability changes. 101 | 102 | ## Meetings 103 | 104 | Time zones permitting, Maintainers are expected to participate in the public 105 | developer meeting, which occurs 106 | [TODO: Details of regular developer or maintainer meeting here]. 107 | 108 | Maintainers will also have closed meetings in order to discuss security reports 109 | or Code of Conduct violations. Such meetings should be scheduled by any 110 | Maintainer on receipt of a security issue or CoC report. All current Maintainers 111 | must be invited to such closed meetings, except for any Maintainer who is 112 | accused of a CoC violation. 113 | 114 | ## CNCF Resources 115 | 116 | Any Maintainer may suggest a request for CNCF resources, either in the 117 | [mailing list](TODO: link to developer/maintainer mailing list), or during a 118 | meeting. A simple majority of Maintainers approves the request. The Maintainers 119 | may also choose to delegate working with the CNCF to non-Maintainer community 120 | members, who will then be added to the [CNCF's Maintainer List](https://github.com/cncf/foundation/blob/main/project-maintainers.csv) 121 | for that purpose. 122 | 123 | ## Code of Conduct 124 | 125 | [Code of Conduct](./code-of-conduct.md) 126 | violations by community members will be discussed and resolved 127 | on the [private Maintainer mailing list](TODO). If a Maintainer is directly involved 128 | in the report, the Maintainers will instead designate two Maintainers to work 129 | with the CNCF Code of Conduct Committee in resolving it. 130 | 131 | ## Security Response Team 132 | 133 | The Maintainers will appoint a Security Response Team to handle security reports. 134 | This committee may simply consist of the Maintainer Council themselves. If this 135 | responsibility is delegated, the Maintainers will appoint a team of at least two 136 | contributors to handle it. The Maintainers will review who is assigned to this 137 | at least once a year. 138 | 139 | The Security Response Team is responsible for handling all reports of security 140 | holes and breaches according to the [security policy](TODO:Link to security.md). 141 | 142 | ## Voting 143 | 144 | While most business in [TODO: PROJECTNAME] is conducted by "[lazy consensus](https://community.apache.org/committers/lazyConsensus.html)", 145 | periodically the Maintainers may need to vote on specific actions or changes. 146 | A vote can be taken on [the developer mailing list](TODO) or 147 | [the private Maintainer mailing list](TODO) for security or conduct matters. 148 | Votes may also be taken at [the developer meeting](TODO). Any Maintainer may 149 | demand a vote be taken. 150 | 151 | Most votes require a simple majority of all Maintainers to succeed, except where 152 | otherwise noted. Two-thirds majority votes mean at least two-thirds of all 153 | existing maintainers. 154 | 155 | ## Modifying this Charter 156 | 157 | Changes to this Governance and its supporting documents may be approved by 158 | a 2/3 vote of the Maintainers. 159 | -------------------------------------------------------------------------------- /GOVERNANCE-subprojects.md: -------------------------------------------------------------------------------- 1 | # [TODO:PROJECTNAME] Project Governance 2 | 3 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/governance-subprojects/) 4 | 5 | 6 | 7 | The [TODO:PROJECTNAME] umbrella project is composed as a federation of individual subprojects, 8 | some independent and some interdependent, each of which focuses on some aspect 9 | of [TODO:Goals of umbrella project]. Our governance reflects this federated structure. 10 | 11 | - [Values](#values) 12 | - [Individual Subroject Governance](#individual-subproject-governance) 13 | - [Steering Committee](#steering-committee) 14 | - [Steering Committee Duties](#steering-committee-duties) 15 | - [Steering Committee Elections](#steering-committee-elections) 16 | - [Code of Conduct Committee](#code-of-conduct-committee) 17 | - [Adding New Subprojects](#adding-new-subprojects) 18 | - [Removing Projects](#removing-projects) 19 | 20 | ## Values 21 | 22 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/governance-subprojects/#values) 23 | 24 | The [TODO: PROJECTNAME] and its leadership embrace the following values: 25 | 26 | * Openness: Communication and decision-making happens in the open and is discoverable for future 27 | reference. As much as possible, all discussions and work take place in public 28 | forums and open repositories. 29 | 30 | * Fairness: All stakeholders have the opportunity to provide feedback and submit 31 | contributions, which will be considered on their merits. 32 | 33 | * Community over Product or Company: Sustaining and growing our community takes 34 | priority over shipping code or sponsors' organizational goals. Each 35 | contributor participates in the project as an individual. 36 | 37 | * Inclusivity: We innovate through different perspectives and skill sets, which 38 | can only be accomplished in a welcoming and respectful environment. 39 | 40 | * Participation: Responsibilities within the project are earned through 41 | participation, and there is a clear path up the contributor ladder into leadership 42 | positions. 43 | 44 | ## Individual Subproject Governance 45 | 46 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/governance-subprojects/#subprojects) 47 | 48 | [TODO:PROJECTNAME]'s Subprojects are: 49 | * [TODO:LIST OF SUBPROJECTS] 50 | 51 | All active Maintainers of each subproject, as defined in the Contributor Ladder, are 52 | members of that subproject's Maintainer Committee, which governs that project. The 53 | subproject's Maintainer Committee is responsible for the following project governance 54 | activities: 55 | 56 | * Ensuring that the subproject creates and publishes regular releases; 57 | * Holding regular, subproject-wide discussions on issues and planning; 58 | * Monthly review of project contributors for advancement on the Contributor Ladder; 59 | * Making final decisions on subproject changes that involve controversial trade-offs; 60 | * Responding to security compromise reports; 61 | * Supporting the Code of Conduct within their subproject and referring violations 62 | to the Code of Conduct Committee. 63 | 64 | Additionally, each subproject's Maintainer Committee will select, by majority vote, 65 | one representative to the Steering Committee. This representative 66 | need not be a member of the subproject's Maintainer Committee, and will be 67 | replaced or renewed by the committee annually. 68 | 69 | Should a member of the Maintainer Committee cease being active in the subproject, 70 | violate the Code Of Conduct, or need to be removed for some other reason, they 71 | may be removed by a 2/3 majority vote of the other Committee members, or a 72 | majority vote of the Steering Committee. 73 | 74 | ## Steering Committee 75 | 76 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/governance-subprojects/#steering-committee) 77 | 78 | The overall [TODO:PROJECTNAME] project is governed by a Steering 79 | Committee, which is selected as follows: 80 | 81 | * One Maintainer representative from each member subproject 82 | * [TODO:Number] general "Community Representatives" 83 | 84 | ### Steering Committee Duties 85 | 86 | The Steering Committee is responsible for the following tasks, any of which may 87 | be delegated to a person or group selected by the committee: 88 | 89 | * Reviewing and deciding on new projects to add to [TODO:PROJECTNAME] 90 | * Communicating with the CNCF on behalf of the project 91 | * Arbitrating inter-project disagreements 92 | * Selecting the Code of Conduct Committee and ratifying CoC judgements 93 | * Removing projects which have become inactive 94 | * Acting on escalated security or code quality issues 95 | * Resolving issues that individual projects are unable to resolve 96 | * Administering project infrastructure, intellectual property, and resources 97 | * Determining overall direction for advocacy and marketing 98 | * Issuing statements on behalf of [TODO:PROJECTNAME] and its subprojects 99 | * Reviewing and approving Contributor Ladder advancement for participants whose 100 | work falls outside of defined subprojects 101 | 102 | In performance of these duties, the Steering Committee will hold a monthly meeting 103 | that is open to all contributors. The Committee may hold additional, closed meetings 104 | in order to discuss non-public issues such as security exploits, CoC enforcement, 105 | and legal questions. 106 | 107 | Steering Committee members are expected to advocate for all of [TODO:PROJECTNAME], 108 | not just certain subprojects or corporate sponsors, comply with and support the 109 | Code of Conduct, and be professional and compassionate in all of their dealings 110 | with project participants. 111 | 112 | ### Steering Committee Elections 113 | 114 | The Community Representative(s) will be elected by the collective Organization 115 | Members of all subprojects, as defined in the Contributor Ladder. They 116 | will be elected annually. 117 | 118 | Once per year, the Steering Committee will select between two and three Election 119 | Officers to run the annual election and sets the dates for the election. Election 120 | Officers should be project Members in good standing, not running for election 121 | themselves, and represent more than one project employer. 122 | 123 | These officers will update the list of eligible Members according to 124 | project records, send out announcements, and conduct the election. The election 125 | starts with a call for nominations, which lasts for at least one week, and will 126 | include a period for project Members to request changes to their voting status. 127 | Candidates may nominate themselves, or they may be nominated by their colleagues. 128 | 129 | The election itself will last for at least one week, and is conducted as a 130 | preference election online, using a method such as Condorcet or IRV. The 131 | Election Officers will announce the selected candidates at the next regular 132 | community meeting. 133 | 134 | ## Code of Conduct Committee 135 | 136 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/governance-subprojects/#code-of-conduct-committee) 137 | 138 | In order to review and enforce the Code of Conduct, the Steering Committee selects 139 | [TODO:Number, suggest "3 to 5"] people to be on the Code of Conduct Committee. 140 | These individuals will be chosen based on their community management and code of 141 | conduct experience, with diverse representation across the committee, including 142 | employer, gender, race, background, and region of the world. To avoid fatigue, 143 | the Steering Committee will replace at least [TODO:Number] member of the CoC 144 | Committee each year. Members of the committee do not need to be members of 145 | [TODO:PROJECTNAME] if they have sufficient other expertise. 146 | 147 | The CoC Committee will receive reports of conduct violations confidentially, 148 | and will discuss them in closed meetings. If a report is determined to be a 149 | violation, they will recommend action on it appropriate to the scale, nature, 150 | and context of the violation, from requiring an apology, up to expulsion of an 151 | individual from the project. In the event that a contributor is to be demoted 152 | or expelled, the CoC Committee will forward this recommendation to the Steering 153 | Committee who will ratify it in a closed meeting. Should a member of the 154 | Steering Committee be the offender or the reporter, this recommendation will 155 | instead be forwarded to the CNCF staff for final arbitration. 156 | 157 | ## Adding New Subprojects 158 | 159 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/governance-subprojects/#adding-and-removing-subprojects) 160 | 161 | During the monthly Steering meeting, any project member may recommend projects 162 | to become a subproject of [TODO:PROJECTNAME]. These projects should have the following 163 | characteristics: 164 | 165 | * Have a mission of [TODO:Goals of umbrella project]; 166 | * Are appropriately licensed and governed or willing to become so; 167 | * Are under active development; 168 | * Consist of high quality code and designs. 169 | 170 | Before submitting an application to the Steering Committee, the applying project 171 | must hold an internal consensus vote of all major contributors to join 172 | [TODO:PROJECTNAME]. The Steering Committee will then review the 173 | application, and decide whether or not to accept it. If it is accepted, the Committee 174 | will assign one person to assist the subproject in their integration. 175 | 176 | In some cases, promising but incomplete projects may be accepted as Experimental 177 | Subprojects. Such Experimental Subprojects will be considered part of 178 | [TODO:PROJECTNAME], but will be marked as Experimental on the website and in code 179 | repositories, in order to inform users. Experimental Subproject Members are considered 180 | Members of [TODO:PROJECTNAME], but the subproject is not entitled to a representative on the 181 | Steering Committee. Steering will review Experimental Subprojects at least twice 182 | per year to determine if they have matured to full subproject status. 183 | 184 | ## Removing Projects 185 | 186 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/required/governance-subprojects/#adding-and-removing-subprojects) 187 | 188 | In some cases, projects will become inactive or unmaintainable, or wish to separate 189 | from [TODO:PROJECTNAME]. Any Steering Committee member may propose removal of a 190 | project on these grounds, and Steering can confirm this with a majority vote. 191 | 192 | Subprojects which still have contributors will then be moved to a repository in 193 | their own namespace. Projects which have ceased all activity are moved to a 194 | [TODO:Name of archive namespace] namespace. 195 | 196 | ## Amendments 197 | 198 | This governance document, and other governance documents of [TODO:PROJECTNAME], 199 | can be amended with a 2/3 majority vote of the Steering Committee. Unless time is of 200 | the essence, the amendment should be circulated in the contributor community for 201 | comment for at least one week before voting. 202 | 203 | Should an amendment be required in order to elect a steering committee, it may 204 | be amended via a majority vote all of the collective subproject maintainers. 205 | -------------------------------------------------------------------------------- /GOVERNANCE.md: -------------------------------------------------------------------------------- 1 | # Project Governance 2 | 3 | Because project governance varies widely, we offer several templates covering 4 | common systems of governance used by various CNCF projects. In order to 5 | adopt them, choose the one closest to how you want your project to be governed, 6 | then rename the appropriate `GOVERNANCE-xxx.md` file to GOVERNANCE.md, 7 | overwriting this file, and customize it. 8 | 9 | See the Contributor Strategy document on [Leadership Selection](https://contribute.cncf.io/maintainers/governance/leadership-selection/) 10 | for more background. Please also review [SustainOSS's Governance Readiness Checklist](https://sustainers.github.io/governance-readiness/) 11 | as preparation for making governance decisions. 12 | 13 | ## Governance Templates Supplied 14 | 15 | `GOVERNANCE-maintainer.md` supplies rules for a simple self-selecting council 16 | of Maintainers as project governance. It assumes that there is no distinction 17 | between the contributors who create the majority of code and documentation for 18 | the project and the group who makes all decisions for the project. This 19 | governance is suitable for small, very unified projects, and is often a good 20 | starting point for project governance. It is based on the Jaeger project's 21 | governance. 22 | 23 | `GOVERNANCE-elections.md` is a template for an elected steering committee, 24 | where senior leadership is elected by the body of contributors. This is a 25 | suitable structure for larger projects with an established community. The 26 | template is based on Kubernetes project governance. 27 | 28 | `GOVERNANCE-subprojects.md` is a template for a "project of projects" where 29 | the CNCF project is more of an umbrella for a bunch of closely related 30 | subprojects. It is based on Konveyor project governance. 31 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /MAINTAINERS.md: -------------------------------------------------------------------------------- 1 | The current Maintainers Group for the [TODO: Projectname] Project consists of: 2 | 3 | | Name | Employer | Responsibilities | 4 | | ---- | -------- | ---------------- | 5 | | | | | 6 | 7 | This list must be kept in sync with the [CNCF Project Maintainers list](https://github.com/cncf/foundation/blob/master/project-maintainers.csv). 8 | 9 | See [the project Governance](GOVERNANCE.md) for how maintainers are selected and replaced. 10 | -------------------------------------------------------------------------------- /README-template.md: -------------------------------------------------------------------------------- 1 | # README 2 | 3 | The is a README template for CNCF projects. Please start by renaming this to 4 | README.md and deleting everything up to and including the "template begins here" 5 | comment in this markdown file. 6 | 7 | This is a template document for CNCF projects that requires editing 8 | before it is ready to use. Read the markdown comments, ``, for 9 | additional guidance. The raw markdown uses `TODO` to identify areas that 10 | require customization. Replace [TODO: PROJECTNAME] with the name of your project. 11 | 12 | 13 | 14 | # Welcome to the [TODO:Projectname] Project! 15 | 16 | 17 | 18 | 19 | 20 | [TODO: PROJECTNAME] is a [TODO: Type of Tool] that [TODO: Functions it 21 | performs]. [TODO: Reasons why these are needed and valuable]. [TODO: 22 | Implementation, strategy and architecture]. 23 | 24 | [TODO: Additional paragraph describing your project (optional)] 25 | 26 | [TODO: PROJECTNAME] is hosted by the [Cloud Native Computing Foundation (CNCF)](https://cncf.io). 27 | 28 | ## Getting Started 29 | 30 | 38 | 39 | ## Contributing 40 | 41 | 42 | Our project welcomes contributions from any member of our community. To get 43 | started contributing, please see our [Contributor Guide](TODO: Link to 44 | CONTRIBUTING.md). 45 | 46 | ## Scope 47 | 48 | 49 | 50 | 51 | ### In Scope 52 | 53 | [TODO: PROJECTNAME] is intended to [TODO: Core functionality]. As such, the 54 | project will implement or has implemented: 55 | 56 | * [TODO: High-level Item 1] 57 | * [TODO: High-level Item 2] 58 | * [TODO: High-level Item 3] 59 | 60 | 61 | ### Out of Scope 62 | 63 | [TODO: PROJECTNAME] will be used in a cloud native environment with other 64 | tools. The following specific functionality will therefore not be incorporated: 65 | 66 | * [TODO: Excluded function 1] 67 | * [TODO: Excluded function 2] 68 | 69 | 70 | [TODO: PROJECTNAME] implements [TODO: List of major features, existing or 71 | planned], through [TODO: Implementation 72 | requirements/language/architecture/etc.]. It will not cover [TODO: short list 73 | of excluded items] 74 | 75 | ## Communications 76 | 77 | 81 | 82 | [TODO: Details (with links) to meetings, mailing lists, Slack, and any other communication channels] 83 | 84 | * User Mailing List: 85 | * Developer Mailing List: 86 | * Slack Channel: 87 | * Public Meeting Schedule and Links: 88 | * Social Media: 89 | * Other Channel(s), If Any: 90 | 91 | ## Resources 92 | 93 | [TODO: Add links to other helpful information (roadmap, docs, website, etc.)] 94 | 95 | ## License 96 | 97 | 98 | This project is licensed under [TODO: Add name of license and link to your LICENSE file] 99 | 100 | ## Conduct 101 | 102 | 103 | We follow the CNCF Code of Conduct [TODO: Insert link to your CODE_OF_CONDUCT.md file]. 104 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # CNCF Project Template Repository 2 | 3 | This is a [template repository][template-repo] for CNCF projects created by [CNCF SIG Contributor 4 | Strategy][contrib-strat]. You can use it to either start a new repository that 5 | has all the required files for a CNCF project or just grab the particular files 6 | that you need. 7 | 8 | ## Steps 9 | 10 | 1. Click **Use this template** and create a copy of this repository. 11 | 12 | ![Green button that says "Use this template"](https://user-images.githubusercontent.com/1368985/95903529-e9c32f00-0d5b-11eb-8723-4369f7c9e044.png) 13 | 1. Remove **.github/settings.yml**. This is not a template and contains 14 | configuration specific our repository. You should not keep this file. 15 | 1. Customize every [required template](#required-templates) and address each TODO item. 16 | 17 | ### Customize Templates 18 | 19 | Each file is a template with instructions to customize the contents for your project. 20 | Most files use comments with TODO to call out where you need to make changes. We recommend 21 | viewing the files in raw or text form so that you can see the comments. 22 | 23 | For example in markdown files, we use `` to provide additional 24 | guidance or indicate where action is required but you won't see those comments 25 | when you view the markdown file in GitHub unless you view the raw text. 26 | 27 | ## Required Templates 28 | 29 | * [LICENSE](LICENSE) 30 | * [CONTRIBUTING.md](CONTRIBUTING.md) 31 | * [README-template.md](README-template.md) 32 | 33 | [template-repo]: https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories/creating-a-repository-from-a-template 34 | [contrib-strat]: https://github.com/cncf/sig-contributor-strategy/blob/master/README.md 35 | 36 | Note: This is the README file for the templates repo. Please use [README-template.md](README-template.md) 37 | as a template for your project README. 38 | -------------------------------------------------------------------------------- /REVIEWING.md: -------------------------------------------------------------------------------- 1 | # Reviewing Guide 2 | 3 | Follow the instructions at [HowTo: Make a Reviewing Guide][howto] file to complete the following sections. 4 | 5 | This document covers who may review pull requests for this project, and provides guidance on how to perform code reviews that meet our community standards and code of conduct. All reviewers must read this document and agree to follow the project review guidelines. Reviewers who do not follow these guidelines may have their privileges revoked. 6 | 7 | [howto]: https://contribute.cncf.io/maintainers/github/templates/recommended/reviewing/ 8 | 9 | ## The Reviewer Role 10 | 11 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/recommended/reviewing/#the-reviewing-role) 12 | 13 | ⚠️ **Pick the statement that matches the reviewer role for your project** 14 | 15 | Only maintainers review pull requests. 16 | 17 | OR 18 | 19 | The reviewer role is distinct from the maintainer role. Reviewers can approve a pull request but they cannot merge it. A maintainer handles final approval and merging the pull request. 20 | 21 | ## Values 22 | 23 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/recommended/reviewing/#values) 24 | 25 | 26 | All reviewers must abide by the [Code of Conduct](CODE_OF_CONDUCT.md) and are also protected by it. A reviewer should not tolerate poor behavior and is encouraged to report any behavior that violates the Code of Conduct. All of our values listed above are distilled from our Code of Conduct. 27 | 28 | Below are concrete examples of how it applies to code review specifically: 29 | 30 | ### Inclusion 31 | 32 | Be welcoming and inclusive. You should proactively ensure that the author is successful. While any particular pull request may not ultimately be merged, overall we want people to have a great experience and be willing to contribute again. Answer the questions they didn't know to ask or offer concrete help when they appear stuck. 33 | 34 | ### Sustainability 35 | 36 | Avoid burnout by enforcing healthy boundaries. Here are some examples of how a reviewer is encouraged to act to take care of themselves: 37 | 38 | * Authors should meet baseline expectations when submitting a pull request, such as writing tests. 39 | * If your availability changes, you can step down from a pull request and have someone else assigned. 40 | * If interactions with an author are not following code of conduct, close the PR and raise it up with your Code of Conduct committee or point of contact. It's not your job to coax people into behaving. 41 | 42 | ### Trust 43 | 44 | Be trustworthy. During a review, your actions both build and help maintain the trust that the community has placed in this project. Below are examples of ways that we build trust: 45 | 46 | * **Transparency** - If a pull request won't be merged, clearly say why and close it. If a pull request won't be reviewed for a while, let the author know so they can set expectations and understand why it's blocked. 47 | * **Integrity** - Put the project's best interests ahead of personal relationships or company affiliations when deciding if a change should be merged. 48 | * **Stability** - Only merge when then change won't negatively impact project stability. It can be tempting to merge a pull request that doesn't meet our quality standards, for example when the review has been delayed, or because we are trying to deliver new features quickly, but regressions can significantly hurt trust in our project. 49 | 50 | ## Process 51 | 52 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/recommended/reviewing/#process) 53 | 54 | ⚠️ **Define your project's review process** 55 | 56 | 57 | ## Checklist 58 | 59 | [Instructions](https://contribute.cncf.io/maintainers/github/templates/recommended/reviewing/#checklist) 60 | 61 | Below are a set of common questions that apply to all pull requests: 62 | 63 | - [ ] Is this PR targeting the correct branch? 64 | - [ ] Does the commit message provide an adequate description of the change? 65 | - [ ] Does the affected code have corresponding tests? 66 | - [ ] Are the changes documented, not just with inline documentation, but also with conceptual documentation such as an overview of a new feature, or task-based documentation like a tutorial? Consider if this change should be announced on your project blog. 67 | - [ ] Does this introduce breaking changes that would require an announcement or bumping the major version? 68 | 69 | 70 | ## Reading List 71 | 72 | Reviewers are encouraged to read the following articles for help with common reviewer tasks: 73 | 74 | * [The Art of Closing: How to closing an unfinished or rejected pull request](https://blog.jessfraz.com/post/the-art-of-closing/) 75 | * [Kindness and Code Reviews: Improving the Way We Give Feedback](https://product.voxmedia.com/2018/8/21/17549400/kindness-and-code-reviews-improving-the-way-we-give-feedback) 76 | * [Code Review Guidelines for Humans: Examples of good and back feedback](https://phauer.com/2018/code-review-guidelines/#code-reviews-guidelines-for-the-reviewer) 77 | --------------------------------------------------------------------------------