Epic roadmap to the new AsyncAPI community section

[AceTheCreator]

After a long discussion with @derberg, we've decided to have a community section located on the Asyncapi website at the following path /community.

This new addition to the community website is going to hold everything related to the community from the Ambassador program to the community docs and every other area community/contributor related.

This overarching goal here is that we want users to have a community experience when using the website

Herer's a link to the current pull request #902

The following list is categorized into 3 sections.

Design

• [x] Help with the enhancement of the current landing page design
• [x] Design banner illustration for every subpage
• [x] Designs/art direction for pages like [ambassador program, event&meetups, community members]
• [x] Community member card design

Engineering

• [x] Implementation of the enhancement made by designers for the community landing page
• [x] Implementation of the subpages required in the community section as designed by designers
• [x] implementation of the events&meetups page, which will include all events/meetups both past & upcoming with filter functionality.
• [ ] Contributors ranking based on the most active (not sure if this is a good idea yet)
• [ ] A well-implemented page for community wiki

Documentations

• [ ] Configuring release pipeline for NodeJS
• [ ] Configuring release pipeline for non NodeJS
• [ ] We tweet out all RCs and Major/Minor releases
• [ ] How can I tweet from the official account
• [ ] How can I post on official LinkedIn account
• [ ] How to create new repository
• [ ] How to donate a project
• [x] How changes in spec are introduced
• [ ] How do we care about old issues
• [ ] How CI works (what can be added and what not)
• [ ] How can I introduce changes in GH workflows
• [x] How to become a TSC member
• [ ] How to become a codeowner
• [ ] /rtm/ /dnm/ and /help
• [ ] dependabot
• [ ] autobumps
• [ ] slack rules
• [ ] toast in slack
• [ ] add contributor guide
• [ ] add maintainer guilde - https://github.com/asyncapi/community/issues/11

[Dule-martins]

@AceTheCreator Hope this is not a dumb question but I want to document the "Configuring release pipeline for NodeJS Configuring release pipeline for non NodeJS" but confuse on how to start.

If I'm correct the docs will be residing in the asyncapi/community path? It is also expected I create a folder name it docs and in that holds all the files you listed?

Some clarity and guide will help, thanks 🙏

[AceTheCreator]

@Dule-mart yeah, you're right. But, I'll suggest you work from my own forked repo and fork the community branch.

[derberg]

@Dule-mart @AceTheCreator I recommend not depending on each other too much. So write the docs, even if new community section is not there yet. Just work on the doc in community repo, maybe introduce docs folder. Then, once all is ready, we can integrate easily. Always work with as small PRs as possible, and not depend on each other. This is especially critical in the open source world, where things are slower than usual, and people come and go without any memo quite often.

[quetzalliwrites]

Let me know if you need my help in the docs, I'm happy to help out!

This sounds like a really great new project ✨✨✨

[Amishakumari544]

Hey @AceTheCreator , Awesome Stuffs are mentioned here I am also ready to contribute in the docs section .😀

[Dule-martins]

Hey 👋 @alequetzalli

It would be nice to work alongside you in achieving this, I have created a folder named docs, and created a file to document the “configuring release pipeline for Nodejs” but it is empty for a start.

[akshatnema]

Hey @derberg, why not we temporarily make a community branch on website repo and merge the present changes of @AceTheCreator. So that whosoever wants to work on the issue, can fork this repo only and merge the changes on community branch instead of forking the forked @AceTheCreator website repo?

After all the issues gets resolved, we will then merge community with master.

[derberg]

@akshatnema I do not see any technical problem/difference between branching form a branch in upstream, or forking a fork and contributing to it.

In case of this project, I strongly discourage you from doing any of it 😄

Long living branches = merge conflict death 😄 and a lot of waiting/blocking of each other.

So I recommend you to work asynchronously 😄

---

@Dule-mart there is a lot of input for documentation in this live stream -> https://www.youtube.com/watch?v=DsQfmlc3Ubo

[Dule-martins]

Thanks for the share @derberg

[akshatnema]

@akshatnema I do not see any technical problem/difference between branching form a branch in upstream, or forking a fork and contributing to it.

I think you didn't get it. I want to say why to create forks of a forked branch. @AceTheCreator branch is already having a PR and if someone wants to contribute to it, have to fork Ace repository, not this one. In this case, we will encounter lots of problems:

• CODEOWNERS have to review the PRs on Ace's repository

  Since they are working on the PR made by Ace, the updates or PRs made by other contributors won't be reflected in this repo. Hence, it will be a difficult task for CODEOWNERS to give reviews on the PRs.

• CI/CD won't be applied on Ace's repository

  All the PRs made on that repo will not be tested in terms of all the workflows and CI/CD of Netlify. So, we then have to manually test all PRs by cloning them in the local system.

These are some of the concerns I think we will face in the long run. After looking on the list of tasks we have to implement, I don't think we will be able to manage with your scenario.

What my plan:

We will make a community branch in this repo in which we will merge the present @AceTheCreator PR and other contributors will now be able contribute to community branch by making PR to it. This way everyone will able to track and review new PRs.

[AceTheCreator]

@derberg I actually think the @akshatnema approach will save a lot of headaches 😊

@akshatnema it's best I update the current PR and get it to merge with the new community branch in this repo. Then we all can work from the community branch from the main repo.

@derberg what do you think?

[akshatnema]

@derberg @AceTheCreator Adding to my above point, the community section is a completely new implementation and creation of new pages which I don't think will conflict with existing page changes. So, if we even merge the community branch with master manually and weekly, I don't think we will encounter major conflicts inside the community branch when we will go for the final merging.

