部落格指南
這些指南涵蓋了主要的 Kubernetes 部落格和 Kubernetes 貢獻者部落格。
所有部落格內容還必須遵守 內容指南中的總體政策。
準備工作
請確保您熟悉 為 Kubernetes 部落格投稿的介紹部分,這不僅能讓您瞭解兩個官方部落格及其差異,還能對整個流程有一個概覽。
原創內容
Kubernetes 專案僅接受英文的原創內容。
注意
如果內容已提交或釋出到 Kubernetes 專案之外,Kubernetes 專案將不接受用於部落格的內容。
官方部落格不適用於將第三方現有內容改寫為新內容。
此限制甚至延伸到推廣其他 Linux Foundation 和 CNCF 專案。許多 CNCF 專案都有自己的部落格。對於關於特定專案的帖子,這些部落格通常是更好的選擇,即使該專案專門設計用於與 Kubernetes(或 Linux 等)協同工作。
相關內容
文章必須包含廣泛適用於 Kubernetes 社群的內容。例如,提交的文章應側重於上游 Kubernetes,而不是特定於供應商的配置。對於提交給主部落格但不是 映象文章的文章,文章中的超連結通常應指向官方 Kubernetes 文件。在進行外部引用時,連結應多樣化——例如,提交的內容不應僅包含指向同一公司部落格的連結。
官方 Kubernetes 部落格不是用於供應商宣傳或推廣 Kubernetes 外部特定解決方案的文章的地方。
有時這是一個微妙的平衡。您可以在 Slack (#sig-docs-blog) 中詢問有關帖子是否適合 Kubernetes 部落格和/或貢獻者部落格的指導——請隨時聯絡。
《內容指南》無條件適用於部落格文章及其新增它們的 PR。請注意,指南中的某些限制宣告僅與文件相關;這些標記的限制不適用於部落格文章。
本地化
該網站已本地化為多種語言;英語是所有其他本地化的“上游”。即使您會說其他語言並樂意提供本地化,也應在單獨的 PR 中進行(請參閱 每個 PR 的語言)。
版權和再利用
您必須撰寫原創內容,並且您必須獲得許可才能將該內容授權給 Cloud Native Computing Foundation(以便 Kubernetes 專案能夠合法釋出它)。這意味著不僅禁止直接抄襲,如果您沒有獲得滿足 CNCF 版權許可條件的許可(例如,如果您的僱主有關於智慧財產權的政策限制了您的行為),您就不能撰寫部落格文章。
部落格的許可證允許出於商業目的的商業使用內容,但反之則不行。
特別興趣小組和工作組
與 Kubernetes SIG 活動的參與或結果相關的議題總是切題的(請參閱 貢獻者溝通團隊中的工作以支援這些帖子)。
專案通常會將這些文章映象到兩個部落格。
國家內容限制
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 專案很可能會拒絕該文章)。