Add README and template.

oteps/0000-template.md

@@ -0,0 +1,41 @@
+# Replace this with your awesome OTEP title
+
+Short (one sentence) summary, e.g., something that would be appropriate for a [CHANGELOG](https://keepachangelog.com/) or release notes.
+
+## Motivation
+
+Why should we make this change? What new value would it bring? What use cases does it enable?
+
+## Explanation
+
+Explain the proposed change as though it was already implemented and you were explaining it to a user. Depending on which layer the proposal addresses, the "user" may vary, or there may even be multiple.
+
+We encourage you to use examples, diagrams, or whatever else makes the most sense!
+
+## Internal details
+
+From a technical perspective, how do you propose accomplishing the proposal? In particular, please explain:
+
+* How the change would impact and interact with existing functionality
+* Likely error modes (and how to handle them)
+* Corner cases (and how to handle them)
+
+While you do not need to prescribe a particular implementation - indeed, OTEPs should be about **behaviour**, not implementation! - it may be useful to provide at least one suggestion as to how the proposal *could* be implemented. This helps reassure reviewers that implementation is at least possible, and often helps them inspire them to think more deeply about trade-offs, alternatives, etc.
+
+## Trade-offs and mitigations
+
+What are some (known!) drawbacks? What are some ways that they might be mitigated?
+
+Note that mitigations do not need to be complete *solutions*, and that they do not need to be accomplished directly through your proposal. A suggested mitigation may even warrant its own OTEP!
+
+## Prior art and alternatives
+
+What are some prior and/or alternative approaches? For instance, is there a corresponding feature in OpenTracing or OpenCensus? What are some ideas that you have rejected?
+
+## Open questions
+
+What are some questions that you know aren't resolved yet by the OTEP? These may be questions that could be answered through further discussion, implementation experiments, or anything else that the future may bring.
+
+## Future possibilities
+
+What are some future changes that this proposal would enable?

oteps/README.md

@@ -0,0 +1,88 @@
+# OpenTelemetry Enhancement Proposal (OTEP)
+
+## Evolving OpenTelemetry at the speed of Markdown
+
+OpenTelemetry uses an "OTEP" (similar to a RFC) process for proposing changes to the OpenTelemetry Specification.
+
+### Table of Contents
+
+- [OpenTelemetry Enhancement Proposal (OTEP)](#opentelemetry-enhancement-proposal-otep)
+  - [Evolving OpenTelemetry at the speed of Markdown](#evolving-opentelemetry-at-the-speed-of-markdown)
+    - [Table of Contents](#table-of-contents)
+    - [What changes require an OTEP](#what-changes-require-an-otep)
+      - [Extrapolating cross-cutting changes](#extrapolating-cross-cutting-changes)
+    - [OTEP scope](#otep-scope)
+    - [Writing an OTEP](#writing-an-otep)
+    - [Submitting the OTEP](#submitting-the-otep)
+    - [Integrating the OTEP into the Spec](#integrating-the-otep-into-the-spec)
+    - [Implementing the OTEP](#implementing-the-otep)
+  - [Changes to the OTEP process](#changes-to-the-otep-process)
+  - [Background on the OpenTelemetry OTEP process](#background-on-the-opentelemetry-otep-process)
+
+### What changes require an OTEP
+
+The OpenTelemetry OTEP process is intended for changes that are **cross-cutting** - that is, applicable across *languages* and *implementations* - and either **introduce new behaviour**, **change desired behaviour**, or otherwise **modify requirements**.
+
+In practice, this means that OTEPs should be used for such changes as:
+
+- New tracer configuration options
+- Additions to span data
+- New metric types
+- Modifications to extensibility requirements
+
+On the other hand, they do not need to be used for such changes as:
+
+- Bug fixes
+- Rephrasing, grammatical fixes, typos, etc.
+- Refactoring
+- Things that affect only a single language or implementation
+
+**Note:** The above lists are intended only as examples and are not meant to be exhaustive. If you don't know whether a change requires an OTEP, please feel free to ask!
+
+#### Extrapolating cross-cutting changes
+
+Sometimes, a change that is only immediately relevant within a single language or implementation may be indicative of a problem upstream in the specification. We encourage you to add an OTEP if and when you notice such cases.
+
+### OTEP scope
+
+While OTEPs are intended for "significant" changes, we recommend trying to keep each OTEP's scope as small as makes sense. A general rule of thumb is that if the core functionality proposed could still provide value without a particular piece, then that piece should be removed from the proposal and used instead as an *example* (and, ideally, given its own OTEP!).
+
+For example, an OTEP proposing configurable sampling *and* various samplers should instead be split into one OTEP proposing configurable sampling as well as an OTEP per sampler.
+
+### Writing an OTEP
+
+- First, [fork](https://help.github.com/en/articles/fork-a-repo) this repo.
+- Copy [`0000-template.md`](./0000-template.md) to `0000-my-OTEP.md`, where `my-OTEP` is a title relevant to your proposal, and `0000` is the OTEP ID.
+- Fill in the template. Put care into the details: It is important to present convincing motivation, demonstrate an understanding of the design's impact, and honestly assess the drawbacks and potential alternatives.
+
+### Submitting the OTEP
+
+- An OTEP is `proposed` by posting it as a PR.
+- An OTEP is `approved` when four reviewers github-approve the PR. The OTEP is then merged.
+- If an OTEP is `rejected` or `withdrawn`, the PR is closed. Note that these OTEPs submissions are still recorded, as GitHub retains both the discussion and the proposal, even if the branch is later deleted.
+- If an OTEP discussion becomes long, and the OTEP then goes through a major revision, the next version of the OTEP can be posted as a new PR, which references the old PR. The old PR is then closed. This makes OTEP review easier to follow and participate in.
+
+### Integrating the OTEP into the Spec
+
+- Once an OTEP is `approved`, an issue is created in this repo to integrate the OTEP into the actual spec.
+- When reviewing the spec PR for the OTEP, focus on whether the spec is written clearly, and reflects the changes approved in the OTEP. Please abstain from relitigating the approved OTEP changes at this stage.
+- An OTEP is `integrated` when four reviewers github-approve the spec PR. The PR is then merged, and the spec is versioned.
+
+### Implementing the OTEP
+
+- Once an OTEP is `integrated` into the spec, an issue is created in the backlog of every relevant OpenTelemetry implementation.
+- PRs are made until the all the requested changes are implemented.
+- The status of the OpenTelemetry implementation is updated to reflect that it is implementing a new version of the spec.
+
+## Changes to the OTEP process
+
+The hope and expectation is that the OTEP process will **evolve** with the OpenTelemetry. The process is by no means fixed.
+
+Have suggestions? Concerns? Questions? **Please** raise an issue or raise the matter on our [community](https://github.com/open-telemetry/community) chat.
+
+## Background on the OpenTelemetry OTEP process
+
+Our OTEP process borrows from the [Rust RFC](https://github.com/rust-lang/rfcs) and [Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements) processes, the former also being [very influential](https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/0000-kep-process#prior-art) on the latter; as well as the [OpenTracing OTEP](https://github.com/opentracing/specification/tree/master/rfc_process.md) process. Massive kudos and thanks to the respective authors and communities for providing excellent prior art 💖
+
+[slack-image]: https://img.shields.io/badge/Slack-4A154B?style=for-the-badge&logo=slack&logoColor=white
+[slack-url]: https://cloud-native.slack.com/archives/C01N7PP1THC