这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

为 Kubernetes 博客做贡献

Kubernetes 有两个官方博客，同时 CNCF 也有其自己的博客， 你也可以在 CNCF 博客上面撰写 Kubernetes 相关内容。对于 Kubernetes 主博客， 我们（Kubernetes 项目）希望发布具有不同视角和特定关注点的文章，这些文章需与 Kubernetes 有所关联。

除极少数特殊情况外，我们只发布未在其他任何地方提交过或发表过的内容。

参阅博客指南了解更多相关要求。

Kubernetes 官方博客

主博客

Kubernetes 主博客由 Kubernetes 项目组发布新特性、社区报告以及可能与 Kubernetes 社区相关的所有新闻。这些内容面向终端用户和开发者。 大部分博客的内容围绕核心项目展开，但 Kubernetes 作为一个开源项目，也鼓励大家提交关于生态系统中其他方面的内容！

任何人都可以撰写博文并提交发布。除极少数特殊情况外，我们仅发布未在其他任何地方提交过或发表过的内容。

贡献者博客

Kubernetes 贡献者博客面向的是参与 Kubernetes 的开发者， 而非使用 Kubernetes 的用户。Kubernetes 项目会有意同时在两个博客上都发布某些文章。

任何人都可以撰写博文并提交审核。

文章更新与维护

Kubernetes 项目不维护博客中较旧的文章。这意味着， 任何发布超过一年的文章通常不接受提交要求修改的 Issue 或 PR。 为了避免形成惯例，这种即使从技术角度看正确的 PR 也可能会被拒绝。

但以下情况是例外：

  • （更新）标记为 Evergreen 的文章
  • 移除或更正已被证明错误且可能导致危险操作的文章
  • 一些修复工作，确保现有文章的渲染仍然正确

对于超过一年且未标记为 Evergreen 的文章，网站会自动显示一条通知，提醒读者内容可能已经过时。

Evergreen 文章

你可以在文章的 front matter 中添加 evergreen: true 将某篇文章标记为 Evergreen（长期维护）。

只有当 Kubernetes 项目承诺长期维护某篇博文时，我们才会将其标记为长期维护 （即在 front matter 中设置 evergreen: true）。 有些博文确实值得长期维护，例如 Kubernetes 发布公告通常都会由 Release Comms Team（发布沟通团队）标记为 Evergreen。

接下来

1 - 给 Kubernetes 博客提交文章

Kubernetes 有两个官方博客，CNCF 也有自己的博客频道，你也可以在 CNCF 博客频道上发布与 Kubernetes 相关的内容。对于 Kubernetes 主博客， 我们（Kubernetes 项目组）希望发布与 Kubernetes 有关联的具有不同视角和独特关注点的文章。

除非有特殊情况，我们只发布尚未在其他任何地方投稿或发布的内容。

为 Kubernetes 博客撰写文章

作为一名作者，你有三个渠道来发表文章。

推荐的渠道

Kubernetes 项目推荐的方式是：联系并向博客团队投稿。你可以通过 Kubernetes Slack 频道 #sig-docs-blog 联系他们。 如果你希望文章仅发布在贡献者博客上，也可以直接向 SIG ContribEx 委员会投稿。

除非你的投稿有问题，否则博客团队或 SIG ContribEx 会为你分配：

  • 一位博客编辑
  • 一位写作搭档（另一位博客作者）

之所以为你分配另一位作者配对，是为了让你们互相支持，互相审阅彼此的文章草稿。 你并不需要非得是某个主题类的专家；大多数读者也不是专家。 Kubernetes 博客团队把为你分配的另一位作者称为“写作搭档”。

编辑会协助你完成从草稿到发表的整个过程。他们可以直接批准文章发布，或安排他人进行批准。

参阅撰写博客文章以了解更多流程信息。

渠道 2：提交 PR

第二种撰写博客的渠道是直接在 GitHub 提交 PR。 不过博客团队并不推荐这种方式；GitHub 很适合协作开发代码，但不太适合处理纯文本写作。

你完全可以先提交一个不包含任何 Commit 的占位 PR，然后在其他地方写好后再把文章推送到此 PR。

与推荐渠道类似，我们会尝试为你配对一位写作搭档和一位博客编辑。 他们会协助你让文章达到发布就绪的状态。

渠道 3：发版后的博文流程

