本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
文件如何處理第三方和雙源內容
編者按：Zach 是 Kubernetes 文件特別興趣小組 (SIG Docs) 的主席之一。
去年夏末，SIG Docs 就 Kubernetes 文件中的第三方內容發起了社群討論。這次討論成為了一個Kubernetes 增強提案 (KEP)，經過五個月的審查和評論，SIG Architecture 批准了該 KEP，作為 Kubernetes 文件的內容指南。
以下是 Kubernetes 文件現在如何處理第三方內容
指向 Kubernetes 專案中活躍內容的連結（kubernetes 和 kubernetes-sigs GitHub 組織中的專案）始終允許。
Kubernetes 需要某些第三方內容才能執行。示例包括容器執行時（containerd、CRI-O、Docker）、網路策略（CNI 外掛）、Ingress 控制器和日誌。
如果 Kubernetes 執行需要，文件可以連結到 Kubernetes 專案之外的第三方開源軟體 (OSS)。
這些常識性準則確保 Kubernetes 文件只記錄 Kubernetes。
保持文件的重點
我們的目標是讓 Kubernetes 文件成為 Kubernetes 功能的可靠指南。為實現此目標，SIG Docs 正在跟蹤第三方內容，並刪除任何既不在 Kubernetes 專案中，也非 Kubernetes 執行所需的部分第三方內容。
重新定位內容
一些讀者可能會覺得有用的內容將被刪除。為了確保讀者可以持續訪問資訊，我們給利益相關者設定了一個截止日期，即在1.19 版本文件截止日期，即2020 年 7 月 9 日之前，重新定位所有計劃刪除的內容。
在接下來的幾個月裡，隨著貢獻者提交 PR 刪除內容，您會發現文件中的第三方內容越來越少。
背景
隨著時間的推移，SIG Docs 觀察到文件中供應商內容不斷增加。有些內容是以供應商特定實現的形式出現的，這些實現並非 Kubernetes 在專案中執行所必需的。另一些內容則是偽裝成廣告，幾乎沒有功能內容。有些供應商內容是新的；另一些內容已經在文件中存在多年。很明顯，文件需要清晰、明確的準則，規定哪些第三方內容允許，哪些不允許。內容指南是在社群進行了廣泛的審查和評論之後形成的。
當文件準確、有用、值得信賴並專注於功能時，它們才能發揮最佳作用。根據我們的經驗，供應商內容會稀釋信任度和準確性。
簡而言之：功能文件不是供應商宣傳其產品的地方。我們的內容策略使文件專注於幫助開發人員和叢集管理員，而不是營銷。
雙重來源內容
影響較小但同樣重要的是 Kubernetes 文件如何處理**雙重來源內容**。雙重來源內容是指在多個位置釋出或來自非權威來源的內容。
在可能的情況下，Kubernetes 文件會連結到權威來源，而不是託管雙重來源內容。
最大限度地減少雙重來源內容可以簡化文件，並使網路上的內容更容易搜尋。我們也在努力整合和重定向 Kubernetes 文件中的雙重來源內容。
貢獻方式
我們正在Kubernetes 網站倉庫中的一個 issue 中跟蹤第三方內容。如果您發現專案之外且 Kubernetes 執行不需要的第三方內容，請在該跟蹤 issue 中評論。
一旦您發現不符合要求的內容，請隨時提交 PR 將其刪除！
想了解更多嗎？
有關更多資訊，請閱讀跟蹤第三方內容的 issue 說明。