Committee formed with

• @hblixt from Intuit
• @wanghong230
• @jannfis from Redhat
• @todaywasawesome from Codefresh

See Argo Maintainer's meeting Sept 14, 2021.

Document the goals of the conformance program and start gathering important ideas that will need to be part of the standard.

Inspiration:

• Prometheus https://github.com/cncf/prometheus-conformance
• Kubernetes https://www.cncf.io/certification/software-conformance/
• Crossplane https://github.com/cncf/crossplane-conformance
• https://github.com/argoproj/argo-conformance-program/blob/main/README.md

I believe I've already expressed some of my opinions in conversations and discussions regarding this topic, but just wanted to put forward some of my concerns out in the open, and where I currently stand with this program. What's still unclear to me is: what are our motivations/goals for a conformance program and how do we expect it to benefit the project? And is a conformance program the best avenue for achieving these goals or should we explore other means?

I understand Kubernetes/Prometheus are being used as examples where this process is being put in place. But unlike Kubernetes and Prometheus, Argo is much more than just an API specification and set of defined behaviors that can be caught in a test suite. I actually consider API compatibility as a pretty low bar to meet with respect to conformance. Would UI fall into conformance? Why or why not?

Second, we must absolutely address the issue of project forks, product variations, and contributions back to the core project (or rather the lack thereof). I am concerned about the inevitable "enterprise" forks of Argo, and the low incentive for contributions being given back to the core project. How do we incentivize vendors to contribute the features back to core instead of their own offering?

Lastly, I feel there is a big risk here with Argo brand dilution. It took us literally years to clear the confusion between the various Argo sub-projects, and train our community and users that Workflows and CD were actually two completely separate things. To this day, I still talk with customers about this confusion and need to repeat this message again and again. I predict the situation to become worse, once we start allowing things like: Acme Argo CD XXX, Bacme Argo Pipelines, etc...

Just wanted to put down where I stand on this, as it seems we are rushing the process and this is a decision that we need to tread very carefully on.

Once the standard is developed it needs an affirmative vote from Argoproj maintainers to become binding.

Requires completion of Goals, Standards, and Test milestones.

@jessesuen @wanghong230 One of the concerns brought up by Jesse in the conformance meeting would be that people go around the built-in mechanisms for adding functionality. We'd like to draft a requirements that would help incentivize people to add functionality to our extensions systems rather than lose conformance by adding non-conformant specs.

Conformance committee meetings should be open and regular to move the project forward.

Begin drafting the requirements for being conformance.

Issues that have already been mentioned:

• Timeboxing
• Protecting UI
• Participation (maintainers)
• API conformance
• CNCF membership

Other notes in issue #3

In accordance with CNCF rules, conformance programs must have an affirmative vote from the CNCF board to become binding. This is the final step in conformance creation.
[] Conformance Goals Defined
[] Conformance Standards
[] Test Suite
[] Maintainer Approval
[] CNCF Board Approval