search

asyncapi / parser-js

AsyncAPI parser for Javascript (browser-compatible too).
Apache License 2.0
116 stars 91 forks source link

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

Closed quetzalliwrites closed 5 months ago

quetzalliwrites commented 6 months ago

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

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?

🏢 Have you read the Contributing Guidelines?

Are you willing to work on this issue?

Yes I am willing to submit a PR!

github-actions[bot] commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 :v:

smoya commented 5 months ago

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 commented 5 months ago

Just to clarify, I retract my vote. Reasons and discussion regarding my vote retraction can be found in https://github.com/asyncapi/spec-json-schemas/issues/492#issuecomment-2008792063

I believe we can close then this issue.