Divide "Maintainer" role into two categories: Triager and Committer
quetzalliwrites opened this issue · 9 comments
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
/websiteproject, 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!
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.
I love this idea. As a maintainer, this has my +1! 🙌
Pinging other global maintainers of this repo: @derberg @fmvilas @dalelane @char0n @GreenRover
Additionally, once this gets accepted, I volunteer to create the PR with the changes needed in the CODEOWNERS file.
+1
makes sense to me - it could be a useful on-ramp for new members
Yes, that makes sense to me too 👍
Thank you for your votes! It looks like the YES has it, so it certainly makes this repo a great project to test out these new maintainer levels.
@smoya do we have any candidates to become new triagers for this repo? 🤔
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)
Also side note for bindings repo - it is not only decision for core maintainers to do. Sometimes idea for Triager is that they can close issues. Now, bindings repo has 2 level maintainership, and core maintainers should not decide in the name of maintainers of for example sns/sqs bindings.
I retract my vote. Reasons and discussion regarding my vote retraction can be found in asyncapi/spec-json-schemas#492 (comment)
It sounds like we didn't get the number of votes, so this motion won't pass this time around 😸
Closing.