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

返回本页常规视图.

为 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 博客，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 字段来完成这一设置。

2 - 发布后沟通

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

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

参与发布后沟通

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

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

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

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

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

准备文章内容

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

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

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

发布

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

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

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

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

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

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 准备好合并， 博客团队（或者，对于贡献者网站，贡献者通信团队）将会接手。 根据反馈，你可能需要返回到前面的步骤，但通常你可以认为作为伙伴的工作已经完成。