AsyncAPI Community Building And Maintenance Goals (2024 Proposal)

[thulieblack]

Carrying on from Lukasz, it's time to have an open discussion on the goals for building and maintaining the AsyncAPI community.

Things I think we should focus on in 2024:

• Increase The Number Of Community Maintainers
• Expand the Community Documentation

Things I think we should continue investing in:

• Community Initiatives and Mentorship Programs
• AsyncAPI Conf on Tour 2024
• AsyncAPI Video Training and Courses

---

Increase The Number Of Community Maintainers

To ensure long-term sustainability and encourage diverse perspectives, increasing the number of active maintainers in the community is essential as we continue to grow. Currently, we only have a few maintainers, which results in a burden on them, especially when it comes to providing reviews, giving feedback, developing, maintaining, and mentoring. By increasing the number of maintainers, the workload can be distributed, leading to quicker issue reviews and potentially avoiding burnout. It is important to focus on maintainer growth during this phase of our community.

Ideas

• During the mentorship program, let's tailor-make our projects to equip mentees to the path of ownership after completing the programs. I understand that most people who show interest in these programs are interested in gaining skills and then go their way after the program ends, but if we can retain at least two individuals after the program, it is progress. For example, individuals like Akshat, Maya, and Florence started as mentees but are now active maintainers.
• We have a few dedicated active contributors, and we can take steps to groom and encourage them to take challenging tasks that will increase their knowledge and eventually transition into ownership and become maintainers.

Expand the Community Documentation

The AsyncAPI community is growing, and it's high time we expand our community documentation. We need to simplify and reduce the time spent on onboarding calls by creating onboarding documentation. We also need resources such as:

• How to become an AsyncAPI contributor
• Becoming a Code Owner/Maintainer
• What it means to become a TSC member
• AsyncAPI style guide - (WIP)

These will provide transparent, step-by-step processes and ease the journey of people joining our community.

---

Community Initiatives and Mentorship Programs

We need to continue with the following initiatives as they play a big part in bringing diverse individuals into our community while fostering growth and development.

AsyncAPI Ambassadors Program

So far, we have doubled the Ambassador list from 3 to 6. This year (2024), we should extend the program to university folks. It will drive education and teach communities about our work at AsyncAPI.

AsyncAPI Bounty Program

Open Source shouldn't be about free contributions, which is why the Bounty Program is one of the important initiatives, and we need to support and pay maintenance and contributors for their work.

AsyncAPI Maintainership Program

I would like to propose that we extend the current AsyncAPI Mentorship to the AsyncAPI Maintainership Program. Under this umbrella, we would have sub-projects that equip maintainers-to-be on the path to becoming code owners and maintainers.
We will still have small to medium-scale projects for mentorship, but I want to shift our primary goal to retaining maintainers after the end of the program.

Mentorship Programs

• Google Season of Docs
• Google Summer of Code
• Hacktoberfest

AsyncAPI Conf on Tour 2024

AACoT'23 went well. We managed to host in 4 different locations and gained better experience planning in-person conferences. Thus, I propose we continue again in 2024.

In Summary:

• We should start planning and reaching out to potential companies interested in hosting the 2024 edition.
• Choose locations that are accessible to the majority of the community members. (i.e., Africa, America)
• Space the conference dates at least thrive on having one conference per each calendar quarter.
• Hosts need to agree to help out in marketing the event.
• Open up sponsorship tiers for companies who'd like to be part of the AACoT brand; the funds received will go towards travel funding, swag costs, and other marketing costs. We have a simple Sponsorship Prospectus detailing this vision.
• Lastly, we need to start planning As Soon As Possible!!

AsyncAPI Video Training and Courses

We are big on open-source education, and we should definitely start investing time and collectively coordinating in having training videos. These videos can serve as onboarding resources for people looking to understand more about ASyncAPI and its concepts. We are starting well, as Barbaño has video scripts written, and we can collectively begin recording videos. Additionally, we can have a joint effort with EDA Sessions, which has more interesting topics that could benefit community members and amplify our education impact.

These resources will provide individuals looking to delve into AsyncAPI and EDAs a starting point in their learning journey.

Let the discussion begin!!!!

cc @asyncapi/ambassadors @asyncapi/tsc_members

[devilkiller-ag]

Hi, I am excited to contribute to the Async API. I am currently in the process of understanding the code base of asyncapi-react. It will be great if I can be assigned with some good first or documentation issues.

[thulieblack]

Welcome to the community! Make sure to join the #11_contributing channel on Slack and you can have a look at the good first issues that we have.

[AnimeshKumar923]

We have a few dedicated active contributors, and we can take steps to groom and encourage them to take challenging tasks that will increase their knowledge and eventually transition into ownership and become maintainers.

Hey, I like this point. I would like to learn more and come under Maintainership 😁

[AnimeshKumar923]

AsyncAPI Bounty Program
AsyncAPI Maintainership Program