第三种渠道适合 Kubernetes 新版本发版时讲述版本变更的博客文章。 Kubernetes 每次发版时，Release Comms 团队会接手管理博客发布日程。 如果你是为某个版本添加特性的人员或计划发布项目所需其他变更的人员， 可以联络 Release Comms，规划、撰写、编辑并最终发布博客文章。

文章时间安排

对于 Kubernetes 博客，博客团队通常安排在工作日（美国等国家使用的公历）发布文章。 如果很重要，有必要在周末发布文章，博客团队会尽力配合。

在撰写博客文章一节中说明了：

  • 起初无需指定文章的发布日期
  • 但需要将文章标记为 Draft（在 Front Matter 中添加 draft: true）

当 Prow 机器人处理你提交的 PR 时，起初它是一个 Draft（草稿），不会设置为待发布。 随后 Kubernetes 的一名贡献者（你、你的写作搭档或博客团队的其他人）会提交一个小的跟进 PR，将你的 PR 标记为待发布。 Prow 机器人接受第二个跟进 PR 后会修改之前标记为 Draft 的文章状态，这样你的 PR 就可以自动发布。

到了文章计划发布的那一天后，自动化流程会触发网站构建，让你的文章对大众可见。

撰写文章

在你投稿之后，我们会鼓励你使用 HackMD（一种 Web 版 Markdown 编辑器）或 Google 文档来分享可编辑版本的文章。 你的写作搭档可以阅读你的草稿文字，并直接提出建议或反馈。 如果你写的内容不符合博客指南，他们也会指出来。

同时，你通常也会是他们的写作搭档， 可以参考我们的写作搭档指南支持他们的工作。

初始管理步骤

如果你尚未签署 CLA，应当先签署 CLA。 最好尽早完成 CLA 的签署。如果你是在工作岗位上把撰写文章作为一部分工作， 你可能需要与公司法律团队或上级主管确认你是否允许签署 CLA。

草拟初稿

博客团队建议你使用 HackMD（一个 Web 版的 Markdown 编辑器）或 Google 文档来准备和分享可编辑版本的文章初稿。

你的写作搭档可以对你的草稿文字进行评论和反馈，并检查是否符合博客指南。 与此同时，你也是他们的写作搭档， 参考编辑指南了解如何支持搭档的工作。

你在这个阶段无需顾虑 Markdown 格式是否完美。

如果有图片，你可以粘贴位图副本获取初期反馈。博客团队会（在后续流程中）协助你让插图达到最终发布状态。

Markdown 发布

你可以参考 GitHub 中已有博客文章的 Markdown 格式： 网站仓库。

如果你还不熟悉，参阅贡献基本知识。 本节假设你没有本地克隆的 Fork，假设你是通过 GitHub 网页 UI 操作的。 如果你还未这样操作，你需要先远程 Fork 网站仓库。

在 GitHub 仓库中，点击 Create new file 按钮。 复制 HackMD 或 Google Docs 上写好的内容，粘贴到编辑器中。 下文会说明有关如何进入该文件的更多细节。 此文件的命名应与拟定的博客文章标题相匹配，但不要在文件名中包含日期。 博客审阅人员会与你一起确定最终文件名和文章发布日期。

  1. 你在保存文件时，GitHub 会引导你完成 PR 流程。

  2. 你的写作搭档会审阅你提交的 PR，并与你协作处理反馈和最终细节。 博客编辑会将你的 PR 作为未排期的草稿批准合并。

Front Matter

你撰写的 Markdown 文件应使用 YAML 格式的 Hugo Front Matter。

以下是一个例子：

---
layout: blog
title: "你的文章标题"
draft: true # 发布前会改为 date: YYYY-MM-DD
slug: 小写文字组成的不含空格的链接放在这里 # 可选
author: >
  作者 1（所属机构）,
  作者 2（所属机构）,
  作者 3（所属机构）  
---
  • 起初无需指定文章的发布日期
  • 但需要将文章标记为 Draft（在 Front Matter 中添加 draft: true）

正文内容

确保使用二级 Markdown 标题（##，不要用 #）作为正文的最顶级标题。 你在 Front Matter 中设置的 title 会作为该页面的一级标题。

你应遵循风格指南，但以下例外：

  • 我们允许作者采用自己的写作风格，只要大多数读者能理解要点就行。
  • 对于有多位作者的博客文章，或文章开头已明确说明是代表某组织撰写的，可以使用“我们”。 如本节所见，虽然我们在文档中不推荐使用“我们”这样的表述， 但也可以有一些例外。
  • 避免使用 Kubernetes 短代码（如 {{< caution >}}）做提醒。 这是因为提醒主要面向的是文档读者，而博客文章并不是文档。
  • 对未来的预测性陈述是允许的，但代表 Kubernetes 的官方公告中应慎用。
  • 博客文章中所用的代码示例无需使用 {{< code_sample >}} 短代码，通常直接展示更便于维护。

图表与插图

如使用图表、插图或图示，推荐使用 figure shortcode。 你应该设置 alt 属性以避免访问速度不佳的问题。

对于插图或技术图表，应尽量使用矢量图。 博客团队推荐使用 SVG，而非光栅（位图）格式或 Mermaid（但你可以将 Mermaid 源代码作为注释保留）。 我们倾向于 SVG 而非 Mermaid，是因为当维护者升级 Mermaid 或调整图表渲染时，往往无法联系到原文作者确认变更是否合适。

图表指南主要面向 Kubernetes 文档，而非博客文章。 你可以参考，但：

  • 无需为图表编号（如图 1、图 2 等）

因为矢量图要求较高，可能对不熟悉流程的投稿人造成困难； Kubernetes SIG Docs 正在寻找降低门槛的方法。 如果你有降低门槛的好主意，欢迎志愿者帮助解决这个问题。

对于照片等其他图像，博客团队强烈建议使用 alt 属性。 如果不希望辅助工具读出图片内容，也可以使用空的 alt 属性，但这种情况较少见。

Commit 消息

当你标记 PR 为“Ready for review”时，每条 Commit 消息应简明总结工作内容。 第一条 Commit 消息应能大致描述整篇博文内容。

良好的 Commit 消息示例：

  • Add blog post on the foo kubernetes feature
  • blog: foobar announcement

不好的 Commit 消息示例：

  • Placeholder commit for announcement about foo
  • Add blog post
  • asdf
  • initial commit
  • draft post

压缩 Commit

当你认为文章已准备好合并时，应压缩（Squash） PR 中的 Commit。如果你不清楚如何操作，可以请博客团队协助。

2 - 博客指南

这些指南涵盖了 Kubernetes 主博客和 Kubernetes 贡献者博客。

所有博客内容还必须遵循内容指南中的总体政策。

准备开始

确保你熟悉为 Kubernetes 博客贡献内容的介绍部分， 不仅是为了了解两个官方博客及其之间的区别，也是为了对整个过程有一个概览。

Kubernetes 项目仅接受原创内容，且必须为英文。

这一限制甚至延伸至推广其他 Linux 基金会和 CNCF 项目。 许多 CNCF 项目都有自己的博客。对于特定项目的帖子，这些博客通常是更好的选择， 即使那个其他项目是专门为与 Kubernetes （或与 Linux 等）协同工作而设计的。

相关内容

文章必须包含适用于整个 Kubernetes 社区的内容。例如，投稿应侧重于上游 Kubernetes，而不是特定供应商的配置。 对于提交到主博客且不是镜像文章的文章， 文章中的超链接应通常指向官方 Kubernetes 文档。 在进行外部引用时，链接应该是多样的 - 例如，投稿不应只包含返回单个公司博客的链接。

官方 Kubernetes 博客不是进行供应商宣传或推广 Kubernetes 外部特定解决方案的地方。

有时，这之间的平衡很微妙。你可以在 Slack （#sig-docs-blog） 上询问某篇文章是否适合发布在 Kubernetes 博客和/或贡献者博客 - 不要犹豫，随时联系。

内容指南无条件适用于博客文章及其添加的 PR。 请记住，指南中的一些限制仅与文档相关；那些标记的限制不适用于博客文章。

本地化

网站已被本地化为多种语言；英文是所有其他本地化的“上游”。即使你懂另一种语言并愿意提供本地化， 这也应该是一个单独的 PR（参见每个 PR 的语言）。

版权和重用

你必须编写原创内容， 并且你必须拥有将该内容授权给云原生计算基金会（Cloud Native Computing Foundation） 的权限（这样 Kubernetes 项目才能合法发布它）。 这意味着不仅直接抄袭是被禁止的，如果你没有权限满足 CNCF 版权许可条件 （例如，如果你的雇主有关于知识产权的政策限制了你能做的事情）， 你也不能撰写博客文章。

license 允许将博客的内容用于商业目的，但反之则不然。

特别兴趣小组和工作组

