On assigning patch reviewers

[dahlia]

We currently use the .github/auto_assign.yml facility to automatically assign pull requests to reviewers. However, as our code base is getting bigger and more complicated, and as our team is getting to have more people, it's apparently starting not working due to several reasons:

• Diffusion of responsibility: Everybody is responsible, but we wish someone else would review. As a result, no one actually review.
• Overload: Too many review requests are in the inbox. Reviewers hardly figure out where to start.

To fix this situation, I want to propose to make reviewers settings (in .github/auto_assign.yml) empty, and assign reviewers manually (or in any other automated way). There could be many other ways to assign reviewers, for example:

• Maintaining CODEOWNERS list might alleviate diffusion of responsibility.
• Or, it might be better to let the manager (@longfin) assigns each pull request to the most appropriate reviewers. He also could adjust the schedule for code reviews with a high priority.
• Instead, we could adopt round-robin assignment of reviewers. This way would require the smallest change to our process, because it can be implemented by just configuring non-zero numberOfReviewers in .github/auto_assign.yml.

Those ideas are not mutually exclusive, so we could mix some of multiple ideas. For example, .github/auto_assign.yml apparently considers CODEOWNERS too.

Hope to listen to your opinions on this proposal.

[greymistcube]

To fix this situation, I want to propose to make reviewers settings (in .github/auto_assign.yml) empty, and assign reviewers manually

This would be the easiest fix, and IMO still be better than the current situation. 🙂
We could clear out .github/auto_assign.yml first and further discuss an review assignment scheme.

[dahlia]

@planetarium/libplanet I made a pull request to make reviewers empty: #2276. Please take a look!

[riemannulus]

We currently use the .github/auto_assign.yml facility to automatically assign pull requests to reviewers. However, as our code base is getting bigger and more complicated, and as our team is getting to have more people, it's apparently starting not working due to several reasons:

말씀하신 문제에 대해서는 공감하고 있습니다.

• reviewers 설정을 비워 두는 것은 좋은 아이디어로 보입니다
• 리뷰어를 직접 지정하는 것도 좋은 아이디어로 보입니다
  팀 규모가 커짐에 따라, 모든 팀원이 libplanet의 모든 번경사항을 파악하고 있는 것을 불가능한 일이라고 여겨집니다.

Maintaining CODEOWNERS list might alleviate diffusion of responsibility.

CODEOWNERS를 관리하는 점에 있어서는 이점을 잘 모르겠습니다. 단순히 CODEOWNERS 에 적힌 사람을 리뷰어로 거는 것을 생각하고 계신 걸까요?

현재 저희의 개발 프로세스인 스프린트 단위의 개발방법 상 같은 스프린터를 수동으로 리뷰어 지정하는 것은 어떨까 제안해 봅니다.

[dahlia]

CODEOWNERS를 관리하는 점에 있어서는 이점을 잘 모르겠습니다. 단순히 CODEOWNERS 에 적힌 사람을 리뷰어로 거는 것을 생각하고 계신 걸까요?

CODEOWNERS 리스트 만들면 PR 만들 때 알아서 알맞는 코드 오너한테 리뷰어 할당이 됩니다. (제 기억이 맞다면 선택 해제도 안 됐던 것 같습니다.)

[longfin]

• First of all, I agree about automatic assigning has negative impact.
• About CODEOWNERS features, I don't have stong opinion now.
  • but it may hard to adopt on our situation because its rules aren't appropriate enough to represent our expertise.
• As short-term solution, +1 to the idea that choosing reviewer by PR author's hand. (if maintainer's PR)
  • Of course, it can't be applied for all contributors due to lack of permission and knowledge.
  • In that case, we need to assign someone as router/moderator, and they need to find and assign the appropriate reviewer.
    • At this moment, I think that it's fine since there're only small contributions from outside... 😢
    • But it isn't sustainable solution. 😅
• On the other hands, just checking the list of opened PRs during daily check-in may help this situation (if we simply just forgot).
  • I'll start mentioning from tomorrow (regardless other solutions)

[riemannulus]

해당 안은 현재 리뷰어를 직접 지정하는 것으로 변경되었으며 이에 따라 종료하겠습니다.