提交部落格文章和案例分析

任何人都可以撰寫部落格文章並提交以供審查。案例研究需要廣泛的審查才能獲得核准。

Kubernetes 部落格

專案使用 Kubernetes 部落格來傳達新功能、社群報告以及任何可能與 Kubernetes 社群相關的新聞。這包括終端使用者和開發人員。部落格的大部分內容是關於核心專案中發生的事情，但我們也鼓勵您提交關於生態系統中其他地方發生的事情！

任何人都可以撰寫部落格文章並提交以供審查。

提交文章

部落格文章不應具有商業性質，並且應包含廣泛適用於 Kubernetes 社群的原始內容。適當的部落格內容包括

  • 新的 Kubernetes 功能
  • Kubernetes 專案更新
  • 特殊興趣小組的更新
  • 教學課程和逐步解說
  • 圍繞 Kubernetes 的思想領導力
  • Kubernetes 合作夥伴 OSS 整合
  • 僅限原始內容

不適合的內容包括

  • 供應商產品推銷
  • 沒有整合和客戶故事的合作夥伴更新
  • 聯合發布文章（語言翻譯可以）

若要提交部落格文章，請依照下列步驟執行

  1. 如果您尚未簽署 CLA，請先簽署。

  2. 查看 網站儲存庫中現有部落格文章的 Markdown 格式。

  3. 在您選擇的文字編輯器中寫出您的部落格文章。

  4. 在步驟 2 的相同連結上，按一下 [建立新檔案] 按鈕。將您的內容貼到編輯器中。命名檔案以符合部落格文章的建議標題，但不要在檔案名稱中放入日期。部落格審查者將與您合作處理最終檔案名稱以及部落格發布的日期。

  5. 當您儲存檔案時，GitHub 將引導您完成提取請求流程。

  6. 部落格文章審查者將審查您的提交內容，並與您合作處理意見回饋和最終細節。當部落格文章獲得核准時，將會排定部落格的發布時間。

指南和期望

  • 部落格文章不應是供應商推銷。

    • 文章必須包含廣泛適用於 Kubernetes 社群的內容。例如，提交內容應著重於上游 Kubernetes，而不是供應商特定的組態。查看 文件樣式指南，以了解通常允許在 Kubernetes 屬性上發布的內容。
    • 連結應主要指向官方 Kubernetes 文件。當使用外部參考時，連結應多樣化 - 例如，提交內容不應僅包含指向單一公司部落格的連結。
    • 有時這是一個微妙的平衡。部落格團隊在那裡提供關於文章是否適合 Kubernetes 部落格的指導，因此請隨時與他們聯繫。

  • 部落格文章不會在特定日期發布。

    • 文章由社群志工審查。我們將盡力配合特定時程，但我們不保證。
    • Kubernetes 專案的許多核心部分在發行視窗期間提交部落格文章，延遲了發布時間。考慮在發行週期的較安靜期間提交。
    • 如果您正在尋找關於文章發行日期的更多協調，與 CNCF 行銷部門協調比提交部落格文章更合適。
    • 有時審查可能會積壓。如果您覺得您的審查沒有獲得它需要的關注，您可以透過 #sig-docs-blog Slack 頻道聯繫部落格團隊，即時詢問。

  • 部落格文章應與 Kubernetes 使用者相關。

    • 與參與 Kubernetes SIG 活動或其結果相關的主題始終在主題範圍內（請參閱 貢獻者通訊團隊中的工作，以取得對這些文章的支援）。
    • Kubernetes 的組件是有意模組化的，因此使用現有整合點（如 CNI 和 CSI）的工具在主題範圍內。
    • 關於其他 CNCF 專案的文章可能在主題範圍內，也可能不在。我們建議在提交草稿之前詢問部落格團隊。
      • 許多 CNCF 專案都有自己的部落格。這些通常是文章更好的選擇。有時 CNCF 專案的重大功能或里程碑，使用者會感興趣在 Kubernetes 部落格上閱讀。
    • 關於貢獻 Kubernetes 專案的部落格文章應在 Kubernetes 貢獻者網站中

  • 部落格文章應為原始內容

    • 官方部落格不是為了將第三方的現有內容重新用於新內容。
    • 部落格的 授權 允許將內容用於商業目的，但不允許反向使用。

  • 部落格文章應力求具有前瞻性

    • 鑑於專案的開發速度，我們希望永不過時的內容，這些內容不需要更新即可保持對讀者的準確性。
    • 撰寫部落格文章來進行高階概述，不如新增教學或更新官方文件會是更好的選擇。
      • 考慮將長篇技術內容濃縮成部落格文章的行動呼籲，並著重於問題領域或讀者應關注的原因。

