Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Version 3 milestone to triage potential inclusions in AsyncAPI version 3 #692

Closed
jessemenning opened this issue Jan 19, 2022 · 7 comments

Comments

@jessemenning
Copy link

Given the large number of issues that could be included in version 3, establishing at least a strawman scope for the release seems to be necessary.

Helpfully, @derberg and @fmvilas have created a running list of potential v3 inclusions

I would propose that prior to the next meeting of the v3 SIG, interested community members should review the list of issues in the milestone and comment on this issue with their opinion on:

  • Which milestone issues are out of date, addressed elsewhere, etc. and can be removed (using a issue number)
  • Which milestone issues are not urgent enough to be addressed in v3
  • Of the remaining (presumably key) milestone issues, provide a ranked ordering of issues in order of importance

In addition, if there are key features/functionality that are not currently in the milestone, I would propose the community members raise issues and have the codeowners attach them to the milestone so they can be properly considered.

@jonaslagoni
Copy link
Member

jonaslagoni commented Jan 20, 2022

I would propose that prior to the next meeting of the v3 SIG, interested community members should review the list of issues in the milestone and comment on this issue with their opinion on:

  • Which milestone issues are out of date, addressed elsewhere, etc. and can be removed (using a issue number)

Agreed, we need people to engage in issues! Raise your objections to the requests or give you support.

  • Which milestone issues are not urgent enough to be addressed in v3
  • Of the remaining (presumably key) milestone issues, provide a ranked ordering of issues in order of importance

I dont think this can be done 😕

It is not up to those who participate in the 3.0 meetings to decide which issues should be considered and which should not. It all comes down to what issues have champions, nothing more nothing less. If you champion an issue and it reach accepted stage (RFC), it is included in the release. We just follow the contribution guide and nothing more 😄

As you said the codeowners created a running list of potential v3 inclusions, that has potential to require breaking changes in the future that we need to consider. However, everything comes back to the contribution guide 🙂

Maybe you meant something different then I interpreted it as @jessemenning? 🤔

In addition, if there are key features/functionality that are not currently in the milestone, I would propose the community members raise issues and have the codeowners attach them to the milestone so they can be properly considered.

Definitely agree that if you are involved in an issue and it is not part of the milestone but should, tag the codeowners 🙂 And leave a comment in #691!

@jessemenning
Copy link
Author

It is not up to those who participate in the 3.0 meetings to decide which issues should be considered and which should not. It all comes down to what issues have champions, nothing more nothing less.

My opinion:

  • All of this work would occur on GitHub, which is accessible to the entire community, not just those participating in 3.0 meetings. So it's the community that decides what should be included in v3.
  • Champions are great and obviously what is defined in the contributors guide.
  • However, as a supplement to champions, we need a transparent, lower cost way for the greater community to indicate which things are valuable enough to include in v3. Once the community has triaged what things that are of value, individual members can decide whether devoting the time to champion something is worth their/the community's time.

@fmvilas
Copy link
Member

fmvilas commented Jan 21, 2022

Just my two cents, when I created this milestone, I wasn't meaning that all these features should end up in v3.0.0. The "consider" word is there to mean they should be considered when making some rearrangements in the spec because they may end up being introduced in 3.1.0, 3.2.0, 3.x.0, etc. and we don't want to release 4.0.0 just because we forgot to consider any of these features.

I hope I'm making myself understable. Don't feel the pressure of having to release v3.0.0 with all these features included. I'd actually discourage it.

@jonaslagoni
Copy link
Member

jonaslagoni commented Jan 31, 2022

For me, triage <=> champion is the same thing for a major version, figure out if the feature requires a breaking change, whether the change is needed and provides value, what there are alternatives and the pros and cons for them, figure out if we need it now or if it can and should be put off for a later time.

However, maybe a better word for it would be an idea, instead of a champion?

@fmvilas
Copy link
Member

fmvilas commented Jan 31, 2022

That's fine, just wanted to make sure we're all aligned 👍

@jessemenning
Copy link
Author

Closing due to lack of enthusiasm and alternative plans.

@smoya
Copy link
Member

smoya commented Feb 10, 2022

Why are we closing this issue @jessemenning? I still think it makes sense to organize the work on "triaging" those issues. Perhaps it makes sense to include that effort into #691 instead?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants