Question about the gRFC review process

[philwo]

Hi gRPC folks,

the Bazel team is considering adopting the gRFC workflow to do design reviews. One thing I was wondering about was this part:

Once the APPROVER is assigned, the OWNER needs to start a discussion on grpc-io and update the PR with the discussion link. After this is done, the OWNER should update the gRFC to the state of In Review. It is expected that the APPROVER will help the OWNER along this process as needed.

Question: Why do you separate discussions of the gRFC from the PR and handle them via the mailing list? On a first look, it seems like if you'd do them directly on the PR, you could refer to individual parts of the doc more easily. However, I'm sure you thought this through and have some experience in how these discussions go and thus, why mailing lists are preferable for this.

Could you explain the reasoning behind this, so that we can learn from it?

[carl-mastrangelo]

cc: @hsaliak

Hi, Kailash and I came up with the gRFC process. The reason is practical: Github's commentary system is difficult to use. There are no threaded conversation aspects, and individual messages cannot be easily linked to. Additionally, if the author rebases the PR while making updates, the commentary is completely lost (except if you saved the emails). Rebasing also happens at the end of the PR sometimes, which means if you squash and merge, all the commentary is lost.

If there was a system like Google's internal code review tools, I think this wouldn't be an issue.

Hope that helps, let me know if you have more questions.

[hsaliak]

I'd add one more minor reason. We want the mailing list to be something users can follow to be on top of discussions around the project. Following pull requests in this repo to be on top of what is happening adds one more location for users to follow..

[philwo]

Thank you very much, @carl-mastrangelo @hsaliak - that helps a lot :)