# On the Creation of a GA / Conformance Task Force

## Background
In the past few months, Knative has been chasing “1.0” and “Conformance,” in many conversations these terms are used as synonyms, or at the very least are said in the same breath. It seems many folks are holding context for these efforts (in their brains), and this brief document is a reflection of “the world as we see it,” (we being Naina S. and Omer B.) as well as what ought to be done to get us to where we need to go.

:::success
First off, a thank you to the TOC, Steering, and TM Committee for their work aligning the disparate and varying interests in relation to 1.0 and Conformance ([crystalized in this document](https://docs.google.com/document/d/1mC_nDpLIycqiBn5Om1tvbcY3yyAR3WUNXcHiyloEzhg/edit)). More specifically, a big thank you to Evan Anderson who has done some excellent work organizing the results of these efforts into a [cohesive spreadsheet](https://docs.google.com/spreadsheets/d/1dH4c3_2bZUQn6nz09Hmn5VLcVNUV1ZocCEAN76jYjas/edit#gid=0).

:::

## Defining Conformance, Defining an Audience
I want to take a quick second to loosely define Conformance as it relates to Knative. Conformance is the process of validating that a given environment implements the [Knative Serving or Eventing interfaces](https://github.com/knative/specs/). That is to say, a Conformant Platform would be one in which some code which is built to align with the Knative Specification (spec, for short) can run without issues. In other words, this means creating a series of tests that will ensure that Platform runs as per the provided Knative specification with varying levels of Conformance. MUST, SHOULD, SHOULD NOT, etc. e.g. "the platform MUST allow you to spin up a Knative Service (KSVC) with a standard manifest and SHOULD give you some abilities on top of that KSVC".

_Evan proposed alternate text:_
> **Why have conformance at all?**
> Conformance provides a mechanism which allows the Knative trademark to be used by multiple vendors to promise a certain degree of compatibility across different implementations. _Vendors_ (companies that sell Knative as a service or as installed software) benefit from being able to use the trademark in their marketing material. _Consumers_ (people who consume Knative by purchasing from a vendor) benefit by having a consistent definition and mark of quality, as well as a catalogue of vendors. _Contributors_ (members of the community) benefit from increased visibility of the open-source project.
> In the short term, conformance is primarily a vendor and contributor concern, as consumers aren't expecting a Knative conformance badge, and all offerings stand on equal footing at the moment.

_original 2 paragraphs of text:_
**But who actually cares about conformance?** Vendors who offer Knative as a Service in some form or fashion (VMware CNR, Google Cloud Run, TriggerMesh, Red Hat OpenShift Serverless, IBM Code Engine etc.) may want to be able to say they are "Knative Conformant." In addition to this, legally speaking, this matters because being Knative Serving Conformant, for example, allows you to legally use the Knative Trademark via a [Conformance Badge](https://docs.google.com/document/d/1XrCnTjDVsiXWC-ameVK2TqFC9WR9naDBO9vuYwWHUiw/edit#heading=h.6a00xlkjxwx6).

**In the short term, the audience which cares about Conformance is, of course, the vendors who offer Knative to their customers.** There is a world in which end users want to know that the platform they are using is conformant to our spec (e.g. for portability reasons) but the desire for conformance in the short term is clearly a push from Vendors who want the ability to legally use the Knative mark (which is, of course, very important).

## Defining 1.0, Defining an Audience
I'm not sure it's necessary to strictly define 1.0 but, in short, labeling a product "1.0" functionally means the product is mature and mostly stable. There is an argument to be made that perhaps Knative is already 1.0: many vendors are shipping Knative as a Service to customers and many users have deployed Knative to production. That, however, isn't the argument we are making here.

**But who actually cares whether Knative is 1.0?** Well, the most obvious answer is our end users or potential end users. There is a perception that Knative isn't a "mature" product (which those of us who use the product know to be untrue) and part of that perception is almost certainly due, in part, to the semantic versioning of the Knative.

However, there is something to be said about the process of releasing a "GA/1.0" product. The process of dotting i's, crossing t's, and ensuring there aren't any glaring mistakes in what you are releasing. Knative has not had the opportunity to dot or cross and therefore may need a more thorough audit before releasing a "1.0."

## Bringing it together
So vendors care about conformance and end users care about versioning. Why have these two labels been conflated?

Since the majority of the efforts expended on Knative are coming from vendors offering Knative as a Service (not unusual in OSS) it makes a ton of sense why "1.0" and "Conformance" are being said in the same breath. We want to have a stable Knative, which requires a thorough audit of our specification, and we want to make sure that our (vendor) platforms are conformant to that specification.

But treating these two (very important) things as fundamentally the same thing has created a bit of a tar ball. Do we ship Knative Serving and Eventing 1.0 and Serving Conformance but not Eventing? Do we wait until Eventing Conformance tests are written until we release either Serving or Eventing? These questions could go on and on ad nauseam.

## How we move forward: A release plan
In the last TM Committee meeting, we (Omer and Naina) brought up the idea that maybe these things don't have to be the same thing and maybe we ought to not hold up one for the other. Eventing Conformance was already dropped as part of the requirements for GA, we propose dropping Serving conformance as a requirement as well.

Regardless of how we move forward with Conformance of Serving or Eventing, we should:
1. Decouple Release of 1.0 "functional" Requirements from "Conformance" requirements in [Knative GA / Licensable Requirements](https://docs.google.com/document/d/1mC_nDpLIycqiBn5Om1tvbcY3yyAR3WUNXcHiyloEzhg/edit#heading=h.gry76zpg7uj7)
2. Deliver "functional" (read: non conformance) work as part of GA/Conformance Task Force.
3. Release 1.0

After the above is completed, the next steps becomes a bit less clear. We have a few options on how to move forward, either of which could change if needed.

==Plan 1:==
1. Decouple Eventing and Serving conformance from each other.
2. Define minimum conformance testing required for Serving and Eventing. (i.e. minimum "MUST" and "MUST NOT" requirements )
3. Release each of the Conformance tests in the order they are completed. Priority order goes: Serving then Eventing.

==Plan 1 Rationale==
Since Serving and Eventing Conformance are 2 separate tracks of work, it will almost certainly be easier for the skeleton-crew "GA/Conformance Task Force" to manage one at a time.

There are many "unknown unkowns" related to Conformance (at least to us, Omer and Naina) so it would be easier to manage if we were to do these two separately.

Also, the audience for Conformance is basically Vendors. I'm not sure end users are going to pay attention to this sort of announcement, so perception isn't as important in this case.

==Plan 2:==
1. Define minimum conformance testing required for Eventing and Serving. (i.e. minimum "MUST" and "MUST NOT" requirements)
2. Release Eventing and Serving Conformance tests together.
3. "SHOULD and SHOULD NOT" tests can be added at a later date.

==Plan 2 Rationale==
Since Knative (Serving and Eventing) is seen as a discrete product. It would make the most sense to our vendor end-users and others if the project as whole was Certified.