knative
/
docs
mirror of https://github.com/knative/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add knative-users as as access option for Team Drive

This commit is contained in:
Evan Anderson 2018-08-03 10:57:27 -07:00
parent 9a2769acd5
commit 264f9b3f47
3 changed files with 123 additions and 105 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

215
community/CONTRIBUTING.md
View File

@ -4,30 +4,30 @@ So, you want to hack on Knative? Yay!
The following sections outline the process all changes to the Knative The following sections outline the process all changes to the Knative
repositories go through. All changes, regardless of whether they are from 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 newcomers to the community or from the core team follow the same process and are
are given the same level of review. given the same level of review.
* [Working groups](#working-groups) - [Working groups](#working-groups)
* [Code of conduct](#code-of-conduct) - [Code of conduct](#code-of-conduct)
* [Team values](#team-values) - [Team values](#team-values)
* [Contributor license agreements](#contributor-license-agreements) - [Contributor license agreements](#contributor-license-agreements)
* [Design documents](#design-documents) - [Design documents](#design-documents)
* [Contributing a feature](#contributing-a-feature) - [Contributing a feature](#contributing-a-feature)
* [Setting up to contribute to Knative](#setting-up-to-contribute-to-knative) - [Setting up to contribute to Knative](#setting-up-to-contribute-to-knative)
* [Pull requests](#pull-requests) - [Pull requests](#pull-requests)
* [Issues](#issues) - [Issues](#issues)
## Working groups ## Working groups
The Knative community is organized into a set of [working The Knative community is organized into a set of
groups](WORKING-GROUPS.md). Any contribution to Knative should be started by [working groups](WORKING-GROUPS.md). Any contribution to Knative should be
first engaging with the appropriate working group. started by first engaging with the appropriate working group.
## Code of conduct ## Code of conduct
All members of the Knative community must abide by the [Code of All members of the Knative community must abide by the
Conduct](CODE-OF-CONDUCT.md). Only by respecting each other can we develop a [Code of Conduct](CODE-OF-CONDUCT.md). Only by respecting each other can we
productive, collaborative community. develop a productive, collaborative community.
## Team values ## Team values
@ -47,64 +47,68 @@ permission to use and redistribute your contributions as part of the project.
## Design documents ## Design documents
Any substantial design deserves a design document. Design documents are Any substantial design deserves a design document. Design documents are written
written with Google Docs and should be shared with the community by adding with Google Docs and should be shared with the community by adding the doc to
the doc to our our
[Team Drive](https://drive.google.com/corp/drive/folders/0APnJ_hRs30R2Uk9PVA) [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 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 people know the doc is there. To get write access to the drive, you'll need to
to be a [member](ROLES.md#member) of the Knative organization. be a [member](ROLES.md#member) of the Knative organization.
We do not yet have a common design document template(TODO). We do not yet have a common design document template(TODO).
The team drive is shared with the 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 [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) Google
group for editing and commenting. If you're not part of that group, the groups for reading and editing, respectively. Access to
first time you try to access the team drive or a specific doc, you'll be [knative-users@](https://groups.google.com/forum/#!forum/knative-users) is
asked to request permission. This permission will always be granted and we unlimited, while
do our best to grant access as fast as we can, but there is a human involved [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) requires
there, so please forgive any delays. 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 a feature ## Contributing a feature
In order to contribute a feature to Knative you'll need to go through the In order to contribute a feature to Knative you'll need to go through the
following steps: following steps:
* Discuss your idea with the appropriate [working groups](WORKING-GROUPS.md) - Discuss your idea with the appropriate [working groups](WORKING-GROUPS.md) on
on the working group's mailing list. the working group's mailing list.
* Once there is general agreement that the feature is useful, [create a GitHub - Once there is general agreement that the feature is useful,
issue](https://github.com/knative/docs/issues/new) to track the discussion. [create a GitHub issue](https://github.com/knative/docs/issues/new) to track
The issue should include information about the requirements and use cases the discussion. The issue should include information about the requirements
that it is trying to address. Include a discussion of the proposed design and use cases that it is trying to address. Include a discussion of the
and technical details of the implementation in the issue. proposed design and technical details of the implementation in the issue.
* If the feature is substantial enough: - If the feature is substantial enough:
* Working group leads will ask for a design document as outlined in - Working group leads will ask for a design document as outlined in
[design documents](#design-documents). Create the design document and [design documents](#design-documents). Create the design document and add a
add a link to it in the GitHub issue. Don't forget to send a note to the link to it in the GitHub issue. Don't forget to send a note to the working
working group to let everyone know your document is ready for review. group to let everyone know your document is ready for review.
* Depending on the breadth of the design and how contentious it is, the - 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 working group leads may decide the feature needs to be discussed in one or
or more working group meetings before being approved. more working group meetings before being approved.
* Once the major technical issues are resolved and agreed upon, post a - Once the major technical issues are resolved and agreed upon, post a note
note with the design decision and the general execution plan to the with the design decision and the general execution plan to the working
working group's mailing list and on the feature's issue. group's mailing list and on the feature's issue.
* Submit PRs to [knative/serving](https://github.com/knative/serving/pulls) - Submit PRs to [knative/serving](https://github.com/knative/serving/pulls) with
with your code changes. your code changes.
* Submit PRs to knative/serving with user documentation for your feature, - Submit PRs to knative/serving with user documentation for your feature,
including usage examples when possible. Add documentation to including usage examples when possible. Add documentation to
[knative/docs/serving](https://github.com/knative/docs/tree/master/serving). [knative/docs/serving](https://github.com/knative/docs/tree/master/serving).
<!-- TODO: switch to knative/serving.dev) --> <!-- TODO: switch to knative/serving.dev) -->
*Note that we prefer bite-sized PRs instead of giant monster PRs. It's therefore _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 preferable if you can introduce large features in small, individually-reviewable
PRs that build on top of one another.* PRs that build on top of one another._
If you would like to skip the process of submitting an issue and instead would 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 prefer to just submit a pull request with your desired code changes then that's
@ -117,8 +121,8 @@ so the choice is up to you.
Check out this Check out this
[README](https://github.com/knative/serving/blob/master/README.md) to learn [README](https://github.com/knative/serving/blob/master/README.md) to learn
about the Knative source base and setting up your [development about the Knative source base and setting up your
environment](https://github.com/knative/serving/blob/master/DEVELOPMENT.md). [development environment](https://github.com/knative/serving/blob/master/DEVELOPMENT.md).
## Pull requests ## Pull requests
@ -128,14 +132,14 @@ active, and hopefully prevents duplicated efforts.
To submit a proposed change: To submit a proposed change:
* Fork the affected repository. - Fork the affected repository.
* Create a new branch for your changes. - Create a new branch for your changes.
* Develop the code/fix. - Develop the code/fix.
* Add new test cases. In the case of a bug fix, the tests should fail without - 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 your code changes. For new features try to cover as many variants as
reasonably possible. reasonably possible.
* Modify the documentation as necessary. - Modify the documentation as necessary.
* Verify all CI status checks pass, and work to make them pass if failing. - 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 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 include all test cases and documentation changes related to the change. A
@ -143,14 +147,17 @@ 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 `[WIP]` prefix in the PR title. WIP PRs should not be merged as long as they are
marked WIP. marked WIP.
When ready, if you have not already done so, sign a [contributor license When ready, if you have not already done so, sign a
agreement](#contributor-license-agreements) and submit the PR. [contributor license agreement](#contributor-license-agreements) and submit the
PR.
This project uses [Prow](https://github.com/kubernetes/test-infra/tree/master/prow) This project uses
to assign reviewers to the PR, set labels, run tests automatically, and so forth. [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 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). merge process used for Knative and for more information about
[Prow](./REVIEWING.md#prow).
## Issues ## Issues
@ -158,47 +165,55 @@ GitHub issues can be used to report bugs or submit feature requests.
When reporting a bug please include the following key pieces of information: 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) - The version of the project you were using (version number, git commit, etc)
* Operating system you are using - Operating system you are using
* The exact, minimal, steps needed to reproduce the issue. Submitting a 5 line - 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 script will get a much faster response from the team than one that's hundreds
hundreds of lines long. of lines long.
## Third-party code ## 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/`: - All third-party code must be placed in `vendor/` or `third_party/` folders.
* Open source, free software, or commercially-licensed code. - `vendor/` folder is managed by [dep](https://github.com/golang/dep) and stores
* Tools or libraries or protocols that are open source, free software, or commercially licensed. the source code of third-party Go dependencies. `vendor/` folder should not be
* Derivative works of third-party code. modified manually.
* Excerpts from third-party code. - 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 ### 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 - Create a sub-folder under `third_party/` for each component.
license text for the dependency. If one doesn't exist then create it. More details on this below. - In each sub-folder, make sure there is a file called LICENSE which contains
* Check in a pristine copy of the code with LICENSE and METADATA files. the appropriate license text for the dependency. If one doesn't exist then
You do not have to include unused files, and you can move or rename files if necessary, create it. More details on this below.
but do not modify the contents of any files yet. - Check in a pristine copy of the code with LICENSE and METADATA files. You do
* Once the pristine copy is merged into master, you may modify the code. 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 ### 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 The license for the code must be in a file named LICENSE. If it was distributed
field of the METADATA file. 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.
If there are multiple licenses for the code, put the text of all the licenses into LICENSE You may optionally document the generation of the LICENSE file in the
along with separators and comments as to the applications. 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.
--- ---

6
community/ROLES.md
View File

@ -34,7 +34,7 @@ table describes:
<tr> <tr>
<td>Collaborator</td> <td>Collaborator</td>
<td>Casual contributor to the project</td> <td>Casual contributor to the project</td>
<td>n/a</td> <td>Join [knative-users@](https://groups.google.com/forum/#!forum/knative-users) to get access to the team drive.</td>
<td> <td>
<p>Can submit PRs</p> <p>Can submit PRs</p>
<p>Commenting permission on the Knative Team drive</p> <p>Commenting permission on the Knative Team drive</p>
@ -115,7 +115,9 @@ the PR bot.
* Working on some contribution to the project that would benefit from the * Working on some contribution to the project that would benefit from the
ability to have PRs or Issues to be assigned to the contributor ability to have PRs or Issues to be assigned to the contributor
* Sponsored by 1 member * Join [knative-users@](https://groups.google.com/forum/#!forum/knative-users)
unrestricted join permissions; this grants read access to documents in the
Team Drive
## Member ## Member

7
community/WORKING-GROUPS.md
View File

@ -13,9 +13,10 @@ procedures.
The working groups generate design docs which are kept in a The working groups generate design docs which are kept in a
[shared drive](https://drive.google.com/corp/drive/folders/0APnJ_hRs30R2Uk9PVA) [shared drive](https://drive.google.com/corp/drive/folders/0APnJ_hRs30R2Uk9PVA)
and are available for anyone to read and comment on. The shared drive and are available for anyone to read and comment on. The shared drive
currently grants edit and comment access to the currently grants read access to
[knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) [knative-users@](https://groups.google.com/forum/#!forum/knative-users) and edit
Google group. and comment access to the
[knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) Google group.
The current working groups are: The current working groups are: