Update to OAM governance model needed

[BBialeckiACR]

To grow community support for OAM and ensure community involvement, the governance structure and membership needs to be updated. I suggest that there be a voting structure, organizations be given rights due to contributions with designated representatives and alternates, whether it be by attending meetings, working and contributing code, etc, therefore adding additional roles to the overall structure and the ability for organizations to be able to have a voice in changes. Based on overall involvement, organizations may have more than one vote, but never more than a majority requiring at least cross organization collaboration and agreement to pass any changes.
The overall concept needs to be enforced that any changes be non-breaking within the spec.

[kminder]

There are a few important points that would need to be addressed in the governance model.
As pointed out above it seems that an organization vs individual model is important to ensure that organizations with multiple participating individuals cannot exert unbalanced influence. In addition there may need to be different rules for "in progress" spec changes and final spec revision approval.

[wonderflow]

Hi, @BBialeckiACR @kminder , currently most of the maintainers are mainly focus on KubeVela and we are practicing implementation driven design instead of design based on nothing.

With this context, we're glad if you can join the KubeVela project and discuss the Implementation and practice with real use case. And then, we can promote the new upgraded model into this repo.

We will respect every community members and their ideas, but we will also be very cautious about changing the spec. Of course we will discuss first before merging any changes.

Thanks for your understanding and suggestions!

[BBialeckiACR]

This seems contrary to the sentiment that was expressed on the community call and the spirt in which the last issue was closed, as well as KubeVela rolling back to support spec version 0.3.1. I hope there can be some consensus between the community members including KubeVela to truly standardize the spec to allow a community of implementations.

[wonderflow]

I'm sorry but the overall idea is just like the comment in the closed issue: #473 (comment)

We can discuss what should be rolling back if there's good reason. For more specific:

• The workflow and Policy API: we won't add these two new concept immediately until users feel the Implementation is useful and widely used.
• workload_types.md the workload type is still compatible in KubeVela, but we intend to prioritize to use ComponentDefinition as alternative. ComponentDefinition is more practical and useful.
• application_scopes.md: the same with workload types, kubevela is still compatible with this mechanism but policy seems to be a good alternative.

As a result, you can see most of the design is still compatible and we're open in KubeVela and you're welcome to discuss there.

The only thing changed is OAM design will driven by implementation instead of based on nothing.

[BBialeckiACR]

I disagree with this completely until there is a version 1 of the spec officially release for implementation. Once there is a community approved version 1, I can see this stance being taken, ensuring that those implementations in the entire community are supported, as well as support for extension based on use cases that could then be standardized in future versions.

[wonderflow]

I understood your concern that the changed spec maybe somehow breaking the impelementation. I also agree that we should keep the compatibility as much as possible.

So the design and Implementation principle of KubeVela is to standardize the common case while keep all the extension.

[dhiguero]

Thanks @BBialeckiACR for raising this issue, our answer to #473 was also raised in the same spirit. We think that the OAM community needs to get back to discussing the Spec evolution. With respect to the @wonderflow comment, we understand that the resolution of #473 pointed to the need of maintain the Spec as a separate entity by itself. I do not agree with the view of features being discussed internally in Kubevela, and then propagating them back in the community. As mentioned in the last community call, this seems like an imposition on what is the evolution of the OAM Spec.

The community even being small, has many regular participants such as @kminder or @BBialeckiACR that can provide valuable insights in the discussions as it had happen in the past, and we as a community can work towards a better definition of the OAM spec. With regards to the current issue, we think that there should be a clear procedure/mechanism to define:

• What is the process to propose a new feature/modification/change in the spec? For example, creating a particular type of issue as a RFC that can be discussed online in the community calls and offline through GitHub.
• What is lifecycle of those issues? For example, establishing a time frame for comments (e.g., 15 days) and closing issues that become stale. Also addressing clearly the next steps for the issues: in which version of the OAM spec will be released, what is the community approval process, etc.
• Which are the responsibilities of a maintainer/contributor? Which is the process to nominate one?
• What do we do the existing 105 open issues? Is this a responsibility of the maintainers? Maybe we need additional working sessions apart from the community call for things like this.
• Where do we plan the roadmap for the OAM Spec?
• Which are the objectives of the community call? This is related with the need or not of other working sessions.

As a next step proposal, we should dedicate the next community call to discuss this.

[wanis-fahmy]

Hey @dhiguero @wonderflow, just wondering what the outcome of the discussion in the community call was and where to see the OAM Spec roadmap.

Thanks

[zt810950783]

邮件已收到，谢谢

[wonderflow]

Thanks for raising this up. @wanisfahmyDE

OAM spec is open, since the last community discussion, there're some conclusion:

1. KubeVela and OAM Spec are developed independently, they are in different github organizations now.
2. Necessary spec changes should be driven by implementation with real world use case and be practiced long enough.
3. For now, OAM spec is still driven by KubeVela, because KubeVela is the biggest and maturest OAM implementation. We're glad to discuss in the community call if there're other spec related design.

Since KubeVela has been developed more than 2 years, some practices are getting more matured. KubeVela is still compatible with the current OAM spec 0.3 with some new enhancements.

@dhiguero , @Somefive , @jefree-cat and I are drafting the new version and enhancement according to KubeVela.