Kubernetes SIG 文档怎样参与贡献

Kubernetes SIG Docs 负责维护 Kubernetes 的文档与网站。想参与贡献，不需要一开始就承担大型功能文档：先签署 CNCF Contributor License Agreement（CLA），在 kubernetes/website 中找到一个边界清楚的问题，按贡献指南提交 issue 或 PR，再根据评审意见迭代即可。

官方入口：https://kubernetes.io/docs/contribute/docs/

先选对贡献入口：issue、PR 和评审各解决什么

第一次参与最容易走偏的地方，是把“发现问题”和“直接改代码”混成一件事。官方文档把入口分得很清楚：任何人都可以报告文档问题、提交文档 PR、评论已有 PR，也可以参与本地化。

把第一次 PR 收窄到一个可合并的任务

进入 GitHub 后，先检查 kubernetes/website 的 issue 是否已经有人处理。一个好的首 PR 通常只回答一个问题：哪个页面、哪一段文字、为什么需要改，以及改完后读者会少走哪一步弯路。不要为了“看起来改得多”顺手重排整页，也不要只修一条无关紧要的 lint 提示。

可以按下面的顺序准备本地分支：

# 克隆官方文档仓库，准备独立修改空间
git clone https://github.com/kubernetes/website.git
cd website
# 用主题明确的分支承载一个边界清楚的文档任务
git switch -c docs/clarify-service-example
# 修改 Markdown 后检查差异，避免把无关格式变化带入 PR
git diff --check
git diff

提交前还要读贡献指南、Documentation Style Guide 和页面模板。涉及新功能时，文档通常需要和负责该功能的 SIG 协作确认；文档贡献者的价值不是凭空编造说明，而是把已有实现整理成读者能执行的内容。

让 PR 进入 SIG Docs 的维护流程

PR 描述不要只写“修复文档”。更有用的写法是：原页面让哪类读者卡住，改动覆盖哪些文件，是否新增示例，如何检查预览或测试。遇到范围判断、术语或发布分支问题，可以在 Kubernetes Slack 的 #sig-docs 频道提问，也可以关注 SIG Docs 的公开讨论。

评审阶段要区分三个信号：reviewer 给出的 lgtm 表示技术上可以接受，approver 的 approve 才是合并授权，自动化测试和预览则负责发现构建或页面问题。只有这些条件满足，PR 才适合进入合并队列。普通贡献者不需要先获得 reviewer 权限，先把一个具体改动写清楚更重要。

从一次修改走向长期参与

完成首个 PR 后，可以继续做两件事：给其他 PR 留下可验证的语言或事实反馈，或在 issue 中帮助确认复现范围。SIG Docs 的角色是逐步获得的，贡献者、member、reviewer、approver 的责任和权限依次增加。想申请更高角色时，要按社区要求积累实质贡献并寻找合适的 sponsor，不要直接私信某位维护者索要权限。

这里的判断标准很实际：你能否找到正确仓库，能否把一个读者问题缩小到一个文件，能否用文档和预览结果解释修改理由。能稳定做到这三点，就已经完成了从“旁观者”到“可协作贡献者”的关键转换。

相关问题

没有写代码经验，也能参加 SIG Docs 吗？

可以。文档修订、翻译、issue 反馈和 PR review 都是公开的贡献方式，重点是把问题描述和修改建议写具体。

不确定该不该直接开 PR，怎么办？

先开 issue 更稳妥，尤其是新增页面、跨多个章节或涉及功能语义的改动；在 issue 中得到范围确认后再提交实现。

为什么 PR 有了 lgtm 还没有合并？

lgtm 只代表评审信号，通常还需要 approver 的 approve、自动化检查通过，并且没有 hold 等阻止合并的状态。