[PATCH 3/5] docs/zh_CN: update the translation of process/7.AdvancedTopics.rst

[Dongliang Mu]

Update to the commit 6e55b1cbf05d ("docs: try to encourage (netdev?)
reviewers")

scripts/checktransupdate.py reports:

Documentation/translations/zh_CN/process/7.AdvancedTopics.rst
commit 6e55b1cbf05d ("docs: try to encourage (netdev?) reviewers")
1 commits needs resolving in total

Signed-off-by: Dongliang Mu <dzm91@xxxxxxxxxxx>
---
 .../zh_CN/process/7.AdvancedTopics.rst             | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst b/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst
index 57beca02181c..92cc06dd5f4e 100644
--- a/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst
+++ b/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst
@@ -113,6 +113,8 @@ Git提供了一些强大的工具，可以让您重写开发历史。一个不
 更改。在这方面 git request-pull 命令非常有用；它将按照其他开发人员所期望的
 格式化请求，并检查以确保您已记得将这些更改推送到公共服务器。
 
+.. _cn_development_advancedtopics_reviews:
+
 审阅补丁
 --------
 
@@ -126,8 +128,20 @@ Git提供了一些强大的工具，可以让您重写开发历史。一个不
 的建议是：把审阅评论当成问题而不是批评。询问“在这条路径中如何释放锁？”
 总是比说“这里的锁是错误的”更好。
 
+当出现分歧时，另一个有用的技巧是邀请他人参与讨论。如果交流数次后讨论陷入僵局，
+可征求其他评审者或维护者的意见。通常，与某一评审者意见一致的人往往会保持沉默，
+除非被主动询问。众人意见会产生成倍的影响力。
+
 不同的开发人员将从不同的角度审查代码。部分人会主要关注代码风格以及代码行是
 否有尾随空格。其他人会主要关注补丁作为一个整体实现的变更是否对内核有好处。
 同时也有人会检查是否存在锁问题、堆栈使用过度、可能的安全问题、在其他地方
 发现的代码重复、足够的文档、对性能的不利影响、用户空间ABI更改等。所有类型
 的检查，只要它们能引导更好的代码进入内核，都是受欢迎和值得的。
+
+使用诸如 ``Reviewed-by`` 这类特定标签并无严格要求。事实上，即便提供了标签，也
+更鼓励用平实的英文撰写评审意见，因为这样的内容信息量更大，例如，“我查看了此次
+提交中 A、B、C 等方面的内容，认为没有问题。”显然，以某种形式提供评审信息或回复
+是必要的，否则维护者将完全无法知晓评审者是否已查看过补丁！
+
+最后但同样重要的是，补丁评审可能会变成一个聚焦于指出问题的负面过程。请偶尔给予
+称赞，尤其是对新手贡献者！
-- 
2.43.0