83 lines
2.7 KiB
Markdown
83 lines
2.7 KiB
Markdown
|
# 如何让你的拉取请求获得审阅？
|
|||
|
|
|
|||
|
|
有时我们发布了拉取请求，却无人[审阅](/docs/contributors/repository-management.md#code-review)我们的工作。该怎么办？
|
|||
|
|
|
|||
|
|
吸引审阅主要不在于代码本身——而在于让审阅过程变得轻松。
|
|||
|
|
|
|||
|
|
如果你发布的拉取请求未获得任何评论或审阅，可以尝试核心贡献者们使用的策略：
|
|||
|
|
|
|||
|
|
## 创建最合理的精简PR
|
|||
|
|
|
|||
|
|
审批一个2000行的PR需要数月时间且令人望而生畏。
|
|||
|
|
|
|||
|
|
审批一个50行的PR仅需数日或数小时且轻松自如。
|
|||
|
|
|
|||
|
|
大规模提交会拖慢进度。将工作拆分成小模块进行提交，才能更快合并代码、加速学习进程。
|
|||
|
|
|
|||
|
|
## 提供相关背景信息：
|
|||
|
|
|
|||
|
|
请阐明：
|
|||
|
|
* 你要解决什么问题？
|
|||
|
|
* 你的PR如何解决该问题？
|
|||
|
|
* 你需要什么反馈？
|
|||
|
|
* 哪些内容不在讨论范围？
|
|||
|
|
* 哪些设计不符合直觉？
|
|||
|
|
* 如何进行测试？
|
|||
|
|
|
|||
|
|
总结所有相关议题和PR。
|
|||
|
|
|
|||
|
|
这比让他人自行摸索要简单得多。
|
|||
|
|
|
|||
|
|
## 让你的PR引人注目
|
|||
|
|
|
|||
|
|
所有贡献都在争夺注意力。让你的作品脱颖而出。
|
|||
|
|
|
|||
|
|
最简单的方法？说明其重要性：
|
|||
|
|
|
|||
|
|
❌ 一个获取数据的新React钩子
|
|||
|
|
✅ `useEntityRecord`：用减少90%模板代码的方式获取数据
|
|||
|
|
|
|||
|
|
然后用代码示例、可视化效果和屏幕录像证明其价值。
|
|||
|
|
|
|||
|
|
## 展示你的工作
|
|||
|
|
|
|||
|
|
在相关议题和PR中发布你的PR链接。
|
|||
|
|
|
|||
|
|
提醒相关议题的评论者、先前提交者和技术负责人关注。
|
|||
|
|
|
|||
|
|
在WordPress.org Slack的#core-editor频道中提出。获取反馈最便捷的方式是在每周[核心编辑器会议](/docs/getting-started/README.md)的[自由发言环节](https://make.wordpress.org/core/tag/core-editor-agenda/)主动发声。
|
|||
|
|
|
|||
|
|
分配相关标签、里程碑和项目（或请他人协助分配）。
|
|||
|
|
|
|||
|
|
## 审阅他人的工作
|
|||
|
|
|
|||
|
|
这是进入他人视野的最简单途径。
|
|||
|
|
|
|||
|
|
查阅相关议题评论者、先前提交者和技术负责人的PR，然后进行审阅。
|
|||
|
|
|
|||
|
|
对他们的工作不熟悉？可以：
|
|||
|
|
|
|||
|
|
* 花时间理解内容
|
|||
|
|
* 提议结对编程环节
|
|||
|
|
* 跳过此项，审阅下一个PR
|
|||
|
|
|
|||
|
|
## 通过清晰表述降低风险
|
|||
|
|
|
|||
|
|
风险会增加阻力——当前的批准可能在日后产生反效果。
|
|||
|
|
|
|||
|
|
清晰的阐述如同润滑剂。请明确记录：
|
|||
|
|
|
|||
|
|
* 涉及哪些风险？为何要承担这些风险？
|
|||
|
|
* 为何此PR是最佳解决方案？
|
|||
|
|
* 如何将风险最小化？
|
|||
|
|
* 已尝试过哪些其他方案？
|
|||
|
|
|
|||
|
|
## 关注热点领域
|
|||
|
|
|
|||
|
|
某些PR天然比其他PR更容易获得关注。
|
|||
|
|
|
|||
|
|
请重点投入这些领域。
|
|||
|
|
|
|||
|
|
部分议题比其他议题更具时效性（例如列入下一版发布目标的议题），因此能获得更多关注。专注于这些议题将更容易吸引审阅者。
|
|||
|
|
|
|||
|
|
如何快速切入？参与WordPress路线图中的活跃项目提供协助
|