mirror of https://github.com/knative/docs.git
remove duplicate files -> all moved to knative/community (#1291)
This commit is contained in:
RichieEscarez
Knative Prow Robot
parent
8d62a0b066
commit
06f51184f7
|
|
@ -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).
|
||||
|
|
@ -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).
|
||||
|
|
@ -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. <br> 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.
|
||||
|
|
@ -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).
|
||||
|
|
@ -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).
|
||||
|
|
@ -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).
|
||||
|
|
@ -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.
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Role</th>
|
||||
<th>Responsibilities</th>
|
||||
<th>Requirements</th>
|
||||
<th>Privileges</th>
|
||||
<th>Scope</th>
|
||||
</tr>
|
||||
</thead>
|
||||
|
||||
<tr>
|
||||
<td>Collaborator</td>
|
||||
<td>Casual contributor to the project</td>
|
||||
<td>Join [knative-users@](https://groups.google.com/forum/#!forum/knative-users) to get access to the team drive.</td>
|
||||
<td>
|
||||
<p>Can submit PRs</p>
|
||||
<p>Commenting permission on the Knative Team drive</p>
|
||||
</td>
|
||||
<td>GitHub Organization</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Member</td>
|
||||
<td>Regular active contributor in the community</td>
|
||||
<td>
|
||||
<p>Sponsored by two members</p>
|
||||
<p>Has made multiple contributions to the project</p>
|
||||
</td>
|
||||
<td>
|
||||
<p>Member of the GitHub Knative org</p>
|
||||
<p>Member of the Knative Slack workspace</p>
|
||||
<p>Edit permission on the Knative Team drive</p>
|
||||
</td>
|
||||
<td>GitHub Organization</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Approver</td>
|
||||
<td>
|
||||
<p>Approve contributions from other members</p>
|
||||
</td>
|
||||
<td>Highly experienced and active reviewer and contributor to an area</td>
|
||||
<td>Entry in one or more OWNERS files in GitHub, and write permissions
|
||||
on one or more repos allowing PRs to be merged.
|
||||
</td>
|
||||
<td>GitHub Directory</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Lead</td>
|
||||
<td>
|
||||
<p>Set priorities for a functional area and approve proposals</p>
|
||||
<p>Triage incoming issues, set milestones, repo labels</p>
|
||||
<p>Run their working group</p>
|
||||
</td>
|
||||
<td>Sponsored by the technical oversight committee as documented
|
||||
<a href="./WORKING-GROUP-PROCESSES.md">here</a>.
|
||||
</td>
|
||||
<td>Write permissions on one or more repos allowing issues to be manipulated.</td>
|
||||
<td>Working Group</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Administrator</td>
|
||||
<td>Manage & control permissions</td>
|
||||
<td>Sponsored by the technical oversight committee</td>
|
||||
<td>
|
||||
<p>Admin privileges on the GitHub Knative org and all its repos</p>
|
||||
<p>Admin privileges on the Knative Slack workspace</p>
|
||||
<p>Admin privileges on the Knative Team Drive</p>
|
||||
<p>Admin privileges on the Google Search Console for knative.dev</p>
|
||||
<p>Admin privilege to the Knative email lists.</p>
|
||||
</td>
|
||||
<td>
|
||||
<p>GitHub Organization</p>
|
||||
<p>Team Drive</p>
|
||||
<p>Slack</p>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## 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.
|
||||
<!-- TODO SLA for admin response -->
|
||||
|
||||
<!-- * TODO Manage the Google Search Console settings for knative.dev -->
|
||||
|
||||
---
|
||||
|
||||
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).
|
||||
|
|
@ -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).
|
||||
|
|
@ -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 |
|
||||
| --------------------------------------------------------- | ---------------- | ------------ | ------------------------------------------ |
|
||||
| <img width="30px" src="https://github.com/bsnchan.png"> | Brenda Chan | Pivotal | [@bsnchan](https://github.com/bsnchan) |
|
||||
| <img width="30px" src="https://github.com/dewitt.png"> | DeWitt Clinton | Google | [@dewitt](https://github.com/dewitt) |
|
||||
| <img width="30px" src="https://github.com/mchmarny.png"> | Mark Chmarny | Google | [@mchmarny](https://github.com/mchmarny) |
|
||||
| <img width="30px" src="https://github.com/mbehrendt.png"> | Michael Behrendt | IBM | [@mbehrendt](https://github.com/mbehrendt) |
|
||||
| <img width="30px" src="https://github.com/pmorie.png"> | Paul Morie | Red Hat | [@pmorie](https://github.com/pmorie) |
|
||||
| <img width="30px" src="https://github.com/rgregg.png"> | Ryan Gregg | Google | [@rgregg](https://github.com/rgregg) |
|
||||
| <img width="30px" src="https://github.com/isdal.png"> | 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).
|
||||
|
|
@ -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) <br>or dial in:<br>(US) +1 240-630-1102 PIN: 316262# |
|
||||
| Community Meeting Calendar | Thursdays at 11:30a-12p <br>[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 |
|
||||
| ------------------------------------------------------------- | ------------- | ------- | -------------------------------------------------- |
|
||||
| <img width="30px" src="https://github.com/evankanderson.png"> | Evan Anderson | Google | [@evankanderson](https://github.com/evankanderson) |
|
||||
| <img width="30px" src="https://github.com/mattmoor.png"> | Matt Moore | Google | [@mattmoor](https://github.com/mattmoor) |
|
||||
| <img width="30px" src="https://github.com/vaikas-google.png"> | 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).
|
||||
|
|
@ -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).
|
||||
|
|
@ -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).
|
||||
|
|
@ -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)
|
||||
<!-- TODO add charters for each group -->
|
||||
|
||||
## 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) <br>Or dial in:<br>(US) +1 262-448-6367<br>PIN: 923 539# |
|
||||
| Community Meeting Calendar | Wednesdays 10:30a-11:00a PST <br>[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 |
|
||||
| -------------------------------------------------------- | ---------- | ------- | --------------------------------------- |
|
||||
| <img width="30px" src="https://github.com/mattmoor.png"> | 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) <br>Or dial in:<br>(US) +1 219-778-6103 PIN: 573 000# |
|
||||
| Community Meeting Calendar | Every other Wednesday 10:00a-10:30a PST <br>[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 |
|
||||
| -------------------------------------------------------- | ---------- | ------- | --------------------------------------- |
|
||||
| <img width="30px" src="https://github.com/ImJasonH.png"> | Jason Hall | Google | [ImJasonH](https://github.com/ImJasonH) |
|
||||
| <img width="30px" src="https://github.com/mattmoor.png"> | 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) <br>Or dial in:<br>(US) +1 929-445-2235<br>PIN: 824 001# |
|
||||
| Community Meeting Calendar | Tuesdays 10:30a-11:00a Pacific <br>[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 |
|
||||
| ---------------------------------------------------------- | --------------- | ------- | ------------------------------------------- |
|
||||
| <img width="30px" src="https://github.com/sixolet.png"> | Naomi Seyfer | Google | [sixolet](https://github.com/sixolet) |
|
||||
| <img width="30px" src="https://github.com/cppforlife.png"> | 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) <br>Or dial in:<br>(US) +1 260-277-0211<br>PIN: 956 724# |
|
||||
| Community Meeting Calendar | Weekly on Tuesdays, alternating between 9:00-9:30am and 4:30-5:00pm PST<br>[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 |
|
||||
| -------------------------------------------------------- | ---------- | ------- | --------------------------------------- |
|
||||
| <img width="30px" src="https://github.com/samodell.png"> | 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) <br>Or dial in:<br>(US) +1 919 525 1825<br>PIN: 356 842# |
|
||||
| Community Meeting Calendar | Wednesdays 9:00a-9:30a PST<br>[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 |
|
||||
| ------------------------------------------------------------- | ----------- | ------- | ------------------------------------------------- |
|
||||
| <img width="30px" src="https://github.com/vaikas-google.png"> | 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) <br>Or dial in:<br>(US) +1 570-865-1288<br>PIN: 741 211# |
|
||||
| Community Meeting Calendar | Thursdays at 9:00a-9:30a PST<br>[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 |
|
||||
| --------------------------------------------------------- | ---------------- | ------- | ----------------------------------------- |
|
||||
| <img width="30px" src="https://github.com/tcnghia.png"> | Nghia Tran | Google | [tcnghia](https://github.com/tcnghia) |
|
||||
| <img width="30px" src="https://github.com/mdemirhan.png"> | 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 <br> Or dial in: <br> (US) +1 413-301-9135 <br>PIN: 602 561# |
|
||||
| Community Meeting Calendar | Every other Thursday, 10:30a-11a PST<br>[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 |
|
||||
| --------------------------------------------------------- | ---------------- | ------- | ----------------------------------------- |
|
||||
| <img width="30px" src="https://github.com/mdemirhan.png"> | 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 <br>[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 |
|
||||
| ------------------------------------------------------------- | -------------- | ------- | ------------------------------------------------- |
|
||||
| <img width="30px" src="https://github.com/josephburnett.png"> | 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<br>[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 |
|
||||
| --------------------------------------------------------- | ------------- | ------- | ----------------------------------------- |
|
||||
| <img width="30px" src="https://github.com/jessiezcc.png"> | Jessie Zhu | Google | [jessiezcc](https://github.com/jessiezcc) |
|
||||
| <img width="30px" src="https://github.com/adrcunha.png"> | 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).
|
||||
Loading…
Reference in New Issue