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.

---

🚧 Breaking changes

No

👀 Have you checked for similar open issues?

• I checked and didn't find a similar issue

🏢 Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines

Are you willing to work on this issue?

Yes I am willing to submit a PR!

[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.

[smoya]

I love this idea. As a maintainer, this has my +1! 🙌

Pinging other global maintainers of this repo: @fmvilas @derberg @dalelane @char0n @GreenRover

Additionally, once this gets accepted, I volunteer to create the PR with the changes needed in the CODEOWNERS file.

[dalelane]

makes sense to me - it could be a useful on-ramp for new members

[fmvilas]

Yup, all in! 👍

[derberg]

I do not think it is good solution for this repository. At the moment it is interconnected with other repositories. More info in asyncapi/spec#1041 (comment)

[quetzalliwrites]

Hmm.. what do we do in community voting processes when the YES's have the majority vote, but receive one NO vote? Does the move automatically pass since YES's have majority, or do we have a follow up discussion to see if folks wanna change their votes?

[smoya]

I retract my vote here and most probably in the rest of the repositories I own because the reasons @jonaslagoni exposed in asyncapi/parser-js#955 plus @derberg in asyncapi/spec#1041 convinced me that this is most probably not the best approach yet for these repositories due to their nature.

The proposal was aiming to get more maintainers into the projects and reduce the average workload on maintainers' duties. And some of us believed that by doing this, that will happen. But it is IMHO more than clear that we missed some things and, at least in my case, I´ve got carried away by emotion 😅.

On that side, maybe we could go deeper into the ideas @derberg suggested in asyncapi/spec#1041 (comment). However, In the short term, I think It will only help reduce the workload of current maintainers. Of course, by reducing it, more maintainers could jump in easily but most probably won't happen automatically if we don't have onboarding guides in place by then.

IMHO, time for reflection and discussing with maintainers what they really need.

[quetzalliwrites]

As it stands, it is tied. (so not enough to pass) But, it is also possible that @fmvilas and @dalelane might choose to change their votes due to the new feedback shared.

It sounds like we didn't get the number of votes needed for a YES to pass, so closing discussion which has been open for a month now. We can always revisit this strategy at a later time if the community wants to. 😸