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

[jessemenning]

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]

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]

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]

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]

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]

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

[jessemenning]

Closing due to lack of enthusiasm and alternative plans.

[smoya]

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?