Update OAM with CNCF guidelines

Author: resouer

CONTRIBUTING.md

@@ -1,21 +1,12 @@
 # Contributing
 
-## Proposing Changes and LGTM Policy
-
-To propose a change or ask a question, please open an issue in the issue queue before submitting a pull request (PR). All PRs must be reviewed and approved (LGTMed) by 2 maintainers before being merged. Maintainers are specified in the [OWNERS](OWNERS.md) file. Refer to to the contribution guidelines in this document for more details on the process for issues and PRs.
-
-## CLA Requirement
-
-This project welcomes contributions and suggestions. All contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant the community the rights to use your contribution. 
+## Introduction
 
-## Specification subject to the Open Web Foundation Agreements
+The developing of Open Application Model is driven by KubeVela, in most cases, you should use KubeVela repository for contribution. This repository mainly accepts issues and PRs for API specification release planning and maintenance purposes.
 
-In addition, by making a contribution to specifications in this repository, you, on behalf of yourself, your employer, and its affiliates, are making those contributions subject to the obligations set forth in the [OWF Contributor License Agreement 1.0 - Copyright and Patent](http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owf-contributor-license-agreement-1-0---copyright-and-patent).  
-Final specifications developed in this repository will be subject to the [Open Web Foundation Final Specification Agreement (“OWFa 1.0”)](http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0).  OWFa 1.0 will be applied as follows:
+## Proposing Changes and LGTM Policy
 
--	The maintainer will notify all contributors to a designated specification in writing via provided contact information of the start of a 30 day review period, after which the specification will be subject to the OWFa 1.0.
--	During that 30 day period, contributors may provide written notice to the maintainer that the contributor is not making the forgoing commitment under OWFa 1.0 for the designated specification (“Exclusion”).
--	Upon the end of that 30 day notice period, those contributors who have not issued an Exclusion, on behalf of themselves, their employer, and its affiliates, will, without further action, be subject to the obligations set forth in the OWFa 1.0 for the designated specification.
+To propose a change or ask a question, please open an issue in the issue queue before submitting a pull request (PR). All PRs must be reviewed and approved (LGTMed) by 2 maintainers before being merged. Maintainers are specified in the [OWNERS](OWNERS.md) file. Refer to to the contribution guidelines in this document for more details on the process for issues and PRs.
 
 ## Code of Conduct
 
@@ -24,30 +15,15 @@ Please maintain respectful communication in the issue queue, PR queue, and all o
 
 ## Contribution guidelines
 
-The Open Application Model specification project accepts contributions via GitHub pull requests. The following section outlines the process for merging contributions to the spec.
+This repository accepts contributions via GitHub pull requests. The following section outlines the process for merging contributions to the spec.
 
 ### Issues
 
-Issues are used as the primary method for tracking anything to do with the Open Application Model specification project.
-
-#### Issue Types
-
-There are three types of issues (each with their own corresponding [label](#labels)):
-
-- **Discussion**: These are support or functionality inquiries that we want to have a record of for
-future reference. Depending on the discussion, these can turn into "Spec Change" issues.
-- **Proposal**: Used for items that propose a new ideas or functionality that require
-a larger discussion. This allows for feedback from others before a
-spec change is actually written. All issues that are proposals should
-both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become
-a "Spec Change" and does not require a milestone.
-- **Spec Change**: These track specific spec changes and ideas until they are complete. They can evolve
-from "Proposal" and "Discussion" items, or can be submitted individually depending on the size. Each spec change should be placed into a milestone.
+Issues are used as the primary method for tracking anything to do with the Open Application Model project.
 
 #### Issue Lifecycle
 
-The issue lifecycle is mainly driven by the core maintainers, but is good information for those
-contributing to the Open Application Model specification. All issue types follow the same general lifecycle. Differences are noted below.
+All issue types follow the same general lifecycle. Differences are noted below.
 
 1. Issue creation
 2. Triage
@@ -65,9 +41,9 @@ contributing to the Open Application Model specification. All issue types follow
 
 ### How to Contribute a Patch
 
-Like any good open source project, we use Pull Requests (PRs) to track code changes. To submit a change to the specification:
+We use Pull Requests (PRs) to track code changes. To submit a change to the project:
 
-1. Fork the repo, modify the specification to address the issue.
+1. Fork the repo, modify the project to address the issue.
 2. Pick an open issue from the [issue list](https://github.com/oam-dev/spec/issues) and claim it in the comments. After approval fix the issue and send us a pull request (PR).
 3. Or you can create a new issue. A community member will get back to you and, if approved, you can fix the issue and send a pull request.
 4. Please go through our issue list first (open as well as closed) and make sure the issue you are reporting does not replicate an issue already reported. If you have issues on multiple pages, report them separately. Do not combine them into a single issue.

OWNERS.md

@@ -1,5 +1,9 @@
 # Owners
 
+## Introduction
+
+Maintainers of Open Application Model will be inherited directly in KubeVela project as KubeVela API maintainers.
+
 ## Maintainers
 
 This section lists all active maintainers:

README.md

@@ -1,11 +1,11 @@
-# Open Application Model Specification
+# Open Application Model
 
 [![Gitter](https://badges.gitter.im/oam-dev/community.svg)](https://gitter.im/oam-devcommunity?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
 [![License: MIT](https://img.shields.io/badge/License-OWF-yellow)](https://github.com/oam-dev/spec/blob/master/LICENSE)
 [![TODOs](https://badgen.net/https/api.tickgit.com/badgen/github.com/oam-dev/spec)](https://www.tickgit.com/browse?repo=github.com/oam-dev/spec)
 [![Follow on Twitter](https://img.shields.io/twitter/follow/oam_dev.svg?style=social&logo=twitter)](https://twitter.com/intent/follow?screen_name=oam_dev)
 
-Open Application Model (OAM) is a runtime-agnostic specification for defining cloud native applications.
+Open Application Model (OAM) is a runtime-agnostic model for defining cloud native applications.
 
 Focused on **application** rather than container or orchestrator, Open Application Model brings modular, extensible, and portable design for modeling application deployment with consistent higher level API. This is the key to enable simple yet robust application delivery workflow across hybrid environments including Kubernetes, cloud, or even IoT devices.
 
@@ -15,6 +15,8 @@ _"Developers think in terms of application architecture, not of infrastructure."
 
 ![How it works](assets/how-it-works.png)
 
+Open Application Model is essentially the theoretical model behind [KubeVela](https://github.com/oam-dev/kubevela) project - a modern application deployment platform that makes delivering and managing applications across today's hybrid, multi-cloud environments easier and faster. 
+
 ### Why Open Application Model?
 
 Managing applications without application context is hard:
@@ -29,21 +31,22 @@ In Open Application Model, we propose an app-centric approach instead:
 - Clarity and extensibility - an open standard to modularize infrastructure capabilities into reusable pieces that adapts to your needs, not the other way around.
 - Runtime agnostic - a consistent experience to deploy and operate your apps across on-prem clusters, cloud providers or even edge devices.
 
-## Read the specification
+## Learn the model
+
+The developing and releasing of Open Application Model are all driven by KubeVela. Though the model itself is maintained as a set of API specifications in this repository. This enables some user cases where Kubernetes as control plane (required by KubeVela) is impossible but still want to adopt OAM.
 
 |                                | Previous Releases | Latest Release |    Working Draft                  |
 | :----------------------------: | :-----------------: | :------------: |:--------------------------------: |
-| OAM Specification              | [v0.1.0](https://github.com/oam-dev/spec/releases/tag/v0.1.0), [v0.2.1](https://github.com/oam-dev/spec/releases/tag/v0.2.1) | [v0.3.0](SPEC.md) |  --  |
+| OAM releases              | [v0.2.1](https://github.com/oam-dev/spec/releases/tag/v0.2.1) | [v0.3.0](SPEC.md) |  --  |
+| KubeVela releases              | v0.3.x |v1.x |  --  |
 
-## See it in action
+For [v0.1.0](https://github.com/oam-dev/spec/releases/tag/v0.1.0) release of OAM, it is an experimental version only supported in [Rudr](https://github.com/oam-dev/rudr) and now archived.
 
-For latest releases (recommend):
-- [KubeVela](https://github.com/oam-dev/kubevela): the modern application deployment system based on OAM, with Kubernetes as control plane.
+## Community
 
-For `v0.1.x` releases:
-- [Rudr](https://github.com/oam-dev/rudr): the reference implementation of OAM on Kubernetes.
+### Copyrights
 
-## Community
+The Open Application Model and KubeVela projects are hosted in [Cloud Native Computing Foundation (CNCF)](https://cncf.io). All copyrights belong to CNCF.
 
 ### Milestones
 
@@ -66,4 +69,3 @@ One of the easiest ways to contribute is to participate in discussions. There ar
 | Bi-weekly APAC Friendly Meeting (Chinese)| [Zoom](https://us02web.zoom.us/j/2804785490?pwd=ZTN4ZU03UTlBZzlmVHIwTndINGM3UT09), [Meeting Notes](https://shimo.im/docs/w8CgdyYGWjtYJ3XP), [Records (BiliBili)](https://space.bilibili.com/180074935?spm_id_from=333.788.b_765f7570696e666f.2) |
 | IM Channel      | https://gitter.im/oam-dev/ |
 | Twitter      | [@oam_dev](https://twitter.com/oam_dev) |
-

code-of-conduct.md

@@ -1,77 +1,3 @@
-# Open Application Model Code of Conduct
-
-## Our Pledge
-
-In the interest of fostering an open and welcoming environment, we as
-contributors and maintainers pledge to make participation in our project and
-our community a harassment-free experience for everyone, regardless of age, body
-size, disability, ethnicity, sex characteristics, 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
-
-Project maintainers 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.
-
-Project maintainers 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 within all project spaces, and it also applies when
-an individual is representing the project or its community in public spaces.
-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 project team [TBD]. 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.
-
-Project maintainers 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
-
-For answers to common questions about this code of conduct, see
-https://www.contributor-covenant.org/faq
+# Code of Conduct
 
+Open Application Model follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).