与参与 Kubernetes SIG 活动或其成果相关的主题总是合适的 （参见贡献者通讯团队中的工作以获得这些帖子的支持）。

该项目通常会将这些文章镜像到两个博客上。

国家对内容的限制

Kubernetes 网站拥有中国政府颁发的互联网内容提供者（ICP）许可证。 Kubernetes 不能发布那些会被中国政府官方网络内容过滤系统阻止的文章 （尽管这种情况不太可能发生）。

博客特定内容指南

除了通用的风格指南外， 博客文章应该（但不是必须）遵循 博客特定风格建议。

本页面其余部分为附加指南；这些并不是文章必须遵守的严格规则，但如果文章明显不符合这里的建议， 审稿人可能会（也应该）要求对文章进行编辑。

图表和插图

对于插图 —— 包括图表或图形 —— 在可行的情况下，使用图形简码。 你应该设置一个alt属性以提高可访问性。

使用矢量图像进行插图、技术图表和类似图形；强烈建议使用 SVG 格式。

使用光栅图像进行插图的文章更难以维护，在某些情况下， 博客团队可能会要求作者在文章可以发布之前进行修改。

时效性

博客文章应力求面向未来：

  • 鉴于项目的开发速度，SIG Docs 倾向于 timeless 写作：即不需要更新就能保持准确的内容。
  • 相较于撰写高层次概述的博客文章，添加教程或更新官方文档可能是更好的选择。
  • 考虑将长技术内容集中在博客文章的呼吁行动中，并关注问题空间或为什么读者应该关心。

内容示例

以下是一些适合 主 Kubernetes 博客的内容示例：

  • 关于 Kubernetes 新功能的公告
  • 解释如何使用 Kubernetes 实现某个目标；例如，告诉我们你在基本滚动更新想法上的低操作改进
  • 比较几个与 Kubernetes 和云原生有关的不同软件选项。可以提及其中一个选项的链接，但必须充分披露你的利益冲突/关系。
  • 讲述问题或事件的故事，以及你是如何解决它们的
  • 讨论构建针对特定用例的云原生平台的文章
  • 你对 Kubernetes 的优缺点的看法
  • 关于非核心 Kubernetes 的公告和故事，例如 Gateway API
  • 发布后公告和更新
  • 关于重要的 Kubernetes 安全漏洞的消息
  • Kubernetes 项目更新
  • 教程和操作指南
  • 围绕 Kubernetes 和云原生的思想领导力
  • Kubernetes 的组件是故意设计成模块化的，因此撰写关于现有集成点的文章 （如 CNI 和 CSI）是相关的。只要你不是在写供应商宣传，你也可以写这些集成的另一端是什么。

这里有一些适合 Kubernetes 贡献者博客的内容示例：

  • 关于如何测试你对 Kubernetes 代码的更改的文章
  • 围绕非代码贡献的内容
  • 讨论设计仍在讨论中的 alpha 特性的文章
  • “认识团队”文章，介绍工作组、特别兴趣小组等
  • 关于如何编写将成为 Kubernetes 一部分的安全代码的指南
  • 关于维护者峰会及其成果的文章

不会被接受的内容示例

然而，项目不会发布：

  • 供应商宣传
  • 你在其他地方已发布过的文章，即使是发布在你自己的低流量博客上
  • 仅有少量解释的大段示例源代码
  • 关于外部项目的更新，如果该项目依赖于 Kubernetes（请将这些内容发布在外项目自己的博客上）
  • 关于与特定云提供商一起使用 Kubernetes 的文章
  • 批评特定人士、人群或企业的文章
  • 包含重要技术错误或误导性细节的文章（例如： 如果你建议在生产集群中关闭一个重要安全控制，因为其可能带来不便， Kubernetes 项目可能会拒绝该文章）

3 - 博客文章镜像

官方有两个 Kubernetes 博客，CNCF 也有自己的博客，你也可以在其中了解 Kubernetes。
对于主要的 Kubernetes 博客，我们（Kubernetes 项目）喜欢发表具有不同视角和特别焦点的文章， 这些文章与 Kubernetes 有一定的关联。

有些文章会同时出现在两个博客上：一篇文章是主要版本，另一篇是另一个博客上的镜像文章。

本文介绍了镜像的标准、镜像的动机，并解释了你应该做什么来确保文章发布到两个博客。

准备开始

请确保你已熟悉为 Kubernetes 博客贡献内容的介绍部分， 这不仅是为了了解两个官方博客及其之间的区别，还能帮助你概览整个发布流程。

