Move use cases to primer, add reference implementations

Include the work on reference implementations, or "adapters" that
will be required to produce / consume cdevents in various platforms.

Relocate the use cases to the primer.md document.

Signed-off-by: Andrea Frittoli <[email protected]>

primer.md

@@ -9,6 +9,7 @@ This non-normative document provides an overview of the CDEvents specification.
 <!-- toc -->
 - [History](#history)
 - [Acknowledgments](#acknowledgments)
+- [Use Cases](#use-cases)
 <!-- /toc -->
 
 ## History
@@ -18,3 +19,23 @@ TBD
 ## Acknowledgments
 
 The initial structure of the CDEvents specification format was based on the specification of the [CloudEvents](https://github.com/cloudevents/spec) project.
+
+## Use Cases
+
+There are two root use cases that we are considering:
+
+- *Interoperability through CDEvents*: In this use case, platforms from the CD landscape either produce
+  or consume CDEvents. On the producing side, a system broadcasts that certain value has been produced,
+  like a code change, an artifact or a test result. On the consumer side, a system takes an action that
+  takes advantage of that value that has been produced.
+
+- *Observability & Metrics*: In this use case, platforms from the CD landscape produce CDEvents that describe
+  the start and end of parts of an end of end CD workflow, for instance build started and finished, artifact
+  packaged and published and deployment started and finished. We want to visualize the end to end CD workflow,
+  for instance from a change being written, through its build, test, release, deployment and possibly rollback
+  in case a remediation is required. To achieve that, events are sent to an event router and collected
+  by a pipeline visualization application, that uses the information in the events to correlate them with each
+  other and build an end to end view. With the same events, we want to measure DevOps performance as well.
+  The same events can be used to track different metrics over time, to be visualized through a dashboard.
+
+The use cases are work in progress - the list is being drafted in a [separate document](https://hackmd.io/ZCS2KYKZTpKBqhU9PMuCew).

roadmap.md

@@ -6,7 +6,7 @@ This document describes the mission of the CDEvents and its overall roadmap for
 
 The mission of CDEvents project is:
 
-> Provide interoperability in the continuous delivery ecosystem through a common events format
+> Provide interoperability in the continuous delivery ecosystem through a common events protocol
 
 The vision for the CDEvents project is to have CDEvents natively produced and consumed by
 as many projects and services as possible in the continuous delivery ecosystem, to provide
@@ -24,28 +24,21 @@ In 2022 we want to focus on a few [key use cases](#use-cases) and make sure that
 them with the protocol specification. More specifically:
 
 - Capture our key use cases and design decisions in the [CDEvents primer](primer.md) document
-- Develop the spec to fully support our [key use cases](#use-cases)
+- Develop the spec to fully support our [key use cases](primer.md#use-cases)
+  - Create our first [release v0.1](https://github.com/orgs/cdevents/projects/1)
+  - Define the specification versioning and stability policy
+  - Define our requirements for a v1.0
 - Validate and demonstrate the spec through proofs-of-concept
-- Specify and rework the CloudEvents binding, re-create the SDK for the `go` language
+- Specify and rework the CloudEvents binding, and develop SDKS:
+  - Re-create the SDK for the `go` language
+  - Create a new SDK for the `python` language
 - Evolve the project bootstrap governance into a full governance
 - Grow the CDEvents community of projects and contributors
 
-## Use Cases
-
-There are two root use cases that we are considering:
-
-- *Interoperability through CDEvents*: In this use case, platforms from the CD landscape either produce
-  or consume CDEvents. On the producing side, a system broadcasts that certain value has been produced,
-  like a code change, an artifact or a test result. On the consumer side, a system takes an action that
-  takes advantage of that value that has been produced.
-
-- *Observability & Metrics*: In this use case, platforms from the CD landscape produce CDEvents that describe
-  the start and end of parts of an end of end CD workflow, for instance build started and finished, artifact
-  packaged and published and deployment started and finished. We want to visualize the end to end CD workflow,
-  for instance from a change being written, through its build, test, release, deployment and possibly rollback
-  in case a remediation is required. To achieve that, events are sent to an event router and collected
-  by a pipeline visualization application, that uses the information in the events to correlate them with each
-  other and build an end to end view. With the same events, we want to measure DevOps performance as well.
-  The same events can be used to track different metrics over time, to be visualized through a dashboard.
-
-The use cases are work in progress - the list is being drafted in a [separate document](https://hackmd.io/ZCS2KYKZTpKBqhU9PMuCew).
+The implementation of proofs of concept will require having CDEvents emitted by various platforms
+which do not support CDEvents yet. Where possible we will work with the community; it is likely we
+will have to develop producers and consumers of CDEvents that can adapt existing event formats into
+CDEvents. We will host such reference implementations in the `cdevents` organization at least until
+they can find a new home in the target project.
+These implementations will be useful to identify the mapping between the data model of a specific
+platform and CDEvents; we can add these mappings to supporting documentation in `cdevents` organization.