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

Increase frequency of Spec 3.0 meeting from biweekly to weekly #690

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

Increase frequency of Spec 3.0 meeting from biweekly to weekly #690

jessemenning opened this issue Jan 19, 2022 · 10 comments

Comments

@jessemenning
Copy link

Given the importance and complexity of the AsyncAPI v3 effort, frequency of meetings should be increased from bi-weekly to weekly. This change would allow for

  • better momentum and consistent progress
  • more time for free discussion of important topics (remote/local discussion, pub/sub confusion, etc)

Also, to improve participation, I would propose varying the time of meeting week to week.

@jessemenning
Copy link
Author

Note that a weekly cadence is common for open source standards:
OpenAPI
CloudEvents
OpenTelemetry

@boyney123
Copy link

I'm all for trying it and seeing how we get on, if it becomes too much then we can review it?

Another thing that would be very useful is having sessions (maybe even in this weekly one), where we can dive into issues in more detail (like I mentioned on the 3.0 meeting). This could help folks (myself included!) gain context and understand issues more deeply and also promote conversation for issues and idea generation.

@jessemenning
Copy link
Author

Another thing that would be very useful is having sessions (maybe even in this weekly one), where we can dive into issues in more detail (like I mentioned on the 3.0 meeting). This could help folks (myself included!) gain context and understand issues more deeply and also promote conversation for issues and idea generation.

I think this is a great idea. As mentioned on the call, I think @smoya reviewing the proposed local/remote server distinction makes a lot of sense.

@jonaslagoni
Copy link
Member

jonaslagoni commented Jan 20, 2022

While I did start of with suggesting weekly meetings, I did get convinced that it is better to do biweekly.

How people want to champion the issues is up to them, and it takes the time it takes. There should be no preasure from our side.

Whether you have a desire to deep dive into issues and have a longer discussion on stream or what ever, is up the champion(s). You can of course request it and ask for it, but ultimately, it is the individual that drives the change that control that 🙂

For the many meanings issue I am championing, I plan to do a separate stream detached from the 3.0 meetings. Where we can have a discussion about it and get down to concrete suggestions that will be reflected in the corresponding issues afterwords. Similar to what @fmvilas did with Thinking out loud.

I will then use the 3.0 meetings to give updates on the progress.

So my suggestion is we dont engage in lengthier discussions in the 3.0 meetings but keep it short and concrete to keep any interrested parties up to date, or discuss smaller subjects as we did in the first one. Which then resulted in new issues and discussions.

So to me biweekly meetings is fine 🙂

@fmvilas
Copy link
Member

fmvilas commented Jan 20, 2022

Yeah, agree with @jonaslagoni it should be biweekly. Let's remember not everyone is working full time on AsyncAPI and it takes time for people to actually do something. A weekly one would put a lot of pressure on them.

I'm happy to do deep dives on Thinking Out Loud which I plan to start in February weekly.

@jessemenning
Copy link
Author

Thanks for your feedback @fmvilas, @boyney123 and @jonaslagoni. There's a variety of viewpoints out there, all of which are well-stated. Even if it's just a weekly status meeting, I do feel like it's important to keep momentum to have a weekly checkpoint, and appears to be fairly standard for open-source communities.

Given the diversity of viewpoints, how/when is the decision whether to switch the frequency of the SIG made?

@derberg
Copy link
Member

derberg commented Jan 21, 2022

it's important to keep momentum to have a weekly checkpoint

we are not in rush here, publish and subscribe is here from the very beginning of the spec and the meaning changed like 3y ago? a weekly call can actually push away people that are not able to devote so much time to the spec. We embrace async work here

appears to be fairly standard for open-source communities.

we are not a standard open source community here. Also I can find ones that meet biweekly, like OpenJS.
weekly makes sense when we are in rush, and we have a deadline, like when I will kick off AsyncAPI Conf organization, where we have clear deadline. For 3.0 there is no deadline, and there shouldn't be imho.

Given the diversity of viewpoints, how/when is the decision whether to switch the frequency of the SIG made?

What do you mean? Jonas kicked off the meeting and we agreed there already to have bi-weekly meeting. And why now again vote and change right after first meeting. Maybe let us first check if bi-weekly is really bad.


We work on many different things, 3.0 is not the only important topic here, we can't just throw everything and each of us work 100% just on the spec itself. I would not compare us to Serverless WG handling the CloudEvents spec or the OpenAPI Initiative. We have a much wider scope here.

@bali182
Copy link

bali182 commented Feb 1, 2022

Is this meeting public? I'd be really interested to listen in without disturbing you guys.

@jonaslagoni
Copy link
Member

Is this meeting public? I'd be really interested to listen in without disturbing you guys.

It is @bali182, you can find each meeting as issues in our community repo, here is our next meeting and how to join - asyncapi/community#250

@jessemenning
Copy link
Author

Closing due to lack of interest and alternative plans.

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

6 participants