diff --git a/contributing/CODE-OF-CONDUCT.md b/contributing/CODE-OF-CONDUCT.md deleted file mode 100644 index 3cdd794a7..000000000 --- a/contributing/CODE-OF-CONDUCT.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: "Contributor covenant code of conduct" -linkTitle: "Code of conduct" -weight: 10 -type: "docs" ---- - -## Our Pledge - -In the interest of fostering an open and welcoming environment, we as -contributors and maintainers pledge to making participation in our project and -our community a harassment-free experience for everyone, regardless of age, body -size, disability, ethnicity, gender identity and expression, level of -experience, education, socio-economic status, nationality, personal appearance, -race, religion, or sexual identity and orientation. - -## Our Standards - -Examples of behavior that contributes to creating a positive environment -include: - -- Using welcoming and inclusive language -- Being respectful of differing viewpoints and experiences -- Gracefully accepting constructive criticism -- Focusing on what is best for the community -- Showing empathy towards other community members - -Examples of unacceptable behavior by participants include: - -- The use of sexualized language or imagery and unwelcome sexual attention or - advances -- Trolling, insulting/derogatory comments, and personal or political attacks -- Public or private harassment -- Publishing others' private information, such as a physical or electronic - address, without explicit permission -- Other conduct which could reasonably be considered inappropriate in a - professional setting - -## Our Responsibilities - -Members of the Technical Oversight Committee are responsible for clarifying the -standards of acceptable behavior and are expected to take appropriate and fair -corrective action in response to any instances of unacceptable behavior. - -TOC members have the right and responsibility to remove, edit, or reject -comments, commits, code, wiki edits, issues, and other contributions that are -not aligned to this Code of Conduct, or to ban temporarily or permanently any -contributor for other behaviors that they deem inappropriate, threatening, -offensive, or harmful. - -## Scope - -This Code of Conduct applies both within project spaces and in public spaces -when an individual is representing the project or its community. Examples of -representing a project or community include using an official project e-mail -address, posting via an official social media account, or acting as an appointed -representative at an online or offline event. Representation of a project may be -further defined and clarified by project maintainers. - -## Enforcement - -Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported by contacting the Technical Oversight Committee at -knative-code-of-conduct@googlegroups.com. All complaints will be reviewed and -investigated and will result in a response that is deemed necessary and -appropriate to the circumstances. The project team is obligated to maintain -confidentiality with regard to the reporter of an incident. Further details of -specific enforcement policies may be posted separately. - -TOC members who do not follow or enforce the Code of Conduct in good faith may -face temporary or permanent repercussions as determined by other members of the -project's leadership. - -## Attribution - -This Code of Conduct is adapted from the [Contributor Covenant][homepage], -version 1.4, available at -https://www.contributor-covenant.org/version/1/4/code-of-conduct.html - -[homepage]: https://www.contributor-covenant.org - ---- - -Except as otherwise noted, the content of this page is licensed under the -[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), -and code samples are licensed under the -[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). diff --git a/contributing/CONTRIBUTING.md b/contributing/CONTRIBUTING.md deleted file mode 100644 index 3ae917a47..000000000 --- a/contributing/CONTRIBUTING.md +++ /dev/null @@ -1,238 +0,0 @@ ---- -title: "Knative contributor guidelines" -linkTitle: "Contributing to Knative" -weight: 15 -type: "docs" ---- - -So, you want to hack on Knative? Yay! - -The following sections outline the process all changes to the Knative -repositories go through. All changes, regardless of whether they are from -newcomers to the community or from the core team follow the same process and are -given the same level of review. - -- [Working groups](#working-groups) -- [Code of conduct](#code-of-conduct) -- [Team values](#team-values) -- [Contributor license agreements](#contributor-license-agreements) -- [Design documents](#design-documents) -- [Contributing documentation](#contributing-documentation) -- [Contributing a feature](#contributing-a-feature) -- [Setting up to contribute to Knative](#setting-up-to-contribute-to-knative) -- [Pull requests](#pull-requests) -- [Issues](#issues) - -## Working groups - -The Knative contributors community is organized into a set of -[working groups](./WORKING-GROUPS.md). Any contribution to Knative should be -started by first engaging with the appropriate working group. - -## Code of conduct - -All members of the Knative community must abide by the -[Code of Conduct](./CODE-OF-CONDUCT.md). Only by respecting each other can we -develop a productive, collaborative community. - -## Team values - -We promote and encourage a set of [shared values](./VALUES.md) to improve our -productivity and inter-personal interactions. - -## Contributor license agreements - -We'd love to accept your patches! But before we can take them, you will have to -fill out the [Google CLA](https://cla.developers.google.com). (Make sure to fill -out the CLA with the same email address you used to register for Github.) - -Once you are CLA'ed, we'll be able to accept your pull requests. This is -necessary because you own the copyright to your changes, even after your -contribution becomes part of this project. So this agreement simply gives us -permission to use and redistribute your contributions as part of the project. - -## Design documents - -Any substantial design deserves a design document. Design documents are written -with Google Docs and should be shared with the community by adding the doc to -our -[Team Drive](https://drive.google.com/corp/drive/folders/0APnJ_hRs30R2Uk9PVA) -and sending an email to the appropriate working group's mailing list to let -people know the doc is there. To get write access to the drive, you'll need to -be a [member](./ROLES.md#member) of the Knative organization. - -We do not yet have a common design document template(TODO). - -The team drive is shared with the -[knative-users@](https://groups.google.com/forum/#!forum/knative-users) and -[knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) Google -groups for reading and editing, respectively. Access to -[knative-users@](https://groups.google.com/forum/#!forum/knative-users) is -unlimited, while -[knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) requires -human review. If you're not part of one of those groups, the first time you try -to access the team drive or a specific doc, you'll be asked to request -permission. Please join one of the above groups (you can join knative-users and -later join knative-dev if you want immediate access). - -## Contributing documentation - -For more information about contributing to the Knative documentation, see -[DOCS-CONTRIBUTING.md](./DOCS-CONTRIBUTING.md). A lot of the information on this -page still applies, but you'll find the specifics about the docs process there. - -## Contributing a feature - -In order to contribute a feature to Knative you'll need to go through the -following steps: - -- Discuss your idea with the appropriate [working groups](./WORKING-GROUPS.md) - on the working group's mailing list. - -- Once there is general agreement that the feature is useful, - [create a GitHub issue](https://github.com/knative/docs/issues/new) to track - the discussion. The issue should include information about the requirements - and use cases that it is trying to address. Include a discussion of the - proposed design and technical details of the implementation in the issue. - -- If the feature is substantial enough: - - - Working group leads will ask for a design document as outlined in - [design documents](#design-documents). Create the design document and add a - link to it in the GitHub issue. Don't forget to send a note to the working - group to let everyone know your document is ready for review. - - - Depending on the breadth of the design and how contentious it is, the - working group leads may decide the feature needs to be discussed in one or - more working group meetings before being approved. - - - Once the major technical issues are resolved and agreed upon, post a note - with the design decision and the general execution plan to the working - group's mailing list and on the feature's issue. - -- Submit PRs to [knative/serving](https://github.com/knative/serving/pulls) with - your code changes. - -- Submit PRs to knative/serving with user documentation for your feature, - including usage examples when possible. Add documentation to the `serving` - folder of [knative/docs](../serving). - -_Note that we prefer bite-sized PRs instead of giant monster PRs. It's therefore -preferable if you can introduce large features in small, individually-reviewable -PRs that build on top of one another._ - -If you would like to skip the process of submitting an issue and instead would -prefer to just submit a pull request with your desired code changes then that's -fine. But keep in mind that there is no guarantee of it being accepted and so it -is usually best to get agreement on the idea/design before time is spent coding -it. However, sometimes seeing the exact code change can help focus discussions, -so the choice is up to you. - -## Setting up to contribute to Knative - -Check out this -[README](https://github.com/knative/serving/blob/master/README.md) to learn -about the Knative source base and setting up your -[development environment](https://github.com/knative/serving/blob/master/DEVELOPMENT.md). - -## Pull requests - -We have a [gubernator](https://gubernator.knative.dev) instance that provides a -[pull request dashboard](https://gubernator.knative.dev/pr) so you can see which -PRs you need to take action on. - -If you're working on an existing issue, simply respond to the issue and express -interest in working on it. This helps other people know that the issue is -active, and hopefully prevents duplicated efforts. - -To submit a proposed change: - -- Fork the affected repository. -- Create a new branch for your changes. -- Develop the code/fix. -- Add new test cases. In the case of a bug fix, the tests should fail without - your code changes. For new features try to cover as many variants as - reasonably possible. -- Modify the documentation as necessary. -- Verify all CI status checks pass, and work to make them pass if failing. - -The general rule is that all PRs should be 100% complete - meaning they should -include all test cases and documentation changes related to the change. A -significant exception is work-in-progress PRs. These should be indicated by a -`[WIP]` prefix in the PR title. WIP PRs should not be merged as long as they are -marked WIP. - -When ready, if you have not already done so, sign a -[contributor license agreement](#contributor-license-agreements) and submit the -PR. - -This project uses -[Prow](https://github.com/kubernetes/test-infra/tree/master/prow) to assign -reviewers to the PR, set labels, run tests automatically, and so forth. - -See [Reviewing and Merging Pull Requests](./REVIEWING.md) for the PR review and -merge process used for Knative and for more information about -[Prow](./REVIEWING.md#prow). - -## Issues - -GitHub issues can be used to report bugs or submit feature requests. - -When reporting a bug please include the following key pieces of information: - -- The version of the project you were using (version number, git commit, etc) -- Operating system you are using -- The exact, minimal, steps needed to reproduce the issue. Submitting a 5 line - script will get a much faster response from the team than one that's hundreds - of lines long. - -## Third-party code - -- All third-party code must be placed in `vendor/` or `third_party/` folders. -- `vendor/` folder is managed by [dep](https://github.com/golang/dep) and stores - the source code of third-party Go dependencies. `vendor/` folder should not be - modified manually. -- Other third-party code belongs in `third_party/` folder. -- Third-party code must include licenses. - -A non-exclusive list of code that must be places in `vendor/` and -`third_party/`: - -- Open source, free software, or commercially-licensed code. -- Tools or libraries or protocols that are open source, free software, or - commercially licensed. -- Derivative works of third-party code. -- Excerpts from third-party code. - -### Adding a new third-party dependency to `third_party/` folder - -- Create a sub-folder under `third_party/` for each component. -- In each sub-folder, make sure there is a file called LICENSE which contains - the appropriate license text for the dependency. If one doesn't exist then - create it. More details on this below. -- Check in a pristine copy of the code with LICENSE and METADATA files. You do - not have to include unused files, and you can move or rename files if - necessary, but do not modify the contents of any files yet. -- Once the pristine copy is merged into master, you may modify the code. - -### LICENSE - -The license for the code must be in a file named LICENSE. If it was distributed -like that, you're good. If not, you need to make LICENSE be a file containing -the full text of the license. If there's another file in the distribution with -the license in it, rename it to LICENSE (e.g., rename a LICENSE.txt or COPYING -file to LICENSE). If the license is only available in the comments or at a URL, -extract and copy the text of the license into LICENSE. - -You may optionally document the generation of the LICENSE file in the -local_modifications field of the METADATA file. - -If there are multiple licenses for the code, put the text of all the licenses -into LICENSE along with separators and comments as to the applications. - ---- - -Except as otherwise noted, the content of this page is licensed under the -[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), -and code samples are licensed under the -[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). diff --git a/contributing/DOCS-CONTRIBUTING.md b/contributing/DOCS-CONTRIBUTING.md deleted file mode 100644 index d0ac2e855..000000000 --- a/contributing/DOCS-CONTRIBUTING.md +++ /dev/null @@ -1,411 +0,0 @@ ---- -title: "Contributing to the Knative documentation" -linkTitle: "Contributing to docs" -weight: 20 -type: "docs" ---- - -- [Before you begin](#before-you-begin) -- [Contributing to the documentation](#contributing-to-the-documentation) -- [Docs contributor roles](#docs-contributor-roles) - -**First off, thanks for taking the time to contribute!** - -The following are guidelines for contributing to the Knative documentation. -These are just guidelines, not rules. Use your best judgment, and feel free to -propose changes to this document in a pull request. - -## Before you begin - -### Code of conduct - -Knative follows the [Knative Code of Conduct](./CODE-OF-CONDUCT.md). By -participating, you are expected to uphold this code. Please report unacceptable -behavior to knative-code-of-conduct@googlegroups.com. - -### Contributor license agreements - -We'd love to accept your contributions! But before we can take them, you need to -fill out the [Google CLA](https://cla.developers.google.com). Important: You -must fill out the CLA with the same email address that you used to create your -GitHub account. - -Once you are CLA'ed, we'll be able to accept your pull requests. This is -necessary because you own the copyright to your changes, even after your -contribution becomes part of this project. So this agreement simply gives us -permission to use and redistribute your contributions as part of the project. - -### Style guide - -Knative documentation follows the -[Google Developer Documentation Style Guide](https://developers.google.com/style/); -use it as a reference for writing style questions. - -## Contributing to the documentation - -### Reporting documentation issues - -Knative uses Github issues to track documentation issues and requests. If you -see a problem with the documentation, submit an issue using the following steps: - -1. Check the [Knative docs issues list](https://github.com/knative/docs/issues) - before creating an issue to avoid making a duplicate. -2. Use the [correct template](https://github.com/knative/docs/issues/new) for - your new issue. There are two templates available: - - **Bug report**: If you're reporting an error in the existing documentation, - use this template. This could be anything from broken samples to typos. - When you create a bug report, include as many details as possible and - include suggested fixes to the issue. If you know which Knative component - your bug is related to, you can assign the appropriate - [Working Group Lead](./WORKING-GROUPS.md). - - **Feature request**: For upcoming changes to the documentation or requests - for more information on a particular subject. - -Note that code issues should be filed against the -[individual Knative repositories](http://github.com/knative), while -documentation issues should go in the -[`knative/docs`repo](https://github.com/knative/docs/issues). If the issue is -specific to the [https://knative.dev](https://knative.dev) website, open the -issue in the [`knative/website`repo](https://github.com/knative/website/issues). - -### Working group - -The [Knative Documentation Working Group](./WORKING-GROUPS.md#documentation) -meets weekly on Tuesdays and alternates between a 9am PT and a 4:30pm PT time to -accommodate contributors in both the EMEA and APAC timezones. -[Click here](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) -to see the exact dates on the Knative working group calendar. If you're -interested in becoming more involved in Knative's documentation, start attending -the working group meetings. You'll meet the writers currently steering our -documentation efforts, who are happy to help you get started. - -### Getting started - -There are a couple different ways to jump in to the Knative doc set: - -- Look for a - [Good First Issue](https://github.com/knative/docs/labels/kind%2Fgood-first-issue) - in the backlog. - -- Try out Knative and send us feedback. For example, run through one of the - [install guides](../install/README.md) and then try - [Getting Started with Knative Serving](../install/getting-started-knative-app.md). - - You should keep a - [friction log](https://devrel.net/developer-experience/an-introduction-to-friction-logging) - of your experience and then use that to open your first set of PRs. Examples: - - - What was hard for you? - - Did you stumble on something because it wasn't clear? - - Was a dependency not mentioned? - -**A few pointers and other considerations** - -- Think about how you can improve the documentation as a whole.
For - example, how can you fix the issue you found so that others don't run into the - same challenges? - -- Are there multiple places that could be fixed? - - - Are there other pages that you should apply your update? - - - Would it help if there was a link to more or related information on a the - page? On a related page? - -- Was the title or description misleading? Did you expect to find something - else? - -- If you find something and don't have the bandwidth to open a PR, make us aware - of the pain point and open an - [Issue](https://github.com/knative/docs/issues/new). - -### Submitting documentation PRs - what to expect - -Here's what generally happens when you open a PR against the `knative/docs` -repo: - -1. One of the assigned repo maintainers will triage the PR by assigning relative - priority, adding appropriate labels, and performing an initial documentation - review. -1. If the PR involves significant technical changes, for example new features, - or new and changed sample code, the PR is assigned to a Subject Matter Expert - (SME), typically an engineer working on Knative, for technical review and - approval. -1. When both the technical writers and SMEs are satisfied with the quality of - the writing and the technical accuracy of the content, the PR can be merged. - A PR requires two labels before it can merge: `lgtm` and `approved`. - - - The SME is responsible for reviewing the technical accuracy and adding the - `lgtm` label. - - - The - [Knative technical writers](https://github.com/knative/docs/blob/master/OWNERS_ALIASES) - are who provide the `approved` label when the content meets quality, - clarity, and organization standards (see [Style Guide](#style-guide)). - -We appreciate contributions to the docs, so if you open a PR we will help you -get it merged. You can also post in the `#docs` -[Slack channel](https://knative.slack.com/) to get input on your ideas before -creating a PR. - -### Putting your docs in the right place - -There are currently two general types of Knative docs, either contributor -related content, or external-facing user content. - -#### Choosing the correct repo - -Depending on the type of content that you want to contribute, it might belong in -one of the Knative code repositories (`knative/serving`, `knative/eventing`, -etc.) or in `knative/docs`, the Knative documentation repo. - -- **Contributor-focused content** - - - _Documentation_: Includes content that is component specific and relevant - only to contributors of a given component. Contributor focused documentation - is located in the corresponding `docs` folder of that component's - repository. For example, if you contribute code to the Knative Serving - component, you might need to add contributor focused information into the - `docs` folder of the - [knative/serving repo](https://github.com/knative/serving/tree/master/docs/). - - - _Code samples_: Includes contributor related code or samples. Code or - samples that are contributor focused also belong in their corresponding - component's repo. For example, Eventing specific test code is located in the - [knative/eventing tests](https://github.com/knative/eventing/tree/master/test) - folder. - -- **User-focused content** - - - _Documentation_: Includes all content for Knative users. The external-facing - user documentation belongs in the - [`knative/docs` repo](https://github.com/knative/docs). All content in - `knative/docs` is published to [https://knative.dev](https://knative.dev). - - - _Code samples_: Includes user-facing code samples and their accompanying - step-by-step instructions. User code samples are currently separated into - two different locations within the `knative/docs` repo. See the following - section for details about determining where you can add your code sample. - -##### Determining where to add user focused code samples - -There are currently two categories of user-focused code samples, _Knative owned -and maintained_ and _Community owned and maintained_. - -- **Knative owned and maintained**: Includes code samples that are actively - maintained and e2e tested. To ensure content currency and balance available - resource, only the code samples that meet the following requirements are - located in the `docs/[*component*]/samples` folders of the `knative/docs` - repo: - - - _Actively maintained_ - The code sample has an active Knative team member - who has committed to regular maintenance of that content and ensures that - the code is updated and working for every product release. - - _Receives regular traffic_ - To avoid hosting and maintaining unused or - stale content, if code samples are not being viewed and fail to receive - attention or use, those samples will be moved into the - "[community maintained](https://github.com/knative/docs/tree/master/community/samples)" - set of samples. - - _Passes e2e testing_ - All code samples within `docs/[*component*]/samples` - folders must align with (and pass) the - [`e2e` tests](https://github.com/knative/docs/tree/master/test). - - Depending on the Knative component covered by the code sample that you want to - contribute, your PR should add that sample in one of the following folders: - - - Build samples: - [`/docs/build/samples`](https://github.com/knative/docs/tree/master/docs/build/samples) - - Eventing samples: - [`/docs/eventing/samples`](https://github.com/knative/docs/tree/master/docs/eventing/samples) - - Serving samples: - [`/docs/serving/samples`](https://github.com/knative/docs/tree/master/docs/serving/samples) - -- **Community owned and maintained samples**: Code samples that have been - contributed by Knative community members. These samples might not receive - regular maintenance. It is possible that a sample is no longer current and is - not actively maintained by its original author. While we encourage a - contributor to maintain their content, we acknowledge that it's not always - possible for certain reasons, for example other commitments and time - constraints. - -While a sample might be out of date, it could still provide assistance and help -you get up-and-running with certain use-cases. If you find that something is not -right or contains outdated info, open an -[Issue](https://github.com/knative/docs/issues/new). The sample might be fixed -if bandwidth or available resource exists, or the sample might be taken down and -archived into the last release branch where it worked. - -#### Choosing the correct branch - -It is likely that your docs contribution is either for new or changed features -in the product, or for a fix or update existing content. - -- **New or changed features**: If you are adding or updating documentation for a - new or changed feature, you likely want to open your PR against the `master` - branch. All pre-release content for active Knative development belongs in - [`master`](https://github.com/knative/docs/tree/master/). - -- **Fixes and updates**: If you find an issue in a past release, for example a - typo or out-of-date content, you likely need to open multiple and subsequent - PRs. If not a followup PR, at least add the "`cherrypick` labels" to your - original PR to indicate in which of the past release that your change affects. - - For example, if you find a typo in a page of the `v0.5` release, then that - page in the `master` branch likely also has that typo. - - To fix the typo: - - 1. Open a PR against the - [`master`](https://github.com/knative/docs/tree/master/) branch. - 1. Add one or more `cherrypick-#.#` labels to that PR to indicate which of - the past release branches should also be fixed. Generally, we only - maintain the most recent numbered release. - 1. If you want to complete the fix yourself (best practice), you then open a - subsequent PR by running `git cherry-pick [COMMIT#]` against the - [release-0.5](https://github.com/knative/docs/tree/release-0.5). Where - [COMMIT#] is the commit of your merged PR. - - Note: Depending on workload and available bandwidth, one of the Knative - team members might be able to help handle the `git cherry-pick` in order - to push the fix into the affected release branch(es). - -For a list of the available branches in the `knative/docs` repo, see -[Documentation Releases](https://github.com/knative/docs/blob/master/doc-releases.md). - -## Assigning owners and reviewers - -For both documentation and code samples, you should assign your PR to a single -owner ("_Assignee_"). It's best to set the "Assignee" and include other -stakeholders as "Reviewers" rather than leaving it unassigned or allowing -[Prow](https://prow.k8s.io/command-help) to auto assign reviewers. - -Use the `/assign` command to set the owner. For example: `/assign @owner_id` - -For code samples, initially set the owner of your PR to the SME who should -review for technical accuracy. If you don't know who the appropriate owner is, -nor who your reviewers should be for your PR, you can assign the -[current working group lead](./WORKING-GROUPS.md) of the related component. - -If you want to notify and include other stakeholders in your PR review, use the -`/cc` command. For example: `/cc @stakeholder_id1 @stakeholder_id2` - -## Docs contributor roles - -Because contributing to the documentation requires a different skill set than -contributing to the Knative code base, we've defined the roles of documentation -contributors separately from the roles of code contributors. - -If you're looking for code contributor roles, see [ROLES](./ROLES.md). - -### Member - -Established contributor to the Knative docs. - -Members are continuously active contributors in the community. They can have -issues and PRs assigned to them, might participate in working group meetings, -and pre-submit tests are automatically run for their PRs. Members are expected -to remain active contributors to the Knative documentation. - -All members are encouraged to help with PR reviews, although each PR must be -reviewed by an official [Approver](#approver). In their review, members should -be looking for technical correctness of the documentation, adherence to the -[style guide](https://developers.google.com/style/), good spelling and grammar -(writing quality), intuitive organization, and strong documentation usability. -Members should be proficient in at least one of these review areas. - -### Requirements - -- Has made multiple contributions to the project or community. Contributions - might include, but are not limited to: - - - Authoring and reviewing PRs on GitHub in the Docs or Website repos. - - - Filing and commenting on issues on GitHub. - - - Contributing to working group or community discussions. - -- Subscribed to - [knative-dev@googlegroups.com](https://groups.google.com/forum/#!forum/knative-dev). - -- Actively contributing to 1 or more areas. - -- Sponsored by 1 approver. - - - Done by adding GitHub user to Knative organization. - -### Responsibilities and privileges - -- Responsive to issues and PRs assigned to them. - -- Active owner of documents they have contributed (unless ownership is - explicitly transferred). - - - Addresses bugs or issues in their documentation in a timely manner. - -### Becoming a member - -First, reach out to an approver and ask them to sponsor you so that you can -become a member. The easiest way to do this is using Slack. - -If they are supportive of your membership, your sponsor will reach out to the -Knative Steering committee to ask that you be added as a member of the Knative -org. - -Once your sponsor notifies you that you've been added to the Knative org, open a -PR to add yourself as a docs-reviewer in the [OWNERS_ALIASES](../OWNERS_ALIASES) -file. - -## Approver - -Docs approvers are able to both review and approve documentation contributions. -While documentation review is focused on writing quality and correctness, -approval is focused on holistic acceptance of a contribution including: -long-term maintainability, adhering to style guide conventions, overall -information architecture, and usability from an engineering standpoint. Docs -approvers will enlist help from engineers for reviewing code-heavy contributions -to the Docs repo. - -### Requirements - -- Reviewer of the Docs repo for at least 3 months. - - - Proficient in reviewing all aspects of writing quality, including grammar - and spelling, adherence to style guide conventions, organization, and - usability. Can coach newer writers to improve their contributions in these - areas. - -- Primary reviewer for at least 10 substantial PRs to the docs, showing - substantial ability to coach for writing development. - -- Reviewed or merged at least 30 PRs to the docs. - -- Nominated by an area lead (with no objections from other leads). - - - Done through PR to update an OWNERS file. - -### Responsibilities and privileges - -- Responsible for documentation quality control via PR reviews. - - - Focus on long-term maintainability, adhering to style guide conventions, - overall information architecture, and usability from an engineering - standpoint. - -- Expected to be responsive to review requests as per - [community expectations](REVIEWING.md). - -- Mentor members and contributors to improve their writing. - -- Might approve documentation contributions for acceptance, but will ask for - engineering review for code-heavy contributions. - -### Becoming an approver - -If you want to become an approver, make your goal clear to the current Knative -Docs approvers, either by contacting them in Slack or announcing your intention -to become an approver at a meeting of the Documentation Working Group. - -Once you feel you meet the criteria, you can ask one of the current approvers to -nominate you to become an approver. If all existing approvers agree that you -meet the criteria open a PR to add yourself as a docs-approver in the -[OWNERS_ALIASES](../OWNERS_ALIASES) file. diff --git a/contributing/README.md b/contributing/README.md deleted file mode 100644 index d83f8c78c..000000000 --- a/contributing/README.md +++ /dev/null @@ -1,112 +0,0 @@ -_Important_. Before proceeding, please review the Knative community -[Code of Conduct](./CODE-OF-CONDUCT.md). - -If you any have questions or concerns, please contact the authors at -knative-code-of-conduct@googlegroups.com. - -## Welcome! - -Welcome to the Knative community! - -This is the starting point for becoming a contributor - improving code, -improving docs, giving talks, etc. - -- [Introduction](#introduction) -- [Knative authors](#knative-authors) - - [Authoring samples](#authoring-samples) -- [Meetings and work groups](#meetings-and-work-groups) -- [How can I help?](#how-can-i-help) -- [Questions and issues](#questions-and-issues) - -Other Documents - -- [Code of Conduct](./CODE-OF-CONDUCT.md) - all contributors must abide by the - code of conduct -- [Values](./VALUES.md) - shared goals and values for the community -- [Contributing to Knative](./CONTRIBUTING.md) - guidelines and advice on - becoming a contributor -- [Working Groups](./WORKING-GROUPS.md) - describes our various working groups -- [Working Group Processes](./WORKING-GROUP-PROCESSES.md) - describes how - working groups operate -- [Steering Committee](./STEERING-COMMITTEE.md) - describes our steering - committee -- [Technical Oversight Committee](./TECH-OVERSIGHT-COMMITTEE.md) - describes our - technical oversight committee -- [Community Roles](./ROLES.md) - describes the roles individuals can assume - within the Knative community -- [Reviewing and Merging Pull Requests](./REVIEWING.md) - how we manage pull - requests -- [Repository Guidelines](./REPOSITORY-GUIDELINES.md) - how we create and remove - core repositories - -## Introduction - -Knative is a Kubernetes-based platform to build, deploy, and manage modern -serverless workloads. See [Knative docs](../docs/README.md) for in-depth -information about using Knative. - -## Knative authors - -Knative is an open source project with an active development community. The -project was started by Google but has contributions from a growing number of -industry-leading companies. For a current list of the authors, see -[Authors](https://github.com/knative/serving/blob/master/AUTHORS). - -### Authoring samples - -Beyond the official documentation there are endless possibilities for combining -tools, platforms, languages, and products. By submitting a tutorial you can -share your experience and help others who are solving similar problems. - -Community tutorials are stored in Markdown files under the `community` folder -[Community Samples](../community/samples/README.md). These documents are -contributed, reviewed, and maintained by the community. - -Submit a Pull Request to the community sample directory under the Knative -component folder that aligns with your document. For example, Knative Serving -samples are under the `serving` folder. A reviewer will be assigned to review -your submission. They'll work with you to ensure that your submission is clear, -correct, and meets the [style guide](./DOCS-CONTRIBUTING.md), but it helps if -you follow it as you write your tutorial. - -## Meetings and work groups - -Knative has public and recorded bi-weekly community meetings. - -Each project has one or more [working groups](./WORKING-GROUPS.md) driving the -project, and Knative as a single -[technical oversight community](./TECH-OVERSIGHT-COMMITTEE.md) monitoring the -overall project. - -## How can I help - -If you're looking for something to do to get your feet wet working on Knative, -look for GitHub issues marked with the Help Wanted label: - -- [Build issues](https://github.com/knative/build/labels/kind%2Fgood-first-issue) -- [Eventing issues](https://github.com/knative/eventing/labels/kind%2Fgood-first-issue) -- [Serving issues](https://github.com/knative/serving/labels/kind%2Fgood-first-issue) -- [Documentation repo](https://github.com/knative/docs/labels/kind%2Fgood-first-issue) - -Even if there's not an issue opened for it, we can always use more testing -throughout the platform. Similarly, we can always use more docs, richer docs, -insightful docs. Or maybe a cool blog post? And if you're a web developer, we -could use your help in spiffing up our public-facing web site. - -## Questions and issues - -If you're a developer, operator, or contributor trying to use Knative, the -following resources are available for you: - -- [Knative Users](https://groups.google.com/forum/#!forum/knative-users) -- [Knative Developers](https://groups.google.com/forum/#!forum/knative-dev) - -For contributors to Knative, we also have -[Knative Slack](./SLACK-GUIDELINES.md). - ---- - -Except as otherwise noted, the content of this page is licensed under the -[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), -and code samples are licensed under the -[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). diff --git a/contributing/REPOSITORY-GUIDELINES.md b/contributing/REPOSITORY-GUIDELINES.md deleted file mode 100644 index 42c7db3b5..000000000 --- a/contributing/REPOSITORY-GUIDELINES.md +++ /dev/null @@ -1,77 +0,0 @@ -# Knative Repository Guidelines - -This document outlines a structure for creating and associating code -repositories with the Knative project. It also describes how and when -repositories are removed. - -## Core Repositories - -Core repositories are considered core components of Knative. They are utilities, -tools, applications, or libraries that form or support the foundation of the -project. - -Core repositories are all those located under the -[github.com/knative organization](https://github.com/knative). - -### Core Repository Requirements - -- Repository must live under github.com/knative/project-name -- Must adopt the Knative Code of Conduct -- All code projects must use the Apache License version 2.0. -- Documentation repositories must use Creative Commons License version 4.0. -- All OWNERS must be members of the Knative community. -- Repository creation must be approved by the Technical Oversight Committee. - -## Removing Repositories - -As important as it is to add new repositories, it is equally important to prune -repositories when necessary. See [Grounds for removal](#grounds-for-removal). - -It is important to the success of Knative that all Knative repositories stay -active, healthy, and aligned with the scope and mission of project. - -### Grounds for removal - -Core repositories may be removed from the project if they are deemed _inactive_. -Inactive repositories are those that meet any of the following criteria: - -- There are no longer any active maintainers for the project, and no - replacements can be found. -- All PRs and issues have gone un-addressed for longer than six months. -- There have been no new commits or other changes in more than a year. -- The contents have been folded into another actively maintained project. - -### Procedure for removal - -When a repository has been deemed eligible for removal, we take the following -steps: - -- A proposal to remove the repository is brought to the attention of the - Technical Oversight Committee through a GitHub issue posted in the - [docs](https://github.com/knative/docs) repo. - - Feedback is encouraged during a Technical Oversight Committee meeting before - any action is taken. -- Once the TOC has approved of the removal, if the repo is not moving to another - actively maintained project: - - The repo description is edited to start with the phrase "[EOL]" - - All open issues and PRs are closed - - All external collaborates are removed - - All webhooks, apps, integrations, or services are removed - - GitHub pages are disabled - - The repo is marked as archived using GitHub's archive feature - - The removal is announced on the knative-dev mailing list - -This procedure maintains the complete record of issues, PRs, and other -contributions. It leaves the repository read-only and makes it clear that the -repository is retired and no longer maintained. - ---- - -Contents of this page are adopted from the -[Kubernetes repository guidelines](https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md), -which is licensed under Apache License 2.0. - -Except as otherwise noted, the content of this page is licensed under the -[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), -and code samples are licensed under the -[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). diff --git a/contributing/REVIEWING.md b/contributing/REVIEWING.md deleted file mode 100644 index 4f04e92a4..000000000 --- a/contributing/REVIEWING.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: "Reviewing and merging Knative pull requests" -linkTitle: "Pull request guidelines" -weight: 60 -type: "docs" ---- - -As a community, we believe in the value of code reviews for all contributions. -Code reviews increase both the quality and readability of our code base, which -in turn produces high quality software. - -This document provides guidelines for how the project's -[Members](./ROLES.md#member) review issues and merge pull requests (PRs). - -- [Pull requests welcome](#pull-requests-welcome) -- [Code of Conduct](#code-of-conduct) -- [Code reviewers](#code-reviewers) -- [Reviewing changes](#reviewing-changes) - - [Holds](#holds) -- [Approvers](#approvers) -- [Merging PRs](#merging-prs) - -## Pull requests welcome - -First and foremost: as a potential contributor, your changes and ideas are -welcome at any hour of the day or night, weekdays, weekends, and holidays. -Please do not ever hesitate to ask a question or submit a PR. - -## Code of Conduct - -Reviewers are often the first points of contact between new members of the -community and are important in shaping the community. We encourage reviewers to -read the [code of conduct](./CODE-OF-CONDUCT.md) and to go above and beyond the -code of conduct to promote a collaborative and respectful community. - -## Code reviewers - -The code review process can introduce latency for contributors and additional -work for reviewers, frustrating both parties. Consequently, as a community we -expect all active participants to also be active reviewers. Participate in the -code review process in areas where you have expertise. - -## Reviewing changes - -Once a PR has been submitted, reviewers should do an initial review to do a -quick "triage" (e.g. close duplicates, identify user errors, etc.), and -potentially identify which maintainers should be the focal points for the -review. - -If a PR is closed without accepting the changes, reviewers are expected to -provide sufficient feedback to the originator to explain why it is being closed. - -During a review, PR authors are expected to respond to comments and questions -made within the PR - updating the proposed change as appropriate. - -After a review of the proposed changes, reviewers can either approve or reject -the PR. To approve, they add an "approved" review to the PR. To reject, they add -a "request changes" review along with a full justification for why they are not -in favor of the change. If a PR gets a "request changes" vote, the group -discusses the issue to resolve their differences. - -Reviewers are expected to respond in a timely fashion to PRs that are assigned -to them. Reviewers are expected to respond to _active_ PRs with reasonable -latency. If reviewers fail to respond, those PRs may be assigned to other -reviewers. _Active_ PRs are those that have a proper CLA (`cla:yes`) label, are -not works in progress (WIP), are passing tests, and do not need rebase to be -merged. PRs that do not have a proper CLA, are WIP, do not pass tests, or -require a rebase are not considered active PRs. - -### Holds - -Any [Approver](./ROLES.md#approver) who wants to review a PR but does not have -time immediately can put a hold on a PR. If you need more time, say so on the PR -discussion and offer an ETA measured in single-digit days at most. Any PR that -has a hold will not be merged until the person who requested the hold acks the -review, withdraws their hold, or is overruled by a majority of approvers. - -## Approvers - -Merging of PRs is done by [Approvers](./ROLES.md#approver). - -As is the case with many open source projects, becoming an Approver is based on -contributions to the project. See our [community roles](./ROLES.md) document for -information on how this is done. - -## Merging PRs - -A PR can be merged only after the following criteria are met: - -1. It has no "request changes" review from a reviewer. -1. It has at least one "approved" review by at least one of the approvers of - that repository. -1. It has all appropriate corresponding documentation and tests. - -## Prow - -This project uses -[Prow](https://github.com/kubernetes/test-infra/tree/master/prow) to -automatically run tests for every PR. PRs with failing tests might not be -merged. If necessary, you can rerun the tests by simply adding the comment -`/retest` to your PR. - -Prow has several other features that make PR management easier, like running the -go linter or assigning labels. For a full list of commands understood by Prow, -see the [command help page](https://prow.knative.dev/command-help). - ---- - -Except as otherwise noted, the content of this page is licensed under the -[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), -and code samples are licensed under the -[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). diff --git a/contributing/ROLES.md b/contributing/ROLES.md deleted file mode 100644 index cc05e649a..000000000 --- a/contributing/ROLES.md +++ /dev/null @@ -1,320 +0,0 @@ ---- -title: "Knative community roles" -linkTitle: "Community roles" -weight: 55 -type: "docs" ---- - -This document describes the set of roles individuals might have within the -Knative community, the requirements of each role, and the privileges that each -role grants. - -- [Role Summary](#role-summary) -- [Collaborator](#collaborator) -- [Member](#member) -- [Approver](#approver) -- [Lead](#lead) -- [Administrator](#administrator) - -## Role Summary - -The following table lists the roles we use within the Knative community. The -table describes: - -- General responsibilities expected by individuals in each role -- Requirements necessary to join or stay in a given role -- How the role manifests in terms of permissions and privileges. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RoleResponsibilitiesRequirementsPrivilegesScope
CollaboratorCasual contributor to the projectJoin [knative-users@](https://groups.google.com/forum/#!forum/knative-users) to get access to the team drive. -

Can submit PRs

-

Commenting permission on the Knative Team drive

- 		GitHub Organization
MemberRegular active contributor in the community -

Sponsored by two members

-

Has made multiple contributions to the project

- 		-

Member of the GitHub Knative org

-

Member of the Knative Slack workspace

-

Edit permission on the Knative Team drive

- 		GitHub Organization
Approver -

Approve contributions from other members

- 		Highly experienced and active reviewer and contributor to an areaEntry in one or more OWNERS files in GitHub, and write permissions - on one or more repos allowing PRs to be merged. - GitHub Directory
Lead -

Set priorities for a functional area and approve proposals

-

Triage incoming issues, set milestones, repo labels

-

Run their working group

- 		Sponsored by the technical oversight committee as documented - here. - Write permissions on one or more repos allowing issues to be manipulated.Working Group
AdministratorManage & control permissionsSponsored by the technical oversight committee -

Admin privileges on the GitHub Knative org and all its repos

-

Admin privileges on the Knative Slack workspace

-

Admin privileges on the Knative Team Drive

-

Admin privileges on the Google Search Console for knative.dev

-

Admin privilege to the Knative email lists.

- 		-

GitHub Organization

-

Team Drive

-

Slack

-
- -## Collaborator - -Individuals can be added as an outside collaborator (with READ access) to a repo -in the Knative GitHub organization without becoming a member. This role allows -them to be assigned issues and PRs until they become a member, but will not -allow tests to be run against their PRs automatically nor allow them to interact -with the PR bot. - -### Requirements - -- Working on some contribution to the project that would benefit from the - ability to have PRs or Issues to be assigned to the contributor. - -- Join [knative-users@](https://groups.google.com/forum/#!forum/knative-users) , - which grants read access to documents in the Team Drive. - -## Member - -Established community members are expected to demonstrate their adherence to the -principles in this document, familiarity with project organization, roles, -policies, procedures, conventions, etc., and technical and/or writing ability. - -Members are continuously active contributors in the community. They can have -issues and PRs assigned to them, participate in working group meetings, and -pre-submit tests are automatically run for their PRs. Members are expected to -remain active contributors to the community. - -All members are encouraged to help with the code review burden, although each PR -must be reviewed by an official [Approver](#approver). - -When reviewing, members should focus on code quality and correctness, including -testing and factoring. Members might also review for more holistic issues, but -this is not a requirement. - -### Requirements - -- Has made multiple contributions to the project or community. Contributions - might include, but are not limited to: - - - Authoring and reviewing PRs on GitHub. - - - Filing and commenting on issues on GitHub. - - - Contributing to working group or community discussions. - -- Subscribed to - [knative-dev@googlegroups.com](https://groups.google.com/forum/#!forum/knative-dev). - -- Actively contributing to 1 or more areas. - -- Sponsored by 1 approver. - - - Done by adding GitHub user to Knative organization. - -### Responsibilities and privileges - -- Responsive to issues and PRs assigned to them. - -- Active owner of code they have contributed (unless ownership is explicitly - transferred). - - - Code is well tested. - - - Tests consistently pass. - - - Addresses bugs or issues discovered after code is accepted. - -Members who frequently contribute code are expected to proactively perform code -reviews and work towards becoming an approver for the area that they are active -in. - -## Approver - -Code approvers are able to both review and approve code contributions. While -code review is focused on code quality and correctness, approval is focused on -holistic acceptance of a contribution including: backward / forward -compatibility, adhering to API and flag conventions, subtle performance and -correctness issues, interactions with other parts of the system, etc. Approver -status is scoped to a part of the codebase. - -### Requirements - -The following apply to the part of the codebase for which one would be an -approver in an OWNERS file: - -- Reviewer of the codebase for at least 3 months. - -- Primary reviewer for at least 10 substantial PRs to the codebase. - - - One path for getting the necessary reviews is to add yourself to the - `reviewers` section of the OWNERS file. Note that this does not give you any - additional privileges. By having yourself listed in this section in OWNERS - file means that you will get PRs assigned to you for code review. Getting - added to `reviewers` section is at the discretion of an approver after - enough evidence of quality contributions. - -- Reviewed or merged at least 30 PRs to the codebase. - -- Nominated by an area lead (with no objections from other leads). - - - Done through PR to update an OWNERS file. - -### Responsibilities and privileges - -The following apply to the part of the codebase for which one would be an -approver in an OWNERS file: - -- Approver status can be a precondition to accepting large code contributions. - -- Demonstrate sound technical judgment. - -* Responsible for project quality control via [code reviews](./REVIEWING.md). - - - Focus on holistic acceptance of contribution such as dependencies with other - features, backward / forward compatibility, API and flag definitions, etc. - -* Expected to be responsive to review requests as per - [community expectations](./REVIEWING.md). - -* Mentor members and contributors. - -* Might approve code contributions for acceptance. - -## Lead - -Working group leads, or just ‘leads’, are approvers of an entire area that have -demonstrated good judgement and responsibility. Leads accept design proposals -and approve design decisions for their area of ownership. - -### Requirements - -Getting to be a lead of an existing working group: - -- Recognized as having expertise in the group’s subject matter. - -- Approver for some part of the codebase for at least 3 months. - -- Member for at least 1 year or 50% of project lifetime, whichever is shorter. - -- Primary reviewer for 20 substantial PRs. - -- Reviewed or merged at least 50 PRs. - -- Sponsored by the technical oversight committee. - -Additional requirements for leads of a new working group: - -- Originally authored or contributed major functionality to the group's area. - -- An approver in the OWNERS file for the group’s code. - -### Responsibilities and privileges - -The following apply to the area / component for which one would be an owner. - -- Run their working group as explained in the - [Working Group Processes](./WORKING-GROUP-PROCESSES.md). - -- Design/proposal approval authority over the area / component, though - escalation to the technical oversight committee is possible. - -- Perform issue triage on GitHub. - -- Apply/remove/create/delete GitHub labels and milestones. - -- Write access to repo (assign issues/PRs, add/remove labels and milestones, - edit issues and PRs, edit wiki, create/delete labels and milestones). - -- Capable of directly applying lgtm + approve labels for any PR. - - - Expected to respect OWNERS files approvals and use - [standard procedure for merging code](./REVIEWING.md#merging-prs). - -- Expected to work to holistically maintain the health of the project through: - - - Reviewing PRs. - - - Fixing bugs. - - - Mentoring and guiding approvers, members, and contributors. - -## Administrator - -Administrators are responsible for the bureaucratic aspects of the project. - -### Requirements - -- Assigned by technical oversight committee. - -### Responsibilities and privileges - -- Manage the Knative GitHub repo, including granting membership and controlling - repo read/write permissions. - -- Manage the Knative Slack team. - -- Manage the Knative Google group forum. - -- Manage any additional Knative technical collaboration assets. - -- Expected to be responsive to membership and permission change requests. - - - - ---- - -Except as otherwise noted, the content of this page is licensed under the -[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), -and code samples are licensed under the -[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). diff --git a/contributing/SLACK-GUIDELINES.md b/contributing/SLACK-GUIDELINES.md deleted file mode 100644 index 8c745705b..000000000 --- a/contributing/SLACK-GUIDELINES.md +++ /dev/null @@ -1,144 +0,0 @@ ---- -title: "Slack usage guidelines" -linkTitle: "Slack guidelines" -weight: 45 -type: "docs" ---- - -Slack is the main communication platform for Knative outside of our mailing -lists. It’s important that conversation stays on topic in each channel, and that -everyone abides by the Code of Conduct. Community members should all expect to -have a positive experience. - -Chat is searchable and public. Do not make comments that you would not say on a -video recording or in another public space. Please be courteous to others. - -`@here` and `@channel` should be used rarely. Members will receive notifications -from these commands and we are a global project - please be kind. Note: `@all` -is only to be used by admins. - -You can join the [Knative Slack](https://slack.knative.dev) instance at -https://slack.knative.dev. - -## Code of Conduct - -The Knative [Code of Conduct](./CODE-OF-CONDUCT.md) applies throughout the -project, and includes all communication mediums. - -## Admins - -Members of the -[Technical Oversight Committee (TOC)](TECH-OVERSIGHT-COMMITTEE.md) and -[Knative Steering Committee (KSC)](STEERING-COMMITTEE.md) are also the -administrators for the Knative Slack instance. - -Slack admins should make sure to mention this in the “What I do” section of -their Slack profile, as well as for which time zone. - -To connect: please reach out in the #slack-admins channel or DM (Direct Message) -a member of the [KSC](STEERING-COMMITTEE.md) or -[TOC](TECH-OVERSIGHT-COMMITTEE.md). - -### Admin Expectations and Guidelines - -- Adhere to Code of Conduct -- Take care of spam as soon as possible, which may mean taking action by making - members inactive -- Moderating and fostering a safe environment for conversations -- Bring Code of Conduct issues to the Steering Committee -- Create relevant channels and list Code of Conduct in new channel welcome - message -- Help troubleshoot Slack issues -- Review bot, token, and webhook requests -- Be helpful! - -## Creating Channels - -Please reach out to the #slack-admins group with your request to create a new -channel. - -Channels are dedicated to [Working Groups](./WORKING-GROUPS.md), sub-projects, -community topics, and related programs/projects. - -Channels are not: - -- company specific; e.g. a channel named for a cloud provider must be used for - conversation about Knative-related topics on that cloud, and not proprietary - information of the provider. -- private unless there is an exception: code of conduct matters, mentoring, - security/vulnerabilities, or steering committee. - -All channels need a documented purpose. Use this space to welcome the targeted -community: promote your meetings, post agendas, etc. - -We may make special accommodations where necessary. - -## Escalating and/or Reporting a Problem - -Join the #slack-admins channel or contact one of the admins in the closest -timezone via DM directly and describe the situation. If the issue can be -documented, please take a screenshot to include in your message. - -### What if you have a problem with an admin - -Send a DM to another listed Admin and describe the situation, or if it’s a code -of conduct issue, please send an email to -knative-code-of-conduct@googlegroups.com and describe the situation. - -## Bots, Tokens, and Webhooks - -Bots, tokens, and webhooks are reviewed on a case-by-case basis. Expect most -requests will be rejected due to security, privacy, and usability concerns. Bots -and the like tend to make a lot of noise in channels. - -Please join #slack-admins and have a discussion about your request before -requesting the access. - -## Admin Moderation - -Be mindful of how you handle communication during stressful interactions. -Administrators act as direct representatives of the project, and need to -maintain a very high level of professionalism at all times. If you feel too -involved in the situation to maintain impartiality or professionalism, that’s a -great time to enlist the help of another admin. - -Try to take any situations that involve upset or angry members to DM or video -chat. Please document these interactions for other Slack admins to review. - -Content will be automatically removed if it violates code of conduct or is a -sales pitch. Admins will take a screenshot of such behavior in order to document -the situation. Google takes such violations extremely seriously, and they will -be handled swiftly. - -## Inactivating Accounts - -For reasons listed below, admins may inactivate individual Slack accounts. Due -to Slack’s framework, it does not allow for an account to be banned or suspended -in the traditional sense. -[Read Slack’s policy on this.](https://get.Slack.help/hc/en-us/articles/204475027-Deactivate-a-member-s-account) - -- Spreading spam content in DMs and/or channels -- Not adhering to the code of conduct set forth in DMs and/or channels -- Overtly selling products, related or unrelated to Knative - -## Specific Channel Rules - -In the case that certain channels have rules or guidelines, they will be listed -in the purpose or pinned docs of that channel. - -## DM (Direct Message) Conversations - -Please do not engage in proprietary company specific conversations in the -Knative Slack instance. This is meant for conversations related to Knative open -source topics and community. - -Proprietary conversations should occur in your company communication platforms. -As with all communication, please be mindful of appropriateness, -professionalism, and applicability to the Knative community. - ---- - -Except as otherwise noted, the content of this page is licensed under the -[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), -and code samples are licensed under the -[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). diff --git a/contributing/STEERING-COMMITTEE.md b/contributing/STEERING-COMMITTEE.md deleted file mode 100644 index 97d32606b..000000000 --- a/contributing/STEERING-COMMITTEE.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -title: "Knative steering committee" -linkTitle: "Steering committee" -weight: 40 -type: "docs" ---- - -The Knative Steering Committee (KSC) is the ultimate authority for the Knative -project, and governs all aspects of the project. - -The governance of Knative is an open, living document, and will continue to -evolve as the community and project change. We expect over time we will adapt -the way we run this committee, based on feedback from the community. - -- [Charter](#charter) -- [Delegated authority](#delegated-authority) -- [Committee Meetings](#committee-meetings) -- [Committee Mechanics](#committee-mechanics) -- [Committee Members](#committee-members) - - [Allocation of seats](#allocation-of-seats) -- [Decision process](#decision-process) -- [Changes to the charter](#changes-to-the-charter) -- [Getting in touch](#getting-in-touch) - -## Charter - -1. Define, evolve, and promote the vision, values, mission, and scope of the - project. -1. Define and evolve project governance structures and policies, including - project roles and how collaborators become members, approvers, leads, and/or - administrators. This includes policy for the creation and administration of - [working groups](./WORKING-GROUPS.md) and committees. -1. Steward, control access, delegate access, and establishes processes - regarding, all Knative project resources and has the final say in the - disposition of those resources. -1. Manage the Knative brand and decide which things can be called "Knative" and - how that mark can be used in relation to other efforts or vendors. -1. Confirm/reject nominations to the KSC from organizations who are allocated - seats. -1. Confirm/reject nominations to the Technical Oversight Committee. -1. Receive and handle reports about [code of conduct](./CODE-OF-CONDUCT.md) - violations and maintain confidentiality. -1. Receive security reports; work with the appropriate technical leads to accept - or reject the report; maintain the private nature of such reports until - disclosed to the broader community. -1. Act as the final escalation point and decider for any disputes, issues, - clarifications, or escalations within the project scope. - -## Delegated authority - -KSC may choose to delegate its authority to other committees as-needed. The -committee currently recognizes this delegated authority for: - -- Technical guidance is delegated to the - [Technical Oversight Committee](./TECH-OVERSIGHT-COMMITTEE.md). - -## Committee Meetings - -KSC meets every two weeks, or as-needed. Meetings are held online. - -Given the private nature of many of these discussions (e.g. privacy, private -emails to the committee, code of conduct violations, escalations, disputes -between members, security reports, etc.) meetings are held in private. - -Meeting notes are available to members of the knative-dev mailing list (link to -be added). - -Questions and proposals for changes to governance are posted as issues in the -[docs repo](https://github.com/knative/docs), and the KSC invites your feedback -there. See [Getting in touch](#getting-in-touch) for other options. - -## Committee members - -Seats on the Steering Committee are held by an organization, not by the -individual. - -The committee was created as the project was in its infancy, in order to tackle -governance and overall project strategy. Because of the nature of the project -and funding required, it was decided that strong corporate leadership was -necessary for the project to ensure velocity. As the project grows and matures -the KSC will, from time to time, consider if this policy should be changed. - -The current membership of the committee is currently (listed alphabetically by -first name): - -|   | Member | Organization | Profile | -| --------------------------------------------------------- | ---------------- | ------------ | ------------------------------------------ | -| | Brenda Chan | Pivotal | [@bsnchan](https://github.com/bsnchan) | -| | DeWitt Clinton | Google | [@dewitt](https://github.com/dewitt) | -| | Mark Chmarny | Google | [@mchmarny](https://github.com/mchmarny) | -| | Michael Behrendt | IBM | [@mbehrendt](https://github.com/mbehrendt) | -| | Paul Morie | Red Hat | [@pmorie](https://github.com/pmorie) | -| | Ryan Gregg | Google | [@rgregg](https://github.com/rgregg) | -| | Tomas Isdal | Google | [@isdal](https://github.com/isdal) | - -### Allocation of seats - -Seats on the steering committee are allocated based upon contribution to the -project by an organization. No final decision has been made on the exact -formula. - -As the project continues to grow, we expect to add additional seats to the -committee, ensuring that those contributing to the project are properly -represented. - -- After a seat is allocated to an organization, the organization shall nominate - a candidate to be confirmed by KSC. The committee reserves the right to not - confirm a candidate, in which the organization would need to nominate a new - candidate -- Members of the committee may step down at any time. When a member steps down, - their organization shall nominate a new candidate. -- If a member leaves their organization, the organization must nominate a new - committee member to replace them following the nomination and confirmation - process. -- If an organization is unable to seat a candidate, the KSC reserves the right - to reallocate the seat to another organization. -- Changes to the number of seats, which company seats are allocated to, and - nominations to the committee are confirmed by majority vote of the committee - members. -- In situations where the organization which holds a seat is no longer a viable - entity (e.g. merger, dissolution, bankruptcy) the KSC will make a decision on - how to reallocate that seat. Seats do not automatically transfer to any - organization. -- Members on the committee have a 1 year term from their confirmation, and may - be reconfirmed to the committee at the end of their term. - -## Decision process - -The steering committee desires to always reach consensus. - -Decisions are made in meetings when a quorum of the members are present and may -pass with majority of the committee supporting it. - -Quorum is considered reached when at least half of the members are present. - -In case of extended absence, the organization of the absent member may appoint a -single delegate from the same company during the absence. - -## Changes to the charter - -Changes to the KSC charter may be proposed via a Pull Request on the charter -itself. Amendments are accepted with majority consent of the committee. - -Proposals and amendments to the charter are available for at least a period of -one week for comments and questions before a vote will occur. - -## Getting in touch - -If you'd like to reach out to the committee, please drop a note to -[knative-steering@googlegroups.com](mailto:knative-steering@googlegroups.com). -This is a private discussion list to which all members of the committee have -access. - ---- - -Portions of this document are adapted from the -[Istio Steering Committee](https://github.com/istio/community/blob/master/STEERING-COMMITTEE.md) -documentation, which is licensed under the Apache License 2.0. - -Except as otherwise noted, the content of this page is licensed under the -[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), -and code samples are licensed under the -[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). diff --git a/contributing/TECH-OVERSIGHT-COMMITTEE.md b/contributing/TECH-OVERSIGHT-COMMITTEE.md deleted file mode 100644 index 3bf0283b8..000000000 --- a/contributing/TECH-OVERSIGHT-COMMITTEE.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: "Knative technical oversight committee" -linkTitle: "Technical oversight committee" -weight: 35 -type: "docs" ---- - -The Knative Technical Oversight Committee (TOC) is responsible for cross-cutting -product and design decisions. - -- [Charter](#charter) -- [Committee Mechanics](#committee-mechanics) -- [Committee Meeting](#committee-meeting) -- [Committee Members](#committee-members) - -## Charter - -- Technical Project Oversight, Direction & Delivery - - - Set the overall technical direction and roadmap of the project. - - - Resolve technical issues, technical disagreements and escalations within the - project. - - - Set the priorities of individual releases to ensure coherency and proper - sequencing. - - - Approve declaring a new long-term supported (LTS) Knative release. - - - Approve the creation and dissolution of working groups and approve - leadership changes of working groups. - - - Create proposals based on TOC discussions and bring them to the relevant - working groups for discussion. - - - Approve the creation/deletion of GitHub repositories, along with other - high-level administrative issues around GitHub and our other tools. - -- Happy Healthy Community - - - Establish and maintain the overall technical governance guidelines for the - project. - - - Decide which sub-projects are part of the Knative project, including - accepting new sub-projects and pruning existing sub-projects to maintain - community focus - - - Ensure the team adheres to our - [code of conduct](./CONTRIBUTING.md#code-of-conduct) and respects our - [values](./VALUES.md). - - - Foster an environment for a healthy and happy community of developers and - contributors. - -## Committee Mechanics - -The TOC’s work includes: - -- Regular committee meetings to discuss hot topics, resulting in a set of - published - [meeting notes](https://docs.google.com/document/d/1hR5ijJQjz65QkLrgEhWjv3Q86tWVxYj_9xdhQ6Y5D8Q/edit#). - -- Create, review, approve and publish technical project governance documents. - -- Create proposals for consideration by individual working groups to help steer - their work towards a common project-wide objective. - -- Review/address/comment on project issues. - -- Act as a high-level sounding board for technical questions or designs bubbled - up by the working groups. - -## Committee Meeting - -Community members are encouraged to suggest topics for discussion ahead of the -TOC meetings, and are invited to observe these meetings and engage with the TOC -during the community feedback period at the end of each meeting. - -| Artifact | Link | -| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Google Group | [knative-tech-oversight@googlegroups.com](https://groups.google.com/forum/#!forum/knative-tech-oversight) | -| Community Meeting VC | [meet.google.com/ffc-rypd-kih](https://meet.google.com/ffc-rypd-kih)
or dial in:
(US) +1 240-630-1102 PIN: 316262# | -| Community Meeting Calendar | Thursdays at 11:30a-12p
[Calendar](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) | -| Meeting Notes | [Notes](https://docs.google.com/document/d/1hR5ijJQjz65QkLrgEhWjv3Q86tWVxYj_9xdhQ6Y5D8Q/edit#heading=h.g47ptr8u5cov) | -| Document Folder | [Folder](https://drive.google.com/drive/folders/1_OHttsYLCVtX202aXNmJJrAHJ7BaXcu6) | - -## Committee Members - -The members of the TOC are shown below. Membership in the TOC is determined by -the [Steering committee](./STEERING-COMMITTEE.md). - -|   | Member | Company | Profile | -| ------------------------------------------------------------- | ------------- | ------- | -------------------------------------------------- | -| | Evan Anderson | Google | [@evankanderson](https://github.com/evankanderson) | -| | Matt Moore | Google | [@mattmoor](https://github.com/mattmoor) | -| | Ville Aikas | Google | [@vaikas-google](https://github.com/vaikas-google) | - ---- - -Except as otherwise noted, the content of this page is licensed under the -[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), -and code samples are licensed under the -[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). diff --git a/contributing/VALUES.md b/contributing/VALUES.md deleted file mode 100644 index 2ffad0267..000000000 --- a/contributing/VALUES.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Knative team values" -linkTitle: "Team values" -weight: 50 -type: "docs" ---- - -We want to make sure every member has a shared understanding of the goals and -values we hold as a team: - -- Optimize for the **overall project**, not your own area or feature - - - A shortcut for one individual can mean a lot of extra work or disruption for - the rest of the team. - -- Our repos should always be in release shape: **Always Green** - - - This lets us move faster in the mid and long term. - - This implies investments in build/test infrastructure to have fast, reliable - tests to ensure that we can release at any time. - - Extra discipline may require more work by individuals to keep the build in - good state, but less work overall for the team. - -- Be **specific**, **respectful** and **courteous** - - - Disagreements are welcome and encouraged, but don't use broad - generalizations, exaggerations, or judgment words that can be taken - personally. Consider other people’s perspective (including the wide range of - applicability of Knative). Empathize with our users. Focus on the specific - issue at hand, and remember that we all care about the project, first and - foremost. - - Emails to the [mailing lists](./CONTRIBUTING.md#contributing-a-feature), - document comments, or meetings are often better and higher bandwidth ways to - communicate complex and nuanced design issues, as opposed to protracted - heated live chats. - - Be mindful of the terminology you are using, it may not be the same as - someone else and cause misunderstanding. To promote clear and precise - communication, define the terms you are using in context. - - See also the [Code of Conduct](./CODE-OF-CONDUCT.md), which everyone must - abide by. - -- Raising issues is great, suggesting solutions is even better - - - Think of a proposed alternative and improvement rather than just what you - perceive as wrong. - - If you have no immediate solution even after thinking about it - if - something does seem significant, raise it to someone who might be able to - also think of solutions or to the group (don’t stay frustrated! Feel safe in - bringing up issues. - - Avoid rehashing old issues that have been resolved/decided (unless you have - new insights or information). - -- Be productive and **happy**, and most importantly, have _fun_ :-) - ---- - -Except as otherwise noted, the content of this page is licensed under the -[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), -and code samples are licensed under the -[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). diff --git a/contributing/WORKING-GROUP-PROCESSES.md b/contributing/WORKING-GROUP-PROCESSES.md deleted file mode 100644 index 9e3e57ab9..000000000 --- a/contributing/WORKING-GROUP-PROCESSES.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -title: "Knative working group processes and guidelines" -linkTitle: "Working group guidelines" -weight: 30 -type: "docs" ---- - -This document describes the processes we use to manage the Knative working -groups. This includes how they are formed, how leads are established, how they -are run, etc. - -- [Why working groups?](#why-working-groups) -- [Proposing a new working group](#proposing-a-new-working-group) -- [Setting up a working group](#setting-up-a-working-group) - - [Dissolving a working group](#dissolving-a-working-group) -- [Running a working group](#running-a-working-group) - - [Be open](#be-open) - - [Making decisions](#making-decisions) - - [Subgroups](#subgroups) - - [Escalations](#escalations) - -## Why working groups? - -Knative working groups are organizations responsible for the design and -implementation of large architectural aspects of the overall Knative project. -Working groups operate with a fair amount of autonomy within the broader scope -of the project. They tend to be long-lived, representing major initiatives over -Knative’s lifetime. - -Some working groups focus on specific technologies. Other working groups are -cross-cutting in nature. - -The technical oversight committee is responsible for the Knative project as a -whole. It sets the overall direction of the project, helps make crosscutting -architectural decisions, helps establish and dissolve working groups, and helps -ensure all working groups are generally rowing in the same direction - -Although working groups are relatively lightweight structures, we want to keep -the number of working groups low in order to keep things manageable. - -## Proposing a new working group - -If you’ve identified a substantial architectural area which would benefit from -long-lived, concerted and focused design, then you should consider creating a -new working group. To do so, you need to: - -- **Create a charter**. This should be a few paragraphs explaining: - - - The mission of the working group - - - The goals of the working group (problems being solved) - - - The scope of the working group (topics, subsystems, code repos, areas of - responsibility) - -- **Nominate an initial set of leads**. The leads set the agenda for the working - group and serve as final arbiters on any technical decision. See - [below](#leads) for information on the responsibilities of leads and - requirements for nominating them. - -- **Prepare a Roadmap**. Create a preliminary 3 month roadmap for what the - working group would focus on. - -- **Send an Email**. Write up an email with your charter, nominated leads, and - roadmap, and send it to - [knative-tech-oversight@](mailto:knative-tech-oversight@googlegroups.com). The - technical oversight committee will evaluate the request and decide whether the - working group should be formed, whether it should be merely a subgroup of an - existing working group, or whether it should be subsumed by an existing - working group. - -## Setting up a working group - -Once approval has been granted by the technical oversight committee to form a -working group, the working group leads need to take a few steps to establish the -working group: - -- **Create a Google Drive Folder**. Create a folder to hold your working group - documents within this parent - [folder](https://drive.google.com/corp/drive/folders/0APnJ_hRs30R2Uk9PVA). - Call your folder "GROUP_NAME". - -- **Create a Meeting Notes Document**. Create a blank document in the above - folder and call it "GROUP_NAME Group Meeting Notes". - -- **Create a Roadmap Document**. Create a document in the above folder and call - it "GROUP_NAME Group Roadmap". Put your initial roadmap in the document. - -- **Create a Wiki**. Create a wiki page on - [GitHub](https://github.com/knative/serving) titled "GROUP_NAME Design - Decisions". This page will be used to track important design decisions made by - the working group. - -- **Create a Public Google Group**. Call the group "knative-_group_name_" (all - in lowercase, dashes for spaces). This mailing list must be open to all. - -- **Schedule a Recurring Meeting**. Create a recurring meeting (weekly or - bi-weekly, 30 or 60 minutes) and call the meeting GROUP_NAME Group Sync-Up". - Attach the meeting notes document to the calendar event. Generally schedule - these meetings between 9:00AM to 2:59PM Pacific Time. Invite the public Google - group to the meeting. - -- **Register the Working Group**. Go to [WORKING-GROUPS.md](./WORKING-GROUPS.md) - and add your working group name, the names of the leads, the working group - charter, and a link to the meeting you created. - -- **Announce your Working Group**. Send a note to - [knative-dev@](mailto:knative-dev@googlegroups.com) and - [knative-tech-oversight@](mailto:knative-tech-oversight@googlegroups.com) to - announce your new working group. Include your charter in the email and provide - links to the meeting invitation. - -Congratulations, you now have a fully formed working group! - -### Dissolving a working group - -Some working groups are ephemeral or naturally reach the end of their useful -life. Working group leads can petition to dissolve their working groups by -emailing -[knative-tech-oversight@googlegroups.com](mailto:knative-tech-oversight@googlegroups.com). -The technical oversight committee takes ownership of any artifacts created or -owned by the dissolved working group. The technical oversight committee also -reserves the right to dissolve or recharter working groups over time as -necessary, though they will strive to first discuss this in committee meetings -and open community discussion. - -## Leads - -Each working group should have at least 2 leads, ideally 3, though young working -groups may have only 1 lead initially. Working groups should strive to include -representatives from multiple organizations as both leads and members. Working -group leads must be Members of the Knative project (that is, have made multiple -contributions to the project in the form of code, design, or documentation). - -Please see the [Community Roles](./ROLES.md) document for a description of a -lead’s role and requirements. - -## Running a working group - -Leads are responsible for running a working group. Running the group involves a -few activities: - -- **Meetings**. Prepare the agenda and run the regular working group meetings. - Ensure the meetings are recorded, and properly archived. - -- **Notes**. Ensure that meeting notes are kept up to date. Provide a link to - the recorded meeting in the notes. The lead may delegate note-taking duties. - -- **Wiki**. Ensure that significant design decisions are captured in the Wiki. - In the Wiki, include links to useful design documents, any interesting GitHub - issues or PRs, posts to the mailing lists, etc. The wiki should provide a good - feel for where the mind of the working group is at and where things are - headed. - -- **Roadmap**. Establish **and maintain** a roadmap for the working group - outlining the areas of focus for the working group over the next 3 months. - -- **Report**. Report current status to the main community meeting every 6 weeks. - -### Be open - -The community design process is done in the open. Working groups should -communicate primarily through the public working group meetings, through design -documents in the working group’s folder, through GitHub issues, and GitHub PRs. -Avoid private emails and/or meeting when possible. - -### Making decisions - -In general, working groups operate in a highly cooperative environment. Working -groups discuss designs in the open and take input from the community at large -when making technical choices. The working group leads are ultimately -responsible for setting the direction of the working group and making the tough -technical choices affecting the working group. - -### Subgroups - -Subgroups are ad hoc subteams within a working group with a special focus on a -set of problems or technologies. We don’t formalize processes for subgroups, -each working group can decide when subgroups are needed and how they operate. - -### Escalations - -Working groups can get blocked on specific technical disagreements. Leads are -expected to generally resolve such issues and allow work to progress. - -Sometimes, different working groups can have conflicting goals or requirements. -Leads from all affected working groups generally work together and come to an -agreeable conclusion. - -In all cases, remaining blocking issues can be raised to the -[technical oversight committee](./TECH-OVERSIGHT-COMMITTEE.md) to help resolve -the situation. To trigger an escalation, create an issue in the project's repo -and assign it to the **@knative/tech-oversight-committee** team. - -The Steering Committee, as a last resort, provides the final escalation path for -any repository or working group issue that cannot be resolved by the TOC. - ---- - -Except as otherwise noted, the content of this page is licensed under the -[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), -and code samples are licensed under the -[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). diff --git a/contributing/WORKING-GROUPS.md b/contributing/WORKING-GROUPS.md deleted file mode 100644 index 0901410da..000000000 --- a/contributing/WORKING-GROUPS.md +++ /dev/null @@ -1,216 +0,0 @@ ---- -title: "Knative working group" -linkTitle: "Join working groups" -weight: 25 -type: "docs" ---- - -Most community activity is organized into _working groups_. - -Working groups follow the [contributing](./CONTRIBUTING.md) guidelines although -each of these groups may operate a little differently depending on their needs -and workflow. - -When the need arises, a new working group can be created. See the -[working group processes](./WORKING-GROUP-PROCESSES.md) for working group -proposal and creation procedures. - -The working groups generate design docs which are kept in a -[shared drive](https://drive.google.com/corp/drive/folders/0APnJ_hRs30R2Uk9PVA) -and are available for anyone to read and comment on. The shared drive currently -grants read access to -[knative-users@](https://groups.google.com/forum/#!forum/knative-users) and edit -and comment access to the -[knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) Google -group. - -Additionally, all working groups should hold regular meetings, which should be -added to the -[shared knative calendar](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) -WG leads should have access to be able to create and update events on this -calendar, and should invite knative-dev@googlegroups.com to working group -meetings. - -The current working groups are: - -- [API Core](#api-core) -- [Build](#build) -- [Client](#client) -- [Documentation](#documentation) -- [Eventing](#eventing) -- [Networking](#networking) -- [Observability](#observability) -- [Productivity](#productivity) -- [Scaling](#scaling) - - -## API Core - -API -[resources](https://github.com/knative/serving/tree/master/pkg/apis/serving), -[validation](https://github.com/knative/pkg/tree/master/webhook), and -[semantics](https://github.com/knative/pkg/tree/master/controller). - -| Artifact | Link | -| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) | -| Community Meeting VC | [https://meet.google.com/bzx-bjqa-rha](https://meet.google.com/bzx-bjqa-rha)
Or dial in:
(US) +1 262-448-6367
PIN: 923 539# | -| Community Meeting Calendar | Wednesdays 10:30a-11:00a PST
[Calendar](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) | -| Meeting Notes | [Notes](https://docs.google.com/document/d/1NC4klOdNaU-N-PsKLyXBqDKgNSHtxCDep29Ta2b5FK0/edit) | -| Document Folder | [Folder](https://drive.google.com/corp/drive/folders/1fpBW7VyiBISsKuVdgn1MrgFdtx_JGoC5) | -| Slack Channel | [#serving-api](https://slack.knative.dev/messages/serving-api) | - -|   | Leads | Company | Profile | -| -------------------------------------------------------- | ---------- | ------- | --------------------------------------- | -| | Matt Moore | Google | [mattmoor](https://github.com/mattmoor) | - -## Build - -[Build](https://github.com/knative/build), Builders, and Build templates - -| Artifact | Link | -| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) | -| Community Meeting VC | [meet.google.com/hau-nwak-tgm](https://meet.google.com/hau-nwak-tgm)
Or dial in:
(US) +1 219-778-6103‬ PIN: ‪573 000‬# | -| Community Meeting Calendar | Every other Wednesday 10:00a-10:30a PST
[Calendar](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) | -| Meeting Notes | [Notes](https://docs.google.com/document/d/1e7gMVFlJfkFdTcaWj2qETeRD9kSBG2Vh8mASPmQMYC0/edit) | -| Document Folder | [Folder](https://drive.google.com/corp/drive/folders/1ov16HvPam-v_FXAGEaUdHok6_hUAoIoe) | -| Slack Channel | [#build-crd](https://slack.knative.dev/messages/build-crd) | - -|   | Leads | Company | Profile | -| -------------------------------------------------------- | ---------- | ------- | --------------------------------------- | -| | Jason Hall | Google | [ImJasonH](https://github.com/ImJasonH) | -| | Matt Moore | Google | [mattmoor](https://github.com/mattmoor) | - -## Client - -[Client](https://github.com/knative/client), CLI, client libraries, and client -conventions - -| Artifact | Link | -| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) | -| Community Meeting VC | [meet.google.com/spi-umby-dmw](https://meet.google.com/spi-umby-dmw)
Or dial in:
(US) +1 929-445-2235
PIN: 824 001# | -| Community Meeting Calendar | Tuesdays 10:30a-11:00a Pacific
[Calendar Invitation](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) | -| Meeting Notes | [Notes](https://docs.google.com/document/d/1Uh7jTWQruBBmic-WmTvtc9cMF95kQrKb5lsqWhNuikM/edit) | -| Document Folder | [Folder](https://drive.google.com/corp/drive/folders/1QF-job3rCEqCpJLm8nHkC4mBIi4XANE1) | -| Slack Channel | [#cli](https://slack.knative.dev) | - -|   | Leads | Company | Profile | -| ---------------------------------------------------------- | --------------- | ------- | ------------------------------------------- | -| | Naomi Seyfer | Google | [sixolet](https://github.com/sixolet) | -| | Dmitriy Kalinin | Pivotal | [cppforlife](https://github.com/cppforlife) | - -## Documentation - -Knative documentation, especially the [Docs](../docs/README.md) repo. - -| Artifact | Link | -| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Forum | [knative-docs@](https://groups.google.com/forum/#!forum/knative-docs) | -| Community Meeting VC | [meet.google.com/mku-npuv-cjs](https://meet.google.com/mku-npuv-cjs)
Or dial in:
(US) +1 260-277-0211
PIN: 956 724#‬‬ | -| Community Meeting Calendar | Weekly on Tuesdays, alternating between 9:00-9:30am and 4:30-5:00pm PST
[Calendar](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) | -| Meeting Notes | [Notes](https://docs.google.com/document/d/1Y7rug0XshcQPdKzptdWbQLQjcjgpFdLeEgP1nfkDAe4/edit) | -| Document Folder | [Folder](https://drive.google.com/corp/drive/folders/1K5cM9m-b93ySI5WGKalJKbBq_cfjyi-y) | -| Slack Channel | [#docs](https://slack.knative.dev/messages/docs) | - -|   | Leads | Company | Profile | -| -------------------------------------------------------- | ---------- | ------- | --------------------------------------- | -| | Sam O'Dell | Google | [samodell](https://github.com/samodell) | - -## Eventing - -Event sources, bindings, FaaS framework, and orchestration - -| Artifact | Link | -| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) | -| Community Meeting VC | [meet.google.com/uea-zcwt-drt](https://meet.google.com/uea-zcwt-drt)
Or dial in:
(US) +1 919 525 1825
PIN: 356 842# | -| Community Meeting Calendar | Wednesdays 9:00a-9:30a PST
[Calendar](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) | -| Meeting Notes | [Notes](https://docs.google.com/document/d/1uGDehQu493N_XCAT5H4XEw5T9IWlPN1o19ULOWKuPnY/edit) | -| Document Folder | [Folder](https://drive.google.com/corp/drive/folders/1S22YmGl6B1ppYApwa1j5j9Nc6rEChlPo) | -| Slack Channel | [#eventing](https://slack.knative.dev/messages/eventing) | - -|   | Leads | Company | Profile | -| ------------------------------------------------------------- | ----------- | ------- | ------------------------------------------------- | -| | Ville Aikas | Google | [vaikas-google](https://github.com/vaikas-google) | - -## Networking - -Inbound and outbound network connectivity for -[serving](https://github.com/knative/serving) workloads. Specific areas of -interest include: load balancing, routing, DNS configuration and TLS support. - -| Artifact | Link | -| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) | -| Community Meeting VC | [meet.google.com/cet-jepr-gtx](https://meet.google.com/cet-jepr-gtx)
Or dial in:
(US) +1 570-865-1288
PIN: 741 211# | -| Community Meeting Calendar | Thursdays at 9:00a-9:30a PST
[Calendar](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) | -| Meeting Notes | [Notes](https://drive.google.com/open?id=1EE1t5mTfnTir2lEasdTMRNtuPEYuPqQCZbU3NC9mHOI) | -| Document Folder | [Folder](https://drive.google.com/corp/drive/folders/1oVDYbcEDdQ9EpUmkK6gE4C7aZ8u6ujsN) | -| Slack Channel | [#networking](https://slack.knative.dev/messages/networking) | - -|   | Leads | Company | Profile | -| --------------------------------------------------------- | ---------------- | ------- | ----------------------------------------- | -| | Nghia Tran | Google | [tcnghia](https://github.com/tcnghia) | -| | Mustafa Demirhan | Google | [mdemirhan](https://github.com/mdemirhan) | - -## Observability - -Logging, monitoring & tracing infrastructure - -| Artifact | Link | -| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) | -| Community Meeting VC | meet.google.com/kps-noeu-uzz
Or dial in:
(US) ‪+1 413-301-9135‬
PIN: ‪602 561‬# | -| Community Meeting Calendar | Every other Thursday, 10:30a-11a PST
[Calendar](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) | -| Meeting Notes | [Notes](https://drive.google.com/open?id=1vWEpjf093Jsih3mKkpIvmWWbUQPxFkcyDxzNH15rQgE) | -| Document Folder | [Folder](https://drive.google.com/corp/drive/folders/10HcpZlI1PbFyzinO6HjfHbzCkBXrqXMy) | -| Slack Channel | [#observability](https://slack.knative.dev/messages/observability) | - -|   | Leads | Company | Profile | -| --------------------------------------------------------- | ---------------- | ------- | ----------------------------------------- | -| | Mustafa Demirhan | Google | [mdemirhan](https://github.com/mdemirhan) | - -## Scaling - -Autoscaling - -| Artifact | Link | -| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) | -| Community Meeting VC | [Hangouts](https://meet.google.com/ick-mumc-mjv?hs=122) | -| Community Meeting Calendar | Wednesdays at 9:30am PST
[Calendar](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) | -| Meeting Notes | [Notes](https://docs.google.com/document/d/1FoLJqbDJM8_tw7CON-CJZsO2mlF8Ia1cWzCjWX8HDAI/edit#heading=h.c0ufqy5rucfa) | -| Document Folder | [Folder](https://drive.google.com/corp/drive/folders/1qpGIPXVGoMm6IXb74gPrrHkudV_bjIZ9) | -| Slack Channel | [#autoscaling](https://slack.knative.dev/messages/autoscaling) | - -|   | Leads | Company | Profile | -| ------------------------------------------------------------- | -------------- | ------- | ------------------------------------------------- | -| | Joseph Burnett | Google | [josephburnett](https://github.com/josephburnett) | - -## Productivity - -Project health, test framework, continuous integration & deployment, release, -performance/scale/load testing infrastructure - -| Artifact | Link | -| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) | -| Community Meeting VC | [Hangouts](https://meet.google.com/sps-vbhg-rfx) | -| Community Meeting Calendar | Every other Thursday, 2p PST
[Calendar](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) | -| Meeting Notes | [Notes](https://docs.google.com/document/d/1aPRwYGD4XscRIqlBzbNsSB886PJ0G-vZYUAAUjoydko) | -| Document Folder | [Folder](https://drive.google.com/corp/drive/folders/1oMYB4LQHjySuMChmcWYCyhH7-CSkz2r_) | -| Slack Channel | [#productivity](https://slack.knative.dev/messages/productivity) | - -|   | Leads | Company | Profile | -| --------------------------------------------------------- | ------------- | ------- | ----------------------------------------- | -| | Jessie Zhu | Google | [jessiezcc](https://github.com/jessiezcc) | -| | Adriano Cunha | Google | [adrcunha](https://github.com/adrcunha) | - ---- - -Except as otherwise noted, the content of this page is licensed under the -[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), -and code samples are licensed under the -[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).