113 lines
6.1 KiB
ReStructuredText
113 lines
6.1 KiB
ReStructuredText
|
.. SPDX-License-Identifier: GPL-2.0
|
|||
|
|
|
|||
|
|
.. include:: ../disclaimer-zh_TW.rst
|
|||
|
|
|
|||
|
|
:Original: :ref:`Documentation/process/code-of-conduct-interpretation.rst <code_of_conduct_interpretation>`
|
|||
|
|
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
|
|||
|
|
Hu Haowen <src.res@email.cn>
|
|||
|
|
|
|||
|
|
.. _tw_code_of_conduct_interpretation:
|
|||
|
|
|
|||
|
|
Linux內核貢獻者契約行為準則解釋
|
|||
|
|
===============================
|
|||
|
|
|
|||
|
|
:ref:`tw_code_of_conduct` 準則是一個通用文檔，旨在爲幾乎所有開源社區提供一套規則。
|
|||
|
|
每個開源社區都是獨一無二的，Linux內核也不例外。因此，本文描述了Linux內核社區中
|
|||
|
|
如何解釋它。我們也不希望這種解釋隨著時間的推移是靜態的，並將根據需要進行調整。
|
|||
|
|
|
|||
|
|
與開發軟體的「傳統」方法相比，Linux內核開發工作是一個非常個人化的過程。你的貢獻
|
|||
|
|
和背後的想法將被仔細審查，往往導致批判和批評。審查將幾乎總是需要改進，材料才
|
|||
|
|
能包括在內核中。要知道這是因爲所有相關人員都希望看到Linux整體成功的最佳解決方
|
|||
|
|
案。這個開發過程已經被證明可以創建有史以來最健壯的作業系統內核，我們不想做任何
|
|||
|
|
事情來導致提交質量和最終結果的下降。
|
|||
|
|
|
|||
|
|
維護者
|
|||
|
|
------
|
|||
|
|
|
|||
|
|
行為準則多次使用「維護者」一詞。在內核社區中，「維護者」是負責子系統、驅動程序或
|
|||
|
|
文件的任何人，並在內核原始碼樹的維護者文件中列出。
|
|||
|
|
|
|||
|
|
責任
|
|||
|
|
----
|
|||
|
|
|
|||
|
|
《行為準則》提到了維護人員的權利和責任，這需要進一步澄清。
|
|||
|
|
|
|||
|
|
首先，最重要的是，有一個合理的期望是由維護人員通過實例來領導。
|
|||
|
|
|
|||
|
|
也就是說，我們的社區是廣闊的，對維護者沒有新的要求，他們單方面處理其他人在
|
|||
|
|
他們活躍的社區的行爲。這一責任由我們所有人承擔，最終《行為準則》記錄了最終的
|
|||
|
|
上訴路徑，以防有關行爲問題的問題懸而未決。
|
|||
|
|
|
|||
|
|
維護人員應該願意在出現問題時提供幫助，並在需要時與社區中的其他人合作。如果您
|
|||
|
|
不確定如何處理出現的情況，請不要害怕聯繫技術諮詢委員會（TAB）或其他維護人員。
|
|||
|
|
除非您願意，否則不會將其視爲違規報告。如果您不確定是否該聯繫TAB 或任何其他維
|
|||
|
|
護人員，請聯繫我們的衝突調解人 Mishi Choudhary <mishi@linux.com>。
|
|||
|
|
|
|||
|
|
最後，「善待對方」才是每個人的最終目標。我們知道每個人都是人，有時我們都會失敗，
|
|||
|
|
但我們所有人的首要目標應該是努力友好地解決問題。執行行為準則將是最後的選擇。
|
|||
|
|
|
|||
|
|
我們的目標是創建一個強大的、技術先進的作業系統，以及所涉及的技術複雜性，這自
|
|||
|
|
然需要專業知識和決策。
|
|||
|
|
|
|||
|
|
所需的專業知識因貢獻領域而異。它主要由上下文和技術複雜性決定，其次由貢獻者和
|
|||
|
|
維護者的期望決定。
|
|||
|
|
|
|||
|
|
專家的期望和決策都要經過討論，但在最後，爲了取得進展，必須能夠做出決策。這一
|
|||
|
|
特權掌握在維護人員和項目領導的手中，預計將善意使用。
|
|||
|
|
|
|||
|
|
因此，設定專業知識期望、作出決定和拒絕不適當的貢獻不被視爲違反行為準則。
|
|||
|
|
|
|||
|
|
雖然維護人員一般都歡迎新來者，但他們幫助（新）貢獻者克服障礙的能力有限，因此
|
|||
|
|
他們必須確定優先事項。這也不應被視爲違反了行為準則。內核社區意識到這一點，並
|
|||
|
|
以各種形式提供入門級節目，如 kernelnewbies.org 。
|
|||
|
|
|
|||
|
|
範圍
|
|||
|
|
----
|
|||
|
|
|
|||
|
|
Linux內核社區主要在一組公共電子郵件列表上進行交互，這些列表分布在由多個不同
|
|||
|
|
公司或個人控制的多個不同伺服器上。所有這些列表都在內核原始碼樹中的
|
|||
|
|
MAINTAINERS 文件中定義。發送到這些郵件列表的任何電子郵件都被視爲包含在行爲
|
|||
|
|
準則中。
|
|||
|
|
|
|||
|
|
使用 kernel.org bugzilla和其他子系統bugzilla 或bug跟蹤工具的開發人員應該遵循
|
|||
|
|
行為準則的指導原則。Linux內核社區沒有「官方」項目電子郵件地址或「官方」社交媒體
|
|||
|
|
地址。使用kernel.org電子郵件帳戶執行的任何活動必須遵循爲kernel.org發布的行爲
|
|||
|
|
準則，就像任何使用公司電子郵件帳戶的個人必須遵循該公司的特定規則一樣。
|
|||
|
|
|
|||
|
|
行為準則並不禁止在郵件列表消息、內核更改日誌消息或代碼注釋中繼續包含名稱、
|
|||
|
|
電子郵件地址和相關注釋。
|
|||
|
|
|
|||
|
|
其他論壇中的互動包括在適用於上述論壇的任何規則中，通常不包括在行為準則中。
|
|||
|
|
除了在極端情況下可考慮的例外情況。
|
|||
|
|
|
|||
|
|
提交給內核的貢獻應該使用適當的語言。在行為準則之前已經存在的內容現在不會被
|
|||
|
|
視爲違反。然而，不適當的語言可以被視爲一個bug；如果任何相關方提交補丁，
|
|||
|
|
這樣的bug將被更快地修復。當前屬於用戶/內核API的一部分的表達式，或者反映已
|
|||
|
|
發布標準或規範中使用的術語的表達式，不被視爲bug。
|
|||
|
|
|
|||
|
|
執行
|
|||
|
|
----
|
|||
|
|
|
|||
|
|
行為準則中列出的地址屬於行為準則委員會。https://kernel.org/code-of-conduct.html
|
|||
|
|
列出了在任何給定時間接收這些電子郵件的確切成員。成員不能訪問在加入委員會之前
|
|||
|
|
或離開委員會之後所做的報告。
|
|||
|
|
|
|||
|
|
最初的行為準則委員會由TAB的志願者以及作爲中立第三方的專業調解人組成。委員會
|
|||
|
|
的首要任務是建立文件化的流程，並將其公開。
|
|||
|
|
|
|||
|
|
如果報告人不希望將整個委員會納入投訴或關切，可直接聯繫委員會的任何成員，包括
|
|||
|
|
調解人。
|
|||
|
|
|
|||
|
|
行為準則委員會根據流程審查案例（見上文），並根據需要和適當與TAB協商，例如請求
|
|||
|
|
和接收有關內核社區的信息。
|
|||
|
|
|
|||
|
|
委員會做出的任何決定都將提交到表中，以便在必要時與相關維護人員一起執行。行爲
|
|||
|
|
準則委員會的決定可以通過三分之二的投票推翻。
|
|||
|
|
|
|||
|
|
每季度，行為準則委員會和標籤將提供一份報告，概述行為準則委員會收到的匿名報告
|
|||
|
|
及其狀態，以及任何否決決定的細節，包括完整和可識別的投票細節。
|
|||
|
|
|
|||
|
|
我們希望在啓動期之後爲行為準則委員會人員配備建立一個不同的流程。發生此情況時，
|
|||
|
|
將使用該信息更新此文檔。
|
|||
|
|
|