I would to participate in these programs. (Although I'm doing this issue under the current Bounty Program Q4 2023!)

[Lancetnik]

Hello there! I am a core developer of FastStream - the Python frameworks to build well-structured publish/consumes services for various Message Brokers. One of the great FastStream features users love - automatic AsyncAPI schema generation (and hosting) right from the service code. Thus, I have a little request to react-component that you can, probably, implement this year.

For now, FastStream uses CDN React Component version to draw a static HTML represention of user service schema. But we can easely (cuz we have backend to serve this static site) implement test message publishing funtional right from a web schema (like OpenAPI allows you to send test HTTP requests). At first, test messages will be addressed only to the original FastStream service... But then we'll implement AsyncAPI schema -> FastStream service generation, that allows us to generate publishers "on flyight" and publish any message to any FastStream-supported Message Broker right from the website.

A slightly confusing preface... We need to ability pass some React-children components to the AsyncAPI react component to draw user payload input somewhere around payload example. We can create the component fork and implement our own component version (with all required inputs), but it is a bad way to build long-living tools. So, I hope on AsyncAPI team collaboration in this question and believe, that together we able to make AsyncAPI environment riacher.

[fmvilas]

Hey @Lancetnik! I love this! Please submit this as an issue in the react-component repo 🙏 This discussion is about goals and not specific tasks to do. Also, here there's a high chance react-component maintainers don't see your message.

[Lancetnik]

Sorry about wrong place. I am just want to inform the AsyncAPI Team about our work to make the community stronger 😄

[fmvilas]

Absolutely! And I want you to succeed 😄

[derberg]

Great goals proposal!

[smoya]

Here are my ideas and proposals:

• In my top list, I want to +1 to Increase the number of community maintainers, as stated in the description of this discussion.
• Get usage insights from all AsyncAPI tools. We are starting with this in CLI atm, but should be expanded to all tools.
  • This is crucial for understanding the impact of our tooling.
  • Needed for making decisions on keeping tools alive, tools that need to improve regarding features/UX, or rather abandon them.
  • How can we consider a tool to be a success without numbers?
• Reduce the number of tools maintained by AsyncAPI org and keep the focus on the Spec and tools that are really empowering with value:
  • Fast design (Studio-like)
  • Quick prototyping (Glee-like)
  • Maintainability of models in the long term (Modelina-like).
  • Validation at almost zero cost (Parsers-like, IDE’s like what we do with VSCode + Schema Store, etc)
  • The rest can be maintained outside the AsyncAPI if there is interest. Only if numbers speak, adopt them under AsyncAPI umbrella (related to the previous point)
• Ensure the support and presence of AsyncAPI in the most popular tools and big projects. This can go from tools like Postman, Backstage.io (having a plugin for autodiscovery of AsyncAPI Documents, editing them with an embedded Studio, etc), and other frameworks, but also internals in projects such as Kubernetes (internal code uses websockets, for example).
  • This helps increase presence, hopefully helping to convert potential users to final users of the spec (and maybe future maintainers!).
• Answering the following questions and find solutions:
  • Why are there still many people who do not follow a design-first approach when designing their asynchronous API but do for REST?
    • Projects in GitHub that expose services such as websockets and don’t have an AsyncAPI file.
    • Expectations from potential users.
  • Why do people abandon AsyncAPI usage, if so, at some point? What is making them stop using our Spec and tools?
    • Expectations from users who are unhappy or didn’t find what they needed from AsyncAPI.

[derberg]

@smoya the goals described by @thulieblack are like the goals from the past we did, focused on goals for building and maintaining the AsyncAPI community

are below goals contributing to that topic:

• Reduce the number of tools maintained by AsyncAPI org and keep the focus on the Spec and tools that are really empowering with value -> how it contributes to subject of building the community? why would we even try to remove from our umbrella a project that is for example used by others and helps community?
• Why are there still many people who do not follow a design-first approach when designing their asynchronous API but do for REST -> how is this important for the growth of AsyncAPI? design-first is not the only approach to do APIs. Important thing that we do here in AsyncAPI is that we are not so opinionated. Also how can we find these many people? who is it?
• Why do people abandon AsyncAPI usage, if so, at some point? What is making them stop using our Spec and tools? -> how can we actually identify these problems and people? for example I do not know any example of anyone ever publicly claiming (slack/github/anywhere) that they abandon AsyncAPI. So I would say first "why do we think people are abandoning AsyncAPI?"

and are ☝🏼 goals that should be coordinated by community manager?

[smoya]

@smoya the goals described by @thulieblack are like the goals from the past we did, focused on goals for building and maintaining the AsyncAPI community

@derberg To be honest, It was not clear at all to me this discussion was exclusively for that matter. I read it in the first line, but I totally thought this was a global thing as per the title AsyncAPI 2024 Goals Proposal. I believe the title should be changed. I am the only one who thought that? Maybe, or maybe I'm among the only ones who shared their goals.

I'm gonna answer your questions anyway here:

Reduce the number of tools maintained by AsyncAPI org and keep the focus on the Spec and tools that are really empowering with value -> how it contributes to subject of building the community? why would we even try to remove from our umbrella a project that is for example used by others and helps community?

It is all about numbers. I believe we should get usage metrics of everything we can and evaluate the cost of maintaining those projects with less usage, or at least, look for changing the strategy and keep only updating them with critical fixes.
This is in favour of moving efforts into the spec, and all that it surrounds it. I helps community? Totally subjective question IMHO.

Why are there still many people who do not follow a design-first approach when designing their asynchronous API but do for REST -> how is this important for the growth of AsyncAPI? design-first is not the only approach to do APIs. Important thing that we do here in AsyncAPI is that we are not so opinionated. Also how can we find these many people? who is it?

I didn't say "design-first is the only approach to do APIs". I'm just comparing AsyncAPI and OpenAPI usage when designing APIs. I see so many projects using OpenAPI out there. I saw projects that could have combined those with AsyncAPI documents but, for some reason, they didn't. Answering my question from my sentence is a bet. And for sure, more investigation is needed; part of the task to perform in case we move forward answering this question.

Why do people abandon AsyncAPI usage, if so, at some point? What is making them stop using our Spec and tools? -> how can we actually identify these problems and people? for example I do not know any example of anyone ever publicly claiming (slack/github/anywhere) that they abandon AsyncAPI. So I would say first "why do we think people are abandoning AsyncAPI?"

I would not expect anyone saying they abandon AsyncAPI but rather just stop using it or not fully using all the features they would like to. Just because we don't see something we can't say it is not happening. Again, my question is not a reality, just a bet. Something we might wanna ask ourselves. Because lets be clear, no one atm can answer questions like these.

and are ☝🏼 goals that should be coordinated by community manager?

Now that you mention, they might some of them. For example, keeping track of user complaints, or messages sharing usage experiences through our community channels and notifying stakeholders.

[quetzalliwrites]

Oh interesting, I was confused too then... I also thought these were global OSS goals for the project.

[derberg]

It is all about numbers. I believe we should get usage metrics of everything we can and evaluate the cost of maintaining those projects with less usage, or at least, look for changing the strategy and keep only updating them with critical fixes.
This is in favour of moving efforts into the spec, and all that it surrounds it. I helps community? Totally subjective question IMHO.

I totally agree if you explain it this way. Make sure we have projects that have active maintainance, active usage and active community - if one of those is missing, we need to discuss if the project should stay under AsyncAPI umbrella. For example if there is no active maintainer, ask community if anyone else wanna help and if not - archive

But yeah, this is more of a house keeping on TSC side, and for now probably my side to keep discussion running. Not sure if we should expect community manager to drive such topics.

I didn't say "design-first is the only approach to do APIs". I'm just comparing AsyncAPI and OpenAPI usage when designing APIs. I see so many projects using OpenAPI out there. I saw projects that could have combined those with AsyncAPI documents but, for some reason, they didn't. Answering my question from my sentence is a bet. And for sure, more investigation is needed; part of the task to perform in case we move forward answering this question.

so you basically mean how as AsyncAPI Initiative we can increase the adoption of AsyncAPI?

I would not expect anyone saying they abandon AsyncAPI but rather just stop using it or not fully using all the features they would like to. Just because we don't see something we can't say it is not happening. Again, my question is not a reality, just a bet. Something we might wanna ask ourselves. Because lets be clear, no one atm can answer questions like these.

but in this case, I'm still on a side that "I cannot answer the question" because I cannot figure its context. It it is a bet, not a real question, how can I answer it if it is not possible to ask a follow up questions and get some examples. You know what I mean?

exercise: "why people stop using Kubernetes" - to be able to answer it, I need data like articles/presentations or direct communication examples so I can asses if the reasons are just emotional or based on real arguments with constructive criticism.

Now that you mention, they might some of them. For example, keeping track of user complaints, or messages sharing usage experiences through our community channels and notifying stakeholders.

are you aware of some complaints that are lost and not addressed? I have a feeling in between words you kinda have a feeling the world is against us and that something wrong is happening? 😅 or what you're saying is that we should basically have a dedicated channel/document where we explain any community member on how to share feedback (like that for docs we have dedicated channel that works) about different parts of the project (that spec feedback here, docs feedback there, code of conduct somewhere else) and have a transparent process behind feedback review? to be ready? just like we want to be ready with possible code of conduct violations and this is why we have setup a code of conduct team? if yes, I think it could be completed as part of community documentation topic 🤔

[derberg]

@alequetzalli

Oh interesting, I was confused too then... I also thought these were global OSS goals for the project.

they are kinda still "global" but focused on community management

[subhamkumarr]

Will it participate in GSoD this year?