为什么要镜像

镜像几乎总是从贡献者博客到主博客。项目组不仅针对有关贡献者社区或一部分文章这么做， 而且和 Kubernetes 主博客更为广泛的读者相关。

作为作者（或评审者），请考虑目标受众，并判断该博客文章是否适合发布在主博客上。
例如：如果目标受众仅限于 Kubernetes 的贡献者， 那么贡献者博客可能更为合适；
如果博客文章是关于开源的普遍话题，那么它可能更适合发布在 Kubernetes 项目之外的其他网站上。

这种对目标受众的考量同样适用于原创文章和镜像文章。

Kubernetes 项目愿意镜像任何发布在 https://kubernetes.dev/blog/ （贡献者博客）上的文章，但前提是满足以下所有条件：

  • 镜像文章的发布日期必须与原始文章相同（发布时间也应相同，但在特殊情况下，可以设置最多延迟 12 小时的时间戳）。

  • 对于在原始文章已合并到贡献者博客之后，向主博客添加镜像文章的 PR，请确保满足以下所有条件：

    • 在原始文章发布到贡献者博客之后，没有文章发布到主博客。

  • 在原始文章的发布时间和镜像文章的发布时间之间，主博客没有文章发布计划。

这是因为 Kubernetes 项目不希望在人们的订阅源（例如 RSS）中插入文章，除非是在订阅源的末尾。

  • 原始文章不违反任何强烈推荐的评审指南或社区规范。

  • 镜像文章的 canonicalUrl 将在其前言中正确设置。 canonicalUrl。

  • 原文章的读者会认为其相关

  • 文章内容与镜像文章出现的目标博客主题一致

从主博客到贡献者博客的镜像操作很少见，但理论上是可行的。

如何镜像

你需要向另一个 Git 仓库（通常是 https://github.com/kubernetes/website） 提交一个 PR，以添加该文章。此操作应在文章合并之前完成。

作为文章的作者，你应该为镜像文章设置规范 URL， 并将其指向原始文章的 URL（你可以使用预览功能预测 URL，并在实际发布前填写此内容）。 在前言中使用 canonicalUrl 字段来完成这一设置。

4 - 发布后沟通

Kubernetes 的发布沟通（Release Comms） 团队（隶属于 SIG Release） 负责管理发布相关的公告，这些公告会发布在主项目博客上。

每次发布之后，发布沟通团队会在一段时间内接管主博客，并发布一系列额外的文章， 用于解释或宣布与该版本相关的变更。这些额外的文章被称为发布后沟通（Post-release comms）。

参与发布后沟通

在一个发布周期中，作为贡献者，你可以选择参与关于 Kubernetes 即将发生的变更的发布后沟通。

要选择参与，你需要针对 k/website 提交一个草稿形式的占位拉取请求（PR）。 最初，这可以是一个空提交。在占位 PR 的描述中，请提及相关的 KEP（Kubernetes Enhancement Proposal） 问题或其他 Kubernetes 改进相关的问题。

当你提交草稿拉取请求时，需要以 main 作为基础分支， 而不是针对 dev-1.34 分支。 这与即将发布的变更和新功能的流程不同。

你还应在相关的 kubernetes/enhancements 问题下留下评论，并附上拉取请求的链接，以通知负责本次发布的发布沟通团队。 你的评论有助于团队了解该变更需要发布公告，并确认你的 SIG 已选择参与。

除此之外，理想情况下，你还应通过 Slack（频道 #release-comms） 联系发布沟通团队，告知他们你已完成上述操作并希望选择参与。

准备文章内容

你应该遵循常规的文章提交流程， 将你的占位 PR 转变为可供评审的内容。然而，对于发布后沟通， 你可能不会有一个写作伙伴；取而代之的是，发布沟通团队可能会指派一名成员来帮助指导你的工作。

你应该压缩拉取请求中的提交； 如果你不确定如何操作，完全可以向发布沟通团队或博客团队寻求帮助。

只要你的文章在前言中被标记为草稿（draft: true）， 该 PR 就可以在发布周期的任何时间合并。

发布

在实际发布之前，发布沟通团队会检查哪些内容已经准备就绪 （如果到了截止日期仍未准备好，且你没有获得豁免，那么公告将不会被收录）。 他们为即将发布的文章制定时间表，并开启新的拉取请求，将这些文章从草稿转为已发布。 以将这些文章从草稿状态变为已发布状态。

