本篇文章已發布超過一年。較舊的文章可能包含過時內容。請確認頁面中的資訊自發布以來是否已變得不正確。
文件如何處理第三方與雙重來源內容
編輯註：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 描述。