研究人員指南¶
Linux 核心社群歡迎對 Linux 核心、其開發活動以及任何其他開發副產品進行透明研究。Linux 從這類研究中受益匪淺，Linux 的大多數方面都以這樣或那樣的形式受到研究的驅動。
如果研究人員能在公開發布成果之前分享初步發現，社群將不勝感激，尤其是在此類研究涉及安全的情況下。及早參與有助於提高研究質量，並使 Linux 從中獲益。無論如何，建議與社群分享已發表研究的開放獲取副本。
本文旨在闡明 Linux 核心社群在進行此類研究時，認為哪些做法是可接受的，哪些是不可接受的。至少，此類研究及相關活動應遵循標準的研究倫理規則。有關研究倫理（通常）、技術倫理以及特別是開發者社群研究的更多背景資訊，請參閱
Linux 核心社群期望所有與專案互動的人都本著善意參與，以使 Linux 變得更好。歡迎對 Linux 核心社群產生的任何公開可用的工件（包括但不限於原始碼）進行研究，但對開發人員的研究必須明確選擇加入。
完全基於公開可用來源的被動研究，包括公共郵件列表上的帖子和公共倉庫中的提交，顯然是允許的。然而，與任何研究一樣，仍然必須遵循標準的倫理規範。
然而，對開發者行為的主動研究，必須徵得相關開發者的明確同意並向其充分披露。未經同意，不能與開發者互動/對開發者進行實驗；這也是標準的研究倫理。
調查¶
研究通常採取向維護者或貢獻者傳送調查問卷的形式。然而，一般來說，核心社群從這些調查中獲得的價值甚微。核心開發流程之所以有效，是因為每個開發人員都從他們的參與中受益，即使是與有不同目標的人合作。然而，回應調查問卷是對忙碌的開發人員提出的單向要求，對他們自己或整個核心社群都沒有相應的益處。因此，不鼓勵這種研究方法。
核心社群成員已經收到過多的電子郵件，並且很可能將調查請求視為對他們時間的又一個要求。傳送此類請求會剝奪社群寶貴的貢獻者時間，並且不太可能產生具有統計學意義的有用回覆。
作為替代方案，研究人員應考慮參加開發者活動，舉辦會議以解釋研究專案及其對參與者的益處，並直接與社群進行互動。這樣獲得的資訊將比透過電子郵件調查獲得的資訊豐富得多，而且社群也將能夠從您的見解中學習並受益。
補丁¶
為了澄清：向開發者傳送補丁確實是與他們互動，但他們已經同意接收善意的貢獻。傳送故意有缺陷/易受攻擊的補丁或在討論中提供誤導性資訊是不被允許的。此類交流可能損害開發者（例如，耗費時間、精力並打擊士氣），並透過侵蝕整個開發者社群對貢獻者（以及貢獻者所屬組織）的信任，從而損害專案，破壞向貢獻者提供建設性反饋的努力，並使終端使用者面臨軟體缺陷的風險。
研究人員參與 Linux 本身的開發，與任何人一樣，是受到歡迎和鼓勵的。對 Linux 程式碼的研究是一種常見做法，特別是在開發或執行能夠產生可操作結果的分析工具時。
在與開發者社群互動時，傳送補丁傳統上是產生影響的最佳方式。Linux 已經存在許多已知錯誤——更有幫助的是擁有經過驗證的修復方案。在貢獻之前，請仔細閱讀相關文件
然後傳送補丁（包括帶有以下所有詳細資訊的提交日誌），並跟進其他開發人員的任何反饋。
傳送研究產生的補丁時，提交日誌應至少包含以下詳細資訊，以便開發者有適當的上下文來理解貢獻。回答
發現了什麼具體問題？
在執行的系統上如何復現此問題？
遇到此問題會對系統產生什麼影響？
問題是如何發現的？具體包括有關任何測試、靜態或動態分析程式以及用於執行此工作的任何其他工具或方法的詳細資訊。
問題是在哪個 Linux 版本上發現的？強烈建議使用最新發布版本或最新的 linux-next 分支（參見如何進行 Linux 核心開發）。
為修復此問題做了哪些更改，以及為什麼認為這些更改是正確的？
此更改是如何進行構建測試和執行時測試的？
此更改修復了哪個之前的提交？這應如文件所述，放在“Fixes:”標籤中。
還有誰審查過此補丁？這應放在相應的“Reviewed-by:”標籤中；詳見下文。
例如
From: Author <author@email>
Subject: [PATCH] drivers/foo_bar: Add missing kfree()
The error path in foo_bar driver does not correctly free the allocated
struct foo_bar_info. This can happen if the attached foo_bar device
rejects the initialization packets sent during foo_bar_probe(). This
would result in a 64 byte slab memory leak once per device attach,
wasting memory resources over time.
This flaw was found using an experimental static analysis tool we are
developing, LeakMagic[1], which reported the following warning when
analyzing the v5.15 kernel release:
path/to/foo_bar.c:187: missing kfree() call?
Add the missing kfree() to the error path. No other references to
this memory exist outside the probe function, so this is the only
place it can be freed.
x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
11.2 show no new warnings, and LeakMagic no longer warns about this
code path. As we don't have a FooBar device to test with, no runtime
testing was able to be performed.
[1] https://url/to/leakmagic/details
Reported-by: Researcher <researcher@email>
Fixes: aaaabbbbccccdddd ("Introduce support for FooBar")
Signed-off-by: Author <author@email>
Reviewed-by: Reviewer <reviewer@email>
如果您是首次貢獻者，建議在將補丁釋出到公共列表之前，先由他人在內部私下審查。（如果您已被明確告知您的補丁需要更仔細的內部審查，則這是必需的。）這些審查人員的“Reviewed-by”標籤應包含在生成的補丁中。尋找另一位熟悉 Linux 貢獻的開發者，尤其是在您自己的組織內部，並在將補丁傳送到公共郵件列表之前讓他們協助審查，這通常會顯著提高補丁的質量，從而減輕其他開發者的負擔。
如果沒有人可以內部審查補丁並且您需要幫助尋找這樣的人，或者您對本文件和開發者社群的期望有任何其他疑問，請聯絡私人技術諮詢委員會郵件列表：<tech-board@groups.linuxfoundation.org>。