Shall AsyncAPI provide detailed status updates periodically?

[smoya]

Currently, there is a status update @derberg does every quarter on what happened on AsyncAPI. I.e. the next one is being crafted right now here.

However, I'm wondering if this is enough for the community or rather they would prefer detailed status updates more often.
In relation to this, some community members have started the initiative on their own of writing bi-weekly or monthly updates on some AsyncAPI areas, such as:

• @mcturco with Visual & Experience Design
• @alequetzalli with Docs
• @Barbanio with Training
• @magicmatatjahu with EDA Design & Documentation
• @jonaslagoni with Tooling
• @smoya with Spec and Parsers

I find those updates useful for different community profiles:

• Active contributors can quickly catch up with the latest updates or events that happened around their area of interest.
• Potential contributors can have a better idea of how the contribution flow works and also jump into an issue that requires help.
• Intermittent contributors or Users can catch up with the latest updates quickly and with more detail than with quarterly updates.

We could promote people from the community to provide those updates. This is happening now organically (as shown earlier) but anyone could jump in and collaborate by adding their updates or volunteering to take the lead on each of those areas as well.

My question is:

In addition to keeping quarterly updates, would it make sense to grab all those periodical updates made by individuals, and put them together into a periodical (monthly?) blog post rather than have all those updates being dispersed on each individual's Gist?

[magicmatatjahu]

In addition to keeping quarterly updates, would it make sense to grab all those periodical updates made by individuals, and put them together into a periodical (monthly?) blog post rather than have all those updates being dispersed on each individual's Gist?

I'm in favour of that. I noticed that our updates, which we add on gist and share on slack, are not read by many people and links quickly disappear. Such a blog post would have the advantage that it would always be available on our site and would not disappear so easily.

[Barbanio]

Yes, I agree with @magicmatatjahu. I think it makes sense.

[mcturco]

Agreed!

[luphieanza]

Hi, @smoya. Just want to ask. are your meaning is, that we creating a newsletter with the context including what's happening, what's going on, and what's next on each topics?

I agree with you that this can be a good thing that we have. we can use a blog post or examples like, Dev.to or Hashnode and it will be distributed publicly OR we can easily publish our newsletter on ASyncAPI LinkedIn & Twitter? That should increase our social media traffic when we post some news on our official social media platforms.

[smoya]

are your meaning is, that we creating a newsletter with the context including what's happening, what's going on, and what's next on each topics?

Yes, kinda. My idea is more on moving all those updates made by individuals (i.e. this one) into a blog post on https://asyncapi.com/blog. But open to whatever the community considers is best of course.

[luphieanza]

I see, yes we should primarily encourage individuals in the community to sync the blog posts that we have, and as time goes on, we can find out to reach other considerations option to share it on other sources.👍

[akshatnema]

Hey Everyone, on listening to the last words made by @smoya in the recording of the last Community meeting, I think he made a good point on making the updates/changes made by various code-owners be centralized in one place, where the new contributors or existing users can very well accommodate how the community is progressing and making amendments in the respective fields.

I want to add more in this that the centralization of the updates is a good process but making a blog post on the website, specially a single blog post for all updates will make it very much long and less readable. Making a separate blog for each field like design, tooling, spec, etc can lead to various blogs per week/month. Then may happen, that the important blogs may get below or down list and got unnoticed by many users. Making separate gists/notion pages by each code owner makes the process more suitable for him/her, but nothing gets centralized in this.

From my suggestion, we should completely switch to GitHub gists or Notion pages. Github gists because everyone is comfortable with Github and we are already making most of the Discussions there. Regarding Notion, it actually provides a good interface and platform to write the blog and make a deployable link where the public can effectively read the stuff easily and in a properly documented form. Notion itself has good templates to organise Team Wikis like this.

I can't say anything about the frequency of updates posted because it totally depends on the code owner on when to write a blog for recent updates. My suggestion is totally on the centralization part.