customize repo template

Author: lavalamp

README.md

@@ -1,16 +1,8 @@
-# Kubernetes Template Project
-
-The Kubernetes Template Project is a template for starting new projects in the GitHub organizations owned by Kubernetes. All Kubernetes projects, at minimum, must have the following files:
-
-- a `README.md` outlining the project goals, sponsoring sig, and community contact information
-- an `OWNERS` with the project leads listed as approvers ([docs on `OWNERS` files][owners])
-- a `CONTRIBUTING.md` outlining how to contribute to the project
-- the `code-of-conduct.md` from this repo, which outlines community behavior and the consequences of breaking the code
-- a `LICENSE` which must be Apache 2.0 for code projects, or Creative Commons 4.0 for documentation repositories
-- a `SECURITY_CONTACTS` with the contact points for the Product Security Team 
-  to reach out to for triaging and handling of incoming issues. They must agree to abide by the
-  [Embargo Policy](https://github.com/kubernetes/sig-release/blob/master/security-release-process-documentation/security-release-process.md#embargo-policy) 
-  and will be removed and replaced if they violate that agreement.
+# Structured Merge and Diff
+
+This repo contains code for implementing the Kubernetes "apply" operation.
+
+It also contains test vectors for testing an implementation of apply.
 
 ## Community, discussion, contribution, and support
 

RELEASE.md

@@ -1,9 +1,24 @@
 # Release Process
 
-The Kubernetes Template Project is released on an as-needed basis. The process is as follows:
+This repo will follow go library versioning semantics.
+
+Currently, it is not stable (version 0.0.0) and interfaces may change without
+warning.
+
+Once it looks like this code will be used in a Kubernetes release, we will mark
+it v1.0.0 and any interface changes will begin accumulating in a v2 candidate.
+
+We will publish versions in a way that's conformant with the new "go modules".
+
+Reviewers / owners are expected to be vigilant about preventing
+interface-breaking changes in stable versions.
+
+When a candidate version is ready to be promoted to stable, the process is as follows:
 
 1. An issue is proposing a new release with a changelog since the last release
 1. All [OWNERS](OWNERS) must LGTM this release
-1. An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION`
+1. An OWNER changes the name from vX-candidate to vX and starts a v(X+1)-candidate directory/module (details TBD when we first do this)
 1. The release issue is closed
 1. An announcement email is sent to `[email protected]` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
+
+(This process is currently intended to be a hint and will be refined once we declare our first stable release.)

SECURITY_CONTACTS

@@ -10,5 +10,4 @@
 # DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE
 # INSTRUCTIONS AT https://kubernetes.io/security/
 
-bob
-alice
+lavalamp