-
-
Notifications
You must be signed in to change notification settings - Fork 276
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
Comments
Note that a weekly cadence is common for open source standards: |
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. |
I think this is a great idea. As mentioned on the call, I think @smoya reviewing the proposed |
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 🙂 |
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. |
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? |
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
we are not a standard open source community here. Also I can find ones that meet biweekly, like OpenJS.
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. |
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 |
Closing due to lack of interest and alternative plans. |
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
Also, to improve participation, I would propose varying the time of meeting week to week.
The text was updated successfully, but these errors were encountered: