search

oam-dev / spec

Open Application Model (OAM).
https://oam.dev
Other
3.05k stars 246 forks source link

Update to OAM governance model needed #475

Open BBialeckiACR opened 2 years ago

BBialeckiACR commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

I'm sorry but the overall idea is just like the comment in the closed issue: https://github.com/oam-dev/spec/issues/473#issuecomment-973207518

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

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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:

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

wanisfahmyDE commented 1 year ago

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 commented 1 year ago

邮件已收到，谢谢

wonderflow commented 1 year ago

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.