博客团队的批准者仍然需要对从草稿到可发布的内容提供最终的签字批准。 在发布日前，用于发布这些公告的拉取请求（PR）应已获得 LGTM（“我觉得不错”） 和批准标签，同时还需要添加 do-not-merge/hold 标签，以确保 PR 不会过早合并。

一旦实际发布完成并且网站 Git 仓库解冻，发布沟通团队或发布团队可以立即取消保留 PR（或一组 PR） PR（或一组 PR）的 hold 状态。

在每篇文章预定发布的当天，自动化流程将触发网站构建，该文章将会变成可见。

5 - 作为博客写作伙伴提供帮助

Kubernetes 有两个官方博客，同时 CNCF 也有自己的博客，你也可以在其中撰写与 Kubernetes 相关的内容。
阅读为 Kubernetes 博客贡献内容以了解这两个博客的详细信息。

当人们作为作者为任一博客撰稿时，Kubernetes 项目会将作者配对为写作伙伴。 本页面解释了如何履行伙伴角色。

在继续阅读本页面之前，你应该确保至少已经阅读了文章提交的概述。

伙伴职责

作为写作伙伴，你的职责包括：

  • 协助博客团队准备文章，使其达到可合并和发布的状态；
  • 支持你的伙伴创作高质量的内容，确保其适合合并；
  • 对你伙伴撰写的文章提供审阅意见。

当团队将你与另一位作者配对时，理念是你们通过互相审阅对方的草稿文章来彼此支持。 大多数阅读 Kubernetes 博客文章的读者并非专家； 内容应当尝试为这类读者群体提供易于理解的信息，或者至少适当地支持非专家读者。

博客团队也会在整个从草稿到发布的流程中帮助你们。他们可以直接批准你的文章发布， 或者安排相应的批准流程。

支持博客团队

你的主要职责是及时沟通你的工作量、可用时间以及进展情况。如果几周过去了， 你的伙伴还没有收到你的消息，这将会导致整体工作花费更多的时间。

支持你的伙伴

支持伙伴的过程分为两个部分：

（这是推荐的选项）

博客团队建议文章的主要作者通过 Google Doc 或 HackMD（由作者选择）构造协作编辑环境。 之后，主作者将该文档共享给以下人员：

  • 所有共同作者
  • 你（他们的写作伙伴）
  • 理想情况下，还应包括一位博客团队中指定的负责人。

作为写作伙伴，你需要阅读草稿内容，并直接提出建议或以其他方式提供反馈。 博客文章的作者通常也会反过来成为你的写作伙伴， 因此他们会针对你所撰写的文章草稿提供类似的反馈。

你的角色是推荐最小的修改集，以使文章适合发布。如果某个图表完全无法理解， 或者文字表达非常不清晰，请提供反馈。如果你对措辞或标点符号有轻微的不同意见， 请忽略它。只要符合博客指南， 让文章作者以他们自己的风格写作即可。

在此完成后，主作者将发起一个 PR 并使用 Markdown 提交文章。 然后你可以提供审阅意见。

一些作者更喜欢从协同编辑开始， 而另一些人则喜欢直接进入 GitHub。

无论他们选择哪种方式，你的角色是提供反馈，使博客团队能够轻松完成审核， 并确认文章可以作为草稿合并。有关作者需要完成的操作， 请参阅向 Kubernetes 博客提交文章。

使用 GitHub 的建议功能指出需要修改的地方。

一旦 Markdown 文件和其他内容（例如图片）看起来没有问题， 你就可以提供正式的审阅意见。

审阅 PR

遵循**审阅 PR **一文的博客部分所给的要求。

当你认为所发起的博客 PR 足够好可以合并时，在 PR 中添加 /lgtm 评论。

这一注释向仓库自动化工具（Prow）内容申明内容“在我看来没有问题”。 Prow 会推进相关流程。/lgtm 命令允许你将自己的意见公开出来， 无论你是否正式成为 Kubernetes 项目的一员。

你或文章作者应通知博客团队有文章已准备好进行签发。根据提交指南， 文章前面应已标记为 draft: true。

后续步骤

作为写作伙伴，没有第四步。一旦 PR 准备好合并， 博客团队（或者，对于贡献者网站，贡献者通信团队）将会接手。 根据反馈，你可能需要返回到前面的步骤，但通常你可以认为作为伙伴的工作已经完成。