博客指南
这些指南涵盖了主要的 Kubernetes 博客和 Kubernetes 贡献者博客。
所有博客内容还必须遵守内容指南中的总体政策。
开始之前
请确保您熟悉贡献 Kubernetes 博客的介绍部分,这不仅有助于了解两个官方博客及其差异,还能让您对整个流程有一个概览。
原创内容
Kubernetes 项目仅接受原创内容,且内容需使用英语。
注意
如果博客内容已在 Kubernetes 项目外部提交或发布过,Kubernetes 项目将不接受。
官方博客不能作为将任何第三方现有内容重新用于新内容的媒介。
此限制甚至适用于推广其他 Linux Foundation 和 CNCF 项目。许多 CNCF 项目都有自己的博客。即使这些项目专门设计用于 Kubernetes(或 Linux 等),关于特定项目的文章通常更适合发布到这些项目自己的博客上。
相关内容
文章必须包含广泛适用于 Kubernetes 社区的内容。例如,投稿应侧重于上游 Kubernetes,而非特定厂商的配置。对于提交到主博客而非镜像文章的文章,文中的超链接通常应指向官方 Kubernetes 文档。在进行外部引用时,链接应多样化,例如,投稿不应只包含指向单一公司博客的链接。
Kubernetes 官方博客不适合发布供应商推销内容或推广 Kubernetes 外部特定解决方案的文章。
有时这是一个微妙的平衡。您可以在 Slack (#sig-docs-blog) 中咨询,了解文章是否适合 Kubernetes 博客和/或贡献者博客——请随时与我们联系。
内容指南无条件地适用于博客文章及添加这些文章的 PR。请注意,指南中的某些限制明确说明仅与文档相关;这些标记的限制不适用于博客文章。
本地化
网站已被本地化为多种语言;英语是所有其他本地化的“上游”。即使您会其他语言并乐于提供本地化,这也应在单独的拉取请求中完成(参见每个 PR 的语言)。
版权和重用
您必须撰写原创内容,并且必须获得许可将该内容授权给云原生计算基金会(Cloud Native Computing Foundation),以便 Kubernetes 项目可以合法发布。这意味着不仅禁止直接抄袭,如果您没有权限满足 CNCF 版权许可条件(例如,您的雇主有关于知识产权的政策限制了您的行为),您也不能撰写博客文章。
博客的许可证允许将内容用于商业目的,但反之则不然。
特别兴趣小组和工作组
与参与 Kubernetes SIG 活动或活动结果相关的主题始终是相关的(关于这些文章的支持,请参见 Contributor Comms Team 的工作)。
项目通常会将这些文章镜像到两个博客。
国家内容限制
Kubernetes 网站拥有中国政府颁发的互联网内容提供商 (ICP) 许可证。尽管不太可能成为问题,但 Kubernetes 不能发布会被中国政府官方互联网内容过滤阻止的文章。
博客特定内容指南
除了常规的风格指南,博客文章应(非必须)符合博客特定风格建议。
本页的其余部分是补充指南;这些并非文章必须遵循的严格规则,但审查人员很可能会(并且应该)要求对明显不符合此处建议的文章进行修改。
图示和插图
对于插图(包括图表),在可行的情况下使用 figure shortcode。您应设置 alt
属性以提高可访问性。
插图、技术图表和类似图形应使用矢量图像;强烈建议使用 SVG 格式。
使用栅格图像作为插图的文章维护起来更困难,在某些情况下,博客团队可能会要求作者在发布前修改文章。
永恒性
博客文章应着眼于面向未来
- 考虑到项目的发展速度,SIG Docs 倾向于永恒的写作:即不需要更新即可对读者保持准确的内容。
- 相比于将高层概览作为博客文章撰写,添加教程或更新官方文档可能是更好的选择。
- 考虑将冗长的技术内容集中作为博客文章的行动号召,并重点关注问题领域或读者为何应该关注。
内容示例
以下是适合主要的 Kubernetes 博客的内容示例
- 关于新的 Kubernetes 能力的公告
- 解释如何使用 Kubernetes 实现某个结果;例如,告诉我们您对滚动部署基本概念的低成本改进。
- 比较与 Kubernetes 和云原生相关的几种不同软件选项。只要您充分披露您的利益冲突/关系,可以包含其中一个选项的链接。
- 关于问题或事件以及您如何解决它们的案例故事
- 讨论为特定用例构建云原生平台的文章
- 您对 Kubernetes 的优点或缺点的看法
- 关于非核心 Kubernetes(例如 Gateway API)的公告和案例故事
- 发布后的公告和更新
- 关于重要 Kubernetes 安全漏洞的消息
- Kubernetes 项目更新
- 教程和演练
- 关于 Kubernetes 和云原生的思想领导力
- Kubernetes 的组件是有意模块化的,因此撰写关于现有集成点(如 CNI 和 CSI)的文章是恰当的。只要您不进行供应商推销,您也可以撰写关于这些集成另一端的内容。
以下是适合 Kubernetes 贡献者博客的内容示例
- 关于如何测试您对 Kubernetes 代码的更改的文章
- 关于非代码贡献的内容
- 关于设计仍在讨论中的 Alpha 特性的讨论
- 关于工作组、特别兴趣小组等的“认识团队”文章
- 关于如何编写安全代码并成为 Kubernetes 本身一部分的指南
- 关于维护者峰会及峰会成果的文章
不接受的内容示例
然而,项目不会发布
- 供应商推销内容
- 您已在其他地方发布过的文章,即使只是在您自己的低流量博客上
- 只有少量解释的大段示例源代码
- 关于与 Kubernetes 协同工作或依赖 Kubernetes 的外部项目的更新(请将这些内容发布到外部项目自己的博客上)
- 关于将 Kubernetes 与特定云提供商结合使用的文章
- 批评特定人物、人群或企业的文章
- 包含重要技术错误或误导性细节的文章(例如:如果您建议在生产集群中关闭重要的安全控制措施,因为这可能不方便,Kubernetes 项目很可能会拒绝该文章)。