You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original list from 2021 was here. More updates on this topic are in this article.
This issue is a list of topics, ordered roadmap of things I want to push/drive on in the coming weeks/months aside from everyday tasks. So these are items that are not trivial and need at least one week of work.
I share the list with you to:
Be transparent with you on what I do, what I focus on to help out the AsyncAPI community
Enable you to influence the list and its order. You see something is missing or more important than other topics, then just let me know in the comments.
You can find here tasks that are important for different community members. Addressing issues I see regularly or hear about from community members.
You can also entirely take over the topic. It happened with Building wider event-driven community topic from the last list. Would love to see others drive topics.
💪🏼 - DONE
🏃♂️ - IN PROGRESS
🚽 - CANCELED
Topic
Details
Status
Comment
Summarize 2021
Summarize 2021 from AsyncAPI community growth perspective. Get numbers from Slack, Google Analytics, Twitter, LinkedIn, SEO and see growth level. Analyze and present it in the form of a blog post
💪🏼
Article published: https://www.asyncapi.com/blog/2021-summary. I'm also regularly monitoring progress on Linux Foundation side to make sure we get GitHub analytics from them around April.
GH Analytics project is delayed on LF side, we do not have it yet (state for end of August)
GSoC and other similar initiatives
Last year we participated in Google Summer of Code through Postman. This was an excellent experience for us as it brought many amazing folks into the project. We should participate in other related events. What is great about the AsyncAPI community is that we are extremely welcoming to all folks, and let's show it even more. I think it is lots of coordination work. I consider proposing AsyncAPI TSC that we hire someone full-time to handle this kind of initiative and other parts of the project, like social media.
GSoC - we were not accepted GSoD - we were accepted. preparation phase now CodeForce - was good, few tickets solved Outreachy will be in few months AsyncAPI Mentorship - started here
Meeting as a service
We grow fast. There is a need for more discussions and more meetings. Sometimes one time, sometimes regularly. This needs to be automated as much as possible. We need to assure all is still done under AsyncAPI, transparently as always. We need to ensure we do not encourage easier to establish, fast private sync calls. We need guides and code some automation. Some more details in this GitHub discussion
This year, we want to try out in-person and online conferences simultaneously. Lots of work ahead. I will definitely help here as much as I can. Basically, making sure it happens.
Focus on request to add $schema support as this is something we could use to measure AsyncAPI adoption with real numbers. Design how it would work and drive to execution.
🏃🏼♂️
I already know how to do it. It is just a matter of implementation.
Implementation already started by Sergio and is in progress.
Use cases aka Testimonials aka Case studies
Yes! Last but not least. I want us to get asyncapi.com/use-cases page, where we list all official use cases based on real stories from production. Use cases based on company stories, where not only developers can find answers. Don't get me wrong, I like developers. I just think that asyncapi.com should provide answers also to other groups. Outline is already discussed here. I want to make sure this happens this year, and we get at least three official use cases. My goal here is to have a foundation that later anyone can pick up and contribute, so we expand use cases at scale.
Complete contributor guide
Make it easier for anyone to contribute. I want to have a plain view, with some documents and a well-described backlog of missing documents that other community members could contribute. The best would be to have some persona-focused navigation too.
🏃🏼♂️
Research already in progress. We just need to create new view, backlog of documents and see how the personas concept can work.
I think we have a problem with communication in TSC. We tried Google Groups and now trying just GitHub Discussion, so communication-based on GitHub that relies on GitHub Notifications a lot. I want us to have it well defined this year. This is super important to have a good solution in place that all agree to follow. One of TSC members' duties is to participate in the voting process, and we need to make sure we handle it like a pro.
🏃🏼♂️
we have automation in place that posts info to dedicated GitHub Slack channel information about topic that needs TSC attention. What is missing a signup flow for dedicated MailChimp mailing list that we will use to send notifications about new voting topics
Improve the way we work with stale and keep-open issues
Come up with a process/mechanism that automatically pics up long-living keep-open issues and stale issues that were "unstaled" for too many times. How should we respond to the community about those? How do we prioritize those? We do not even have a recommendation for maintainers on triaging issues. It quickly gets out of hand if this is not a regular job. The best would be to look at it from the spec repository perspective, where we sometimes leave issues for long and then look at them only before release.
Research best way to redistribute sponsor money
Give it a try to IssueHunter and check how we could use it to sponsor work of AsyncAPI contributors on special tasks
Introduce interactive tutorials
We have this tutorial. We get only positive feedback on it. This is the way that I believe we should go, especially with tools like Docable that address a way to have a tutorial that can start an app for you. It also addresses a topic that was always close to my heart. Documentation testing aka how you know your tutorial still works after the last release, without manually checking it.
We need better documentation for Generator
AsyncAPI Generator is one of the core tools we have here. I have a feeling we do not educate about its usage enough. We need to restructure existing documentation, get it on the website, and provide an end-to-end tutorial that showcases all features. Of course best, if it is interactive 😆
🏃🏼♂️
The works started already with support of 2 interns from Google Season of Docs
The idea is that I do not create issues for these topics upfront. I create separate issues only when needed, when some work is actually started.
The text was updated successfully, but these errors were encountered:
This issue is a list of topics, ordered roadmap of things I want to push/drive on in the coming weeks/months aside from everyday tasks. So these are items that are not trivial and need at least one week of work.
I share the list with you to:
You can find here tasks that are important for different community members. Addressing issues I see regularly or hear about from community members.
You can also entirely take over the topic. It happened with
Building wider event-driven community
topic from the last list. Would love to see others drive topics.💪🏼 - DONE
🏃♂️ - IN PROGRESS
🚽 - CANCELED
Summarize 2021GH Analytics project is delayed on LF side, we do not have it yet (state for end of August)
GSoC - we were not accepted
GSoD - we were accepted. preparation phase now
CodeForce - was good, few tickets solved
Outreachy will be in few months
AsyncAPI Mentorship - started here
- Documentation
- Website
Implementation already started by Sergio and is in progress.
Work already started and coordinated by Ace asyncapi/website#903
keep-open
issues andstale
issues that were "unstaled" for too many times. How should we respond to the community about those? How do we prioritize those? We do not even have a recommendation for maintainers on triaging issues. It quickly gets out of hand if this is not a regular job. The best would be to look at it from thespec
repository perspective, where we sometimes leave issues for long and then look at them only before release.The idea is that I do not create issues for these topics upfront. I create separate issues only when needed, when some work is actually started.
The text was updated successfully, but these errors were encountered: