update readme after move to containerd

Signed-off-by: Mike Brown <[email protected]>

CONTRIBUTING.md

@@ -1,28 +1,118 @@
-# Contributing guidelines
+# Contributing
 
-## How to become a contributor and submit your own code
+Contributions should be made via pull requests. Pull requests will be reviewed
+by one or more maintainers and merged when acceptable.
 
-### Contributor License Agreements
+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.
 
-We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles.
+## Successful Changes
 
-Please fill out either the individual or corporate Contributor License Agreement (CLA).
+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.
 
-  * If you are an individual writing original source code and you're sure you own the intellectual property, then you'll need to sign an [individual CLA](https://identity.linuxfoundation.org/node/285/node/285/individual-signup).
-  * If you work for a company that wants to allow you to contribute your work, then you'll need to sign a [corporate CLA](https://identity.linuxfoundation.org/node/285/organization-signup).
+PRs that are just submitted without any prior communication will likely be
+summarily closed.
 
-Follow either of the two links above to access the appropriate CLA and instructions for how to sign and return it. Once we receive it, we'll be able to accept your pull requests.
+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.
 
-### Contributing A Patch
+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.
 
-1. Submit an issue describing your proposed change to the repo in question.
-1. The [repo owners](OWNERS) will respond to your issue promptly.
-1. If your proposed change is accepted, and you haven't already done so, sign a Contributor License Agreement (see details above).
-1. Fork the desired repo, develop and test your code changes.
-1. Submit a pull request.
+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.
 
-### Adding dependencies
+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.
 
-If your patch depends on new packages, add that package with [`vndr`](https://github.com/LK4D4/vndr). Please
-modify `vendor.conf` and run the `vndr` tool to update the `vendor/` directory. After that, please run
-`hack/update-vendor.sh` script to update the contents of `hack/versions`.
+## 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 <[email protected]>
+
+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`.

README.md

@@ -88,7 +88,7 @@ make BUILD_TAGS='seccomp apparmor'
 | selinux   | selinux process and mount labeling | <none>                          |
 | apparmor  | apparmor profile support           | libapparmor development library |
 ### Validate Your cri-containerd Setup
-Another Kubernetes incubator project called [cri-tools](https://github.com/kubernetes-incubator/cri-tools)
+A Kubernetes incubator project called [cri-tools](https://github.com/kubernetes-incubator/cri-tools)
 includes programs for exercising CRI implementations such as `cri-containerd`.
 More importantly, cri-tools includes the program `critest` which is used for running
 [CRI Validation Testing](https://github.com/kubernetes/community/blob/master/contributors/devel/cri-validation.md).
@@ -98,8 +98,8 @@ Run the CRI Validation test to validate your installation of `cri-containerd`:
 make test-cri
 ```
 ### Running a Kubernetes local cluster
-If you already have a working development environment for supported Kubernetes version, you can
-try `cri-containerd` in a local cluster:
+If you already have a working development environment for supported Kubernetes
+version, you can try `cri-containerd` in a local cluster:
 
 1. Start `containerd` as root in a first terminal:
 ```bash
@@ -123,17 +123,40 @@ See [here](./docs) for additional documentation.
 ## Contributing
 Interested in contributing? Check out the [documentation](./CONTRIBUTING.md).
 
-## Kubernetes Incubator
-This is a [Kubernetes Incubator project](https://github.com/kubernetes/community/blob/master/incubator.md).
-The project was established 2017/4/13. The incubator team for the project is:
-* Sponsor: Dawn Chen ([@dchen1107](https://github.com/dchen1107))
-* Champion: Yuju Hong ([@yujuhong](https://github.com/yujuhong))
-* SIG: `sig-node`
+## 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 more information about `sig-node` and the `cri-containerd` project:
+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.
+
+For sync communication we have a community slack with a #containerd channel that
+everyone is welcome to join and chat about development.
+
+**Slack:** https://dockr.ly/community
+
+## Other Communications
+As this project is tightly coupled to CRI and CRI-Tools and they are Kubernetes
+projects, some of our project communications take place in the Kubernetes' SIG:
+`sig-node.`
+
+For more information about `sig-node`, `CRI`, and the `CRI-Tools` projects:
 * [sig-node community site](https://github.com/kubernetes/community/tree/master/sig-node)
 * Slack: `#sig-node` channel in Kubernetes (kubernetes.slack.com)
 * Mailing List: https://groups.google.com/forum/#!forum/kubernetes-sig-node
+
+### Reporting Security Issues
+
+__If you are reporting a security issue, please reach out discreetly at [email protected]__.
+
+## Licenses
+The containerd codebase is released under the [Apache 2.0 license](https://github.com/containerd/containerd/blob/master/LICENSE.code).
+The README.md file, and files in the "docs" folder are licensed under the
+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
-Participation in the Kubernetes community is governed by the
-[Kubernetes Code of Conduct](./code-of-conduct.md).
+This project follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).

code-of-conduct.md

@@ -1,3 +1,3 @@
-# Kubernetes Community Code of Conduct
+# Code of Conduct
 
-Please refer to our [Kubernetes Community Code of Conduct](https://git.k8s.io/community/code-of-conduct.md)
+This project follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).