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 maintainers of this repo: @magicmatatjahu @jonaslagoni

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

[jonaslagoni]

I completely disagree with splitting Triager and Committer, a maintainer always falls within both these categories as I don't believe you can be one and not the other.

I get that it worked on the website with the amount of issues and PRs and the nature of what needs to be done. I don't believe it's a good fit for the parser.

[smoya]

a maintainer always falls within both these categories as I don't believe you can be one and not the other.

Can you elaborate this?

In my experience, I see we (current maintainers) usually expend time jus triaging issues (checking the issue is still happening, adding the right labels, etc, etc) that many more others can do, those that still don't feel comfortable or don't have time yet for actually fixing the bug or working on the feature, etc.

BTW, I understand a Committer can do both roles eventually, but Triagers would help first by paving the way

[jonaslagoni]

Because I dont think that a Triager can triage an issue nor start to figure out what is needed, without having in-depth knowledge of the implementation. I think it creates a push-and-forth workflow actually creating more work for maintainers (committers or what we can call them).

I understand it worked in the website, but its nature is very different than a library.

[smoya]

I understand your point. However, this is a really great suggestion that won't break anything in how maintainers keep reviewing issues.

Let me use an example. The following unlabeled issue, which is atm the most recent issue opened, mentions an unexpected behavior when getting operations from a doc.
We do not have info about what version of the parser is using (we can guess), and we didn't verify the issue still persists in the latest version.
The triager can help with that, by asking the user to provide more info if needed and additionally verify the issue persists. If confirmed, label the issue with bug label and ping, if needed (if urgent, etc) directly maintainers.

[jonaslagoni]

I understand your point. However, this is a really great suggestion that won't break anything in how maintainers keep reviewing issues.

It has nothing to do with breaking, but everything to do with restructuring how we maintain projects. So far I am not convinced or seen enough evidence that this change will work as intended here. I see this proposal has been made in multiple repositories, let's use those who believe it works to verify it and if we have good experiences across two or more repos then we can try it out ✌️

[smoya]

I understand your point. However, this is a really great suggestion that won't break anything in how maintainers keep reviewing issues.

It has nothing to do with breaking, but everything to do with restructuring how we maintain projects. So far I am not convinced or seen enough evidence that this change will work as intended here. I see this proposal has been made in multiple repositories, let's use those who believe it works to verify it and if we have good experiences across two or more repos then we can try it out ✌️

That's actually a good suggestion. No need to implement this in all the repositories, and as always if in doubt, let's discard this for this repo and wait for other success use cases.

Anything else you wanna add @magicmatatjahu to this (as the other maintainer of this repo)? Otherwise, we close it.

[smoya]

Just to clarify, I retract my vote. Reasons and discussion regarding my vote retraction can be found in asyncapi/spec-json-schemas#492 (comment)

I believe we can close then this issue.