Hi all,

I find it's hard sometimes to handle situations in code-review, something likes solving conflicts while not upsetting developers, or suggesting a change to a patchset while still encouraging the committer, etc. I know there are already documents that guide us on how to do a code-review [2] and even projects develope their own procedures but I find they're more about technical issues rather than human communication. Currently reading Google's code-review practices [1] give me some inspiration to develop more human-centric code-review guidelines for OpenStack projects. IMO, it could be a great way to help project teams develop stronger relationship as well as encouraging newcomers. When the document is finalized, I then encourage PTLs to refer to that document in the project's docs.

Let me know what you think and I will put a patchset after one or two weeks.

[1] https://google.github.io/eng-practices/review/

[2] https://docs.openstack.org/project-team-guide/review-the-openstack-way.html

[3] https://docs.openstack.org/doc-contrib-guide/docs-review.html

[4] https://docs.openstack.org/nova/rocky/contributor/code-review.html

[5] https://docs.openstack.org/neutron/pike/contributor/policies/code-reviews.html