提交部落格文章的技術考量

提交內容需為 Markdown 格式，以供部落格的 Hugo 產生器使用。關於如何使用此技術堆疊，有許多可用資源。

對於插圖、圖表或圖示，可以使用 figure shortcode。對於其他圖片，我們強烈建議使用 alt 屬性；如果圖片不需要任何 alt 屬性，或許根本不需要放在文章中。

我們理解這項要求會使較不熟悉的人員提交過程更加困難，並且我們不斷尋找降低此門檻的解決方案。如果您對於如何降低門檻有任何想法，請自願協助。

SIG Docs 的 部落格子專案 管理部落格文章的審查流程。如需更多資訊，請參閱 Submit a post。

若要提交部落格文章，請依照下列指示

  • 開啟提取請求 並附上新的部落格文章。新的部落格文章會放在 content/en/blog/_posts 目錄下。

  • 請確保您的部落格文章遵循正確的命名慣例和以下 frontmatter（metadata）資訊

    • Markdown 檔案名稱必須遵循 YYYY-MM-DD-Your-Title-Here.md 格式。例如，2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md。

    • 請勿在檔案名稱中包含點號。類似 2020-01-01-whats-new-in-1.19.md 的名稱會在建置期間造成失敗。

    • Front matter 必須包含以下內容

      ---
layout: blog
title: "Your Title Here"
date: YYYY-MM-DD
slug: text-for-URL-link-here-no-spaces
author: >
  Author-1 (Affiliation),
  Author-2 (Affiliation),
  Author-3 (Affiliation)  
---

    • 首次或初始提交訊息應為正在進行工作的簡短摘要，且應能獨立作為部落格文章的描述。請注意，後續對您部落格文章的編輯將被合併到此主要提交中，因此應盡可能地實用。

      • 良好提交訊息的範例
        • Add blog post on the foo kubernetes feature （新增關於 foo kubernetes 功能的部落格文章）
        • blog: foobar announcement （部落格：foobar 公告）
      • 不良提交訊息的範例
        • Add blog post （新增部落格文章）
        • .
        • initial commit （初始提交）
        • draft post （草稿文章）

    • 部落格團隊將審查您的 PR，並針對您可能需要修正的事項提供意見。之後，機器人會合併您的 PR，您的部落格文章將會發布。

    • 如果部落格文章的內容僅包含預期不需要更新以保持讀者準確性的內容，則可以將其標記為常青內容，並免於針對發布超過一年的部落格文章自動新增過時內容警告。

      • 若要將部落格文章標記為常青內容，請將此內容新增至 front matter

        evergreen: true

      • 不應標記為常青內容的範例

        • 僅適用於特定發行版本或版本而非所有未來版本的教學
        • 參考 pre-GA API 或功能

從 Kubernetes Contributor Blog 鏡像

若要從 Kubernetes contributor blog 鏡像部落格文章，請遵循以下準則

  • 保持部落格內容不變。如果有變更，應先對原始文章進行變更，然後再對鏡像文章進行變更。
  • 鏡像部落格應具有 canonicalUrl，也就是原始部落格發布後的網址。
  • 與 Kubernetes contributor blogs 相同，Kubernetes 部落格文章也根據新準則在 YAML 標頭中提及作者。應確保這一點。
  • 發布日期與原始部落格保持一致。

上述所有其他準則和期望也適用。

提交案例研究

案例研究突顯組織如何使用 Kubernetes 解決真實世界的問題。Kubernetes 行銷團隊和 CNCF 成員會與您合作處理所有案例研究。

請查看 現有案例研究 的原始碼。

請參考 案例研究準則，並依照準則中概述的方式提交您的請求。

上次修改時間：2024 年 6 月 20 日下午 8:49 PST：Update blogs-case-studies.md (1d493790e8)