Divide "Maintainer" role into two categories: Triager and Committer

[quetzalliwrites]

Currently, each AsyncAPI repository has a single level of maintainers, each responsible for various project parts. Their duties range from issue triage to PR (Pull Request) approval and merging.

We propose introducing two distinct levels of maintainers to manage an increasing workload and divide responsibilities more clearly. Originally proposed and implemented in our /website repository, we found this change to maintainer roles has expedited work on the website project while facilitating the onboarding of new maintainers.

NOTE: Even though AsyncAPI first implemented this concept in the /website project, this approach has already been implemented in other OSS communities such as Django, React, Kubernetes, and Node.js.

🗳️ Divide "Maintainer" role into two categories: Triager and Committer

• Triager: Inspired by the Node.js community, triagers assess newly opened issues and pull requests. Assigned the "Triage" role on GitHub, they are responsible for labeling issues and pull requests, commenting on, closing, and reopening them, and assisting users and novice contributors. Triagers aspiring to become committers should collaborate with existing committers to gradually acquire more rights, such as approving and merging simple bug fixes.

• Committer: Committers are tasked with approving pull requests and maintaining the project. They receive the "Maintainer" role on GitHub and are responsible for the technical direction of the website, reviewing and approving pull requests, and onboarding new committers and triagers.

Both committers and triagers are included in the CODEOWNER file. We would maintain the existing division of duties based on specific topics. As such, triagers may focus exclusively on code-related or documentation-related issues and pull requests.

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[derberg]

Even though I think this repo is similar to website and we can do Triager and Committer here, I don't want to apply the same things we did in website as we just started there, and do not know how it works.

To copy something like "triager" idea, we should first stabilize it:

• we do not have any public info on how it works there in website with the new approach, I remember we discussed somewhere that it would be nice if docs triage people do public triage in docs channel in slack but nothing like that happen, so I assume there is no active triage of docs taking place
• contributing guide is not updated, we just have stuff written in an issue
• automation has just been merged but we need to test it first before it can be applied in other projects

[quetzalliwrites]

Even though I think this repo is similar to website and we can do Triager and Committer here, I don't want to apply the same things we did in website as we just started there, and do not know how it works.
To copy something like "triager" idea, we should first stabilize it:

Makes sense!!

I assume there is no active triage of docs taking place

Incorrect assumption, we have 1 new docs traigers who has been actively cleaning up our docs board and getting things done. So far, the back and forth triaging convos have mostly happened in GitHub, which is why you likely haven't seen as much happening in slack yet.

[derberg]

oh, ok, if one triager then it makes sense there is no slack interaction 😄
thanks!