[GitHub] [tvm] hogepodge commented on issue #9057: [VOTE] Adopt round-robin assignment of reviewers for GitHub pull request reviewer assignment.

[GitBox <gi...@apache.org>]

hogepodge commented on issue #9057:
URL: https://github.com/apache/tvm/issues/9057#issuecomment-931595264


   +0 as someone who is not actively reviewing a large body of code, I don't have a strong opinion on if this is the right move. It's clear that the current "tag all code owners" is not workable, and I fully support removing that. To me the big questions is: how do we fairly allocate work amongst the community and code owners. We can look at how other communities have handled this.
   
   O1) Within the Kubernetes community, code ownership is allocated to Special Interest Groups, and SIG leaders are round-robin allocated to review code under their ownership. Other reviewers can be automatically added also based on codeowners files, and reviewers and assignees can be manually added through tags to bots.
   O2) The Rust community allows for volunteers to join a "high five" program that automatically round robin assigns them for code review. It's opt-in, and is a way to gain experience and merit within the community.
   
   Echoing what @areusch was saying, since every pull request needs a review from a committer to merge, I feel we need a way to allocate committers, but it does no good if committers have become inactive and we're just spamming them. Going back to Kubernetes as an example, their three-month release cycle creates a natural period of time where contributors can volunteer for work but be able to step back gracefully if work or personal demands take them away from the project. Looking at O2, I could imagine a quarterly "call for reviewers" to give us space to build an equivalent of that "high five" list, and for the PMC to review contributions by community members and identify who is active, and who is inactive.
   
   Within a community ladder I like to think of what roles and responsibilities people have to be regarded as active in the community. For example, an active reviewer or committer should be maintaining a certain level of reviews, and similarly somone who is not an active reviewer but wants to be promoted should be able to demonstrate an ability to do that. This is somewhat at odds with The Apache Way of doing things, but in my mind it helps to distinguish between active an inactive, as it helps the community in general identify who is there to help, and how to share the work amongst them.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@tvm.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org