Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
quetzalliwrites opened this issue Feb 29, 2024 · 6 comments
Closed
Labels
enhancement New feature or request stale

Comments

@quetzalliwrites
Copy link
Member

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.

@quetzalliwrites quetzalliwrites added the enhancement New feature or request label Feb 29, 2024
@Amzani
Copy link
Collaborator

Amzani commented Feb 29, 2024

I love this idea @alequetzalli

@Amzani
Copy link
Collaborator

Amzani commented Feb 29, 2024

How and who will be managing permissions? triager/committer

(As a current maintainer - I don't have admin access).

Screenshot 2024-02-29 at 14 06 33

cc @alequetzalli @derberg @fmvilas

Copy link
Member Author

@Amzani As for managing permissions, I would assume only the higher level of commiters, but unsure of who exactly has those permissions. 🤔 Perhaps the others know more.

  • committers will be granted write permissions.
  • triagers will only be granted read permissions.

Copy link
Collaborator

Amzani commented Mar 7, 2024

@alequetzalli @derberg
I didn't see any description of higher level of commiters, for me it's still unclear how these permissions will be managed.
For example, I'm a studio maintainer but unable to manage this kind of permission as I mentioned.

Copy link
Member Author

Honestly, I have the same question as you! 😁 (FYI, higher level of committers is just a phrase I wrote myself, it's not an actual term we've using.. feel free to ignore my phrasing if I confused you heh)

I do not know who has the repo settings permission access, I genuinely would like the answer to that question myself.

@fmvilas @magicmatatjahu @derberg Can one of your folks please clarify who has these permission settings in this repo and who/why is awarded that admin access?

Copy link

github-actions bot commented Jul 7, 2024

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

@github-actions github-actions bot added the stale label Jul 7, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request stale
Projects
Status: Done
Development

No branches or pull requests

2 participants