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

[alequetzalli]

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

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

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

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