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

[alequetzalli]

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.

[smoya]

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

Pinging other 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.

[derberg]

I do not think it is good solution for this repository.

Same for bindings and spec-json-schemas.

All these 3 are interconnected - if someone becomes a maintainer in spec, they are also maintainers in bindings an spec-json-schemas. This is a complex setup, not as simple as in website or asyncapi-react repos.

also, stuff we started in website is pretty fresh, and we do not even know if it works: asyncapi/asyncapi-react#928 (comment)

In my opinion we need a different approach here and in related repos. Maintainers should be responsible for triage to give proper attention of someone who is experienced with AsyncAPI:

• we can do triage duty schedule, every month different maintainer does triage, and than hands over to another one with report of issues that were closed or something like that
• we can have a regular monthly triage call that would actually put us in sync and enable more regular and proactive approach to minor releases
• maybe we even should consider merging bindings, spec-json-schemas and even extensions-catalog into spec repo. We discarded it some time ago and pulled spec-json-schemas outside spec because we were afraid of complexity of releases but I think recent years showed, we did not remove release complexity and only introduced maintenance complexity

spec is the backbone on AsyncAPI Initiative and if we want to make changes like that, I prefer to have a meeting first and discussion.

And if you still want Triagers and Committers then please provide examples how that would look like. Is there even a candidate that we could onboard? and would that be triager for all repos? what about bindings, where we have "champions-like" setup similar to Modelina. I just do not see what problem it is solving.

[alequetzalli]

we did not remove release complexity and only introduced maintenance complexity

😆

All these 3 are interconnected - if someone becomes a maintainer in spec, they are also maintainers in bindings an spec-json-schemas.

Ahh, got it, makes complete sense why you don't feel it's a similar example to the website repo. Def more complex.

side note... @derberg it sounds like you lost enthusiasm in your triager/committer proposal idea, do you regret proposing it originally for website repo? hehe 😄

[smoya]

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

[derberg]

side note... @derberg it sounds like you lost enthusiasm in your triager/committer proposal idea, do you regret proposing it originally for website repo? hehe 😄

no, I love it, I just do not think it is a silver bullet solution for all. And anyway, we just started in website, we need to see some numbers, get feedback from participants, etc and then we can promote it

[alequetzalli]

It sounds like we didn't get the number of votes, so this motion won't pass this time around 😸

Closing.