diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md deleted file mode 100644 index a6f2458e55fd..000000000000 --- a/CONTRIBUTING.md +++ /dev/null @@ -1,118 +0,0 @@ -# Contributing - -Contributions should be made via pull requests. Pull requests will be reviewed -by one or more maintainers and merged when acceptable. - -This project is in an early state, making the impact of contributions much -greater than at other stages. In this respect, it is important to consider any -changes or additions for their future impact more so than their current impact. - -## Successful Changes - -We ask that before contributing, please make the effort to coordinate with the -maintainers of the project before submitting large or high impact PRs. This -will prevent you from doing extra work that may or may not be merged. - -PRs that are just submitted without any prior communication will likely be -summarily closed. - -While pull requests are the methodology for submitting changes to code, changes -are much more likely to be accepted if they are accompanied by additional -engineering work. While we don't define this explicitly, most of these goals -are accomplished through communication of the design goals and subsequent -solutions. Often times, it helps to first state the problem before presenting -solutions. - -Typically, the best methods of accomplishing this are to submit an issue, -stating the problem. This issue can include a problem statement and a -checklist with requirements. If solutions are proposed, alternatives should be -listed and eliminated. Even if the criteria for elimination of a solution is -frivolous, say so. - -Larger changes typically work best with design documents, similar to those found -in `design/`. These are focused on providing context to the design at the time -the feature was conceived and can inform future documentation contributions. - -Make sure that new tests are added for bugs in order to catch regressions and tests -with new features to exercise the new functionality that is added. - -## Commit Messages - -There are times for one line commit messages and this is not one of them. -Commit messages should follow best practices, including explaining the context -of the problem and how it was solved, including in caveats or follow up changes -required. They should tell the story of the change and provide readers -understanding of what led to it. - -If you're lost about what this even means, please see [How to Write a Git -Commit Message](http://chris.beams.io/posts/git-commit/) for a start. - -In practice, the best approach to maintaining a nice commit message is to -leverage a `git add -p` and `git commit --amend` to formulate a solid -changeset. This allows one to piece together a change, as information becomes -available. - -If you squash a series of commits, don't just submit that. Re-write the commit -message, as if the series of commits was a single stroke of brilliance. - -That said, there is no requirement to have a single commit for a PR, as long as -each commit tells the story. For example, if there is a feature that requires a -package, it might make sense to have the package in a separate commit then have -a subsequent commit that uses it. - -Remember, you're telling part of the story with the commit message. Don't make -your chapter weird. - -## Sign your work - -The sign-off is a simple line at the end of the explanation for the patch. Your -signature certifies that you wrote the patch or otherwise have the right to pass -it on as an open-source patch. The rules are pretty simple: if you can certify -the below (from [developercertificate.org](http://developercertificate.org/)): - -``` -Developer Certificate of Origin -Version 1.1 - -Copyright (C) 2004, 2006 The Linux Foundation and its contributors. -660 York Street, Suite 102, -San Francisco, CA 94110 USA - -Everyone is permitted to copy and distribute verbatim copies of this -license document, but changing it is not allowed. - -Developer's Certificate of Origin 1.1 - -By making a contribution to this project, I certify that: - -(a) The contribution was created in whole or in part by me and I - have the right to submit it under the open source license - indicated in the file; or - -(b) The contribution is based upon previous work that, to the best - of my knowledge, is covered under an appropriate open source - license and I have the right under that license to submit that - work with modifications, whether created in whole or in part - by me, under the same open source license (unless I am - permitted to submit under a different license), as indicated - in the file; or - -(c) The contribution was provided directly to me by some other - person who certified (a), (b) or (c) and I have not modified - it. - -(d) I understand and agree that this project and the contribution - are public and that a record of the contribution (including all - personal information I submit with it, including my sign-off) is - maintained indefinitely and may be redistributed consistent with - this project or the open source license(s) involved. -``` - -Then you just add a line to every git commit message: - - Signed-off-by: Joe Smith - -Use your real name (sorry, no pseudonyms or anonymous contributions.) - -If you set your `user.name` and `user.email` git configs, you can sign your -commit automatically with `git commit -s`. diff --git a/OWNERS b/OWNERS index a59152dbee41..7e07404199da 100644 --- a/OWNERS +++ b/OWNERS @@ -1,3 +1,8 @@ +# cri approvers and reviewers +# +# As a containerd sub-project, containerd maintainers are also included from https://github.com/containerd/project/blob/master/MAINTAINERS. +# See https://github.com/containerd/project/blob/master/GOVERNANCE.md for description of maintainer role +# approvers: - Random-Liu - mikebrow diff --git a/README.md b/README.md index b663d6b2f6b7..144c6833bd5b 100644 --- a/README.md +++ b/README.md @@ -145,14 +145,7 @@ and [here](https://github.com/containerd/containerd/blob/master/docs/man/contain for information about how to configure containerd ## Documentation See [here](./docs) for additional documentation. -## Contributing -Interested in contributing? Check out the [documentation](./CONTRIBUTING.md). - ## Communication -This project was originally established in April of 2017 in the Kubernetes -Incubator program. After reaching the Beta stage, In January of 2018, the -project was merged into [containerd](https://github.com/containerd/containerd). - For async communication and long running discussions please use issues and pull requests on this github repo. This will be the best place to discuss design and implementation. @@ -184,5 +177,13 @@ Creative Commons Attribution 4.0 International License under the terms and conditions set forth in the file "[LICENSE.docs](https://github.com/containerd/containerd/blob/master/LICENSE.docs)". You may obtain a duplicate copy of the same license, titled CC-BY-4.0, at http://creativecommons.org/licenses/by/4.0/. -## Code of Conduct -This project follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). +## Project details +cri is a containerd sub-project. This project was originally established in +April of 2017 in the Kubernetes Incubator program. After reaching the Beta +stage, In January of 2018, the project was merged into [containerd](https://github.com/containerd/containerd). +As a containerd sub-project, you will find the: +* [Project governance](https://github.com/containerd/project/blob/master/GOVERNANCE.md), +* [Maintainers](https://github.com/containerd/project/blob/master/MAINTAINERS), +* and [Contributing guidelines](https://github.com/containerd/project/blob/master/CONTRIBUTING.md) + +information in our [`containerd/project`](https://github.com/containerd/project) repository.