[Dule-martins]

@akshatnema does this mean I don't have to fork the asyncapi/community repo? What will happen if the community repo is forked and PRs are made into that repo?

[derberg]

Can you folks clarify, maybe provide examples of PRs that someone would open against @AceTheCreator fork and his community branch. Why would anyone like to do it and what would it be, except for community-related documentation

[akshatnema]

@derberg Look at the screenshots and links provided below.

PR link - https://github.com/AceTheCreator/website-1/pull/1 The repo which is forked from @AceTheCreator repo - https://github.com/The-Code-Of-Duty/website

See this image, any contributor has to do the contributions to community section in this way by creating PRs on Ace's repo, not in AsyncAPI. So, this will make confusion on where to make a PR for certain changes and also difficult for maintainers to keep track of the new PRs.

[derberg]

@akshatnema I understand technically that people would have to open a PR against the fork, this is clear 😉

I just do not understand why anyone would have to do it. Why would you consider opening a PR to his fork, except for the docs that we clarified can be done separately?

[derberg]

to not run this discussion for too long,

there are 2 top items for the new community section:

• UI
• Docs

UI is also divided into additional 2 items:

• minimal UI (with some stuff that might be hidden as not completed or left out but inactive with proper tool tip info like tbd)
• additional features -> like implementation of the events&meetups page

---

For Docs I'm firmly opinionated that they should be done in a separate PR, each document separately, in community repo.

---

For UI

For additional features, I'm firmly opinionated they should be done separately, later, after initial work. Separate PRs to master branch.

For minimal UI, I'm ok with whatever solution you prefer. If @AceTheCreator requires help and commits from maintainers, and prefers these through PR (normally this is not needed) then create community branch if you need folks. Especially that @akshatnema wants to help also supports this approach. My only huge request: **please remember to keep the work with MVP approach, so final review between community -> master is not a hell for other maintainers. **

Also hint for you if you go ☝🏼 direction: right after creating community branch with changes from @AceTheCreator, open a PR between community and master so we can on regular basis see how it looks thanks to generated previews. Also it will enable our automated merging of changes in master (as long as they are not breaking changes).

[Harish-b-03]

Heyy @AceTheCreator @derberg 😃, I would like to contribute in this, specially Design and Engineering categories.

@AceTheCreator is there any urgent need for some task?, so that I can start with that task and continue with other things. So can you suggest me the first task I should start with?

Thank you 😁

[AceTheCreator]

@Harish-b-03 thanks for your interest, I don't know what your design skills are like, can you help do some designs for this section "Designs/art direction for pages like [ambassador program, event&meetups, community members]"?

I'd be glad to working with you on this :) What do you think?

[akshatnema]

Hey @AceTheCreator, I'm back!!. So I see that Lukasz merged your PR in another branch community in the repo, but I think we are still missing a PR that should be initialized from the community branch to master branch to track the changes. Should I do that for you?

---

Edit: Also, there will be certain merge conflicts right now because we merged the PR #804 which comes up with a lot of changes in the master branch and changes in the Tailwind version in website.

[AceTheCreator]

Hey @AceTheCreator, I'm back!!. So I see that Lukasz merged your PR in another branch community in the repo, but I think we are still missing a PR that should be initialized from the community branch to master branch to track the changes. Should I do that for you?

Edit: Also, there will be certain merge conflicts right now because we merged the PR #804 which comes up with a lot of changes in the master branch and changes in the Tailwind version in website.

@akshatnema that will be really helpful. Thanks man

[Harish-b-03]

@AceTheCreator I am not that much good at design, that too from the scratch🥲.

Can you please suggest me some tasks in the Engineering? I think I can work on that and parallely try to design.

Heyy @mcturco😁, hope you are doing great!. Can you please help me in this? We got to design some pages or layouts (even I don't have any idea about this, I hope @AceTheCreator can help us 😃)

Thank you

[AceTheCreator]

@Harish-b-03 I would really love to hop on a call with you so that we can brainstorm together and come up with something.

@mcturco has a lot on her plate atm. Lets put something together, then she can help us review it :)

What do you think @Harish-b-03?

[Harish-b-03]

I would really love to hop on a call with you so that we can brainstorm together and come up with something.

Ofcourse, I will catch you on slack😉

@mcturco has a lot on her plate atm. Lets put something together, then she can help us review it :)

Ohh ok fine👍🏻😁

[mcturco]

Yeah as @AceTheCreator mentioned, I have some other tasks that I am focused on at the moment, but I will be available for feedback. I just posted the issue in the design channel on slack, so hopefully someone is interested in helping with design guidance!

[Dule-martins]

Hello @AceTheCreator I will like to create this "add contributor guide" Any guide on what to do

@derberg

[derberg]

@Dule-martins this one is hard one for me as I have no idea where to start. Many folks point to https://docs.djangoproject.com/en/dev/internals/contributing/ as good example. And I'm thinking if we should write our own or actually research few, link in one document and just mention some asyncapi-specific things that others do not write about.

I think best is if you start with creating an issue in https://github.com/asyncapi/community and share it in Slack, in #how-to-contribute channel and ask people for input, what contributors need

[Dule-martins]

Is it ok to name the issue contributors guide?

[derberg]

I guess so, in the end it will be like current https://github.com/asyncapi/.github/blob/master/CONTRIBUTING.md but on steroids 😏

[asmitbm]

Hey @AceTheCreator I would like to work on the Design and Engineering part. Is this issue still active?