Essential.NET-如何參與 Microsoft 開放原始碼軟體專案

藉由作者： Mark Michaelis |2018 年 10 月

以下是事實：Microsoft 會裝載在 GitHub 上，包括一些相當大的類似.NET 編譯器平台，也稱為"Roslyn，"有多達 4 百萬個幾行程式碼的約為 2,000 位開放原始碼軟體 (OSS) 存放庫。對於許多開發人員，看起來令人怯步的程式碼將變更提交至數以百萬計的電腦執行的專案。幸運的是，您不需要在 Microsoft OSS 專案上創造您的歷史的博士學位的程式設計語言和編譯器。有提供範圍廣泛的困難度和體驗，從新手到專家的機會。

我收到我開始在 2018 年 3 月的使用.NET Core 小組成員加入一組新的 Api。我才能夠在跳由於我在 Microsoft，特別是與專案經理 Kathleen Dollard 的連線。當時我想知道: 「困難，就可以不是在要參與 Microsoft 連線良好的人嗎？」記住此問題，我決定進行一些研究，了解。在本文中我會探討的主題提供給 Microsoft 作業系統和花費新手參與。

入門：文件和提取要求檢閱

可能是最好的起點是文件。如果您瀏覽至任何.NET 文件網頁 (例如bit.ly/2LAv7hA) 沒有徵求意見反應，頁尾中所示的每個頁面的底部，您會發現**[圖 1**。

提交的建議和文件的變更
[圖 1 提交建議和文件的變更

從這裡您可以按一下 [產品意見反應] 提交新問題，或瀏覽和搜尋現有的問題。更棒的是，第二個按鈕會帶您直接前往 GitHub 問題清單，如您所瀏覽，因此您可以建立 GitHub 問題，或瀏覽至文件原始碼本身的特定頁面 (例如github.com/dotnet/docs) 直接修正此問題。通常，只需更新文件和提交提取要求 (PR) 是比文件問題所需的工作更容易。

我已說出與小組成員直接與他們強調所有提交都的歡迎使用，甚至拼字與文法修正。這些變更可能不是令人興奮，但他們可以進行成功的 API 和不成功的一個之間的差異。

此外，docs 小組是其中一個最快回應引發的問題和 Pr，與指派給每個區域，無論多麼微小的地址投稿的人員。一個原因文件編輯很簡單：它通常不需要您複製存放庫，以提交變更。相反地，您可以使用 GitHub 的 web 編輯 UI，它會自動分支，並為您提交提取要求。

提取要求檢閱也是參與重要的差異。每個專案需要提取要求意見反應和 Microsoft 小組會感激的 PR 檢閱貢獻。我知道我已註明貢獻歸屬 — 和所學習到從 — 我已提交至.NET 的運作方式的檢閱。最大的一課，我是時間的我不能全心投入並執意操作或其他項目之間 slivers 提供顯著的貢獻。在此層級的程式碼需要仔細思考、仔細實作和重要的共同作業。最後，我很感激拒絕 Pr 並接受提取要求的項目。提取要求檢閱是中的步驟並提供開放原始碼開發的好地方。

第一次容易存取的問題

準備好的人採取多個文件，Microsoft 會提供一些指引。會加上描述項，例如「第一個問題」和「簡單」是絕佳的候選項目是至遊戲的新的開發人員的問題。Microsoft 甚至會要求要避開的第一次容易存取的問題之前的版本中，結尾附近的作用中的專案成員，因此保持專案適用於新的開發人員更容易使用的問題，並降低複雜度列開始使用。此外，第一次平易近人經常發出說明哪裡可找到問題的文件連結，而不是離開 flailing 以嘗試尋找特定的瑕疵品中新的開發人員，這是大型存放庫。Roslyn 小組，比方說，良好的第一個問題必須包含：

修正可能是必要的檔案的連結
測試要去的識別
開始使用 roslyn 建立與安裝指示
一般的參與原則

偏好從新的參與的承諾也擴展到接受提取要求的方式。標記為「良好第一個問題」的 Pr，Microsoft 會提供給新的參與者，會比從現有的參與者接受其 Pr 的喜好設定。不僅如此，Microsoft staffer 標記為「良好第一個問題」的問題會直接回答努力修正此問題的人的問題。手把手的該位元可以是很重要的參與程度的第一個階段。

很明顯地，Microsoft 會超出其方法來取得第一次參與的參與者。Roslyn，比方說，是複雜的 4 百萬列程式碼基底，不能隨心所欲。吸引人的新參與者，Microsoft 可在其 OSS 研究計劃，讓外部開發人員的活躍社群。

定期的貢獻

接受您的第一個提取要求之後，您可能要採取更複雜的問題和功能。有「說明想」和「最新的高」等問題標記表示問題可能是適當的目標群區 — 雖然不一定適用於第一個計時器。(請參閱最多為 grabs.net瀏覽的專案和對應的問題清單標記這類與第一次平易近人或尋求幫助。) 加上這些標記可能的問題牽涉到更多的工作或更高的知識專案所無法提供的工作;不過，它們是妥善定義，而且不需要與專案小組的廣泛合作。相反地，還有一種定義的工作流程，您會是個明智的選擇遵循：

應該討論貢獻的層級的錯誤修正之外，與小組及計劃，以避免遭到拒絕的範圍內
貢獻應針對主機 — 不是針對實驗性功能分支
提取要求必須與主要分支的提示輕鬆合併
參與者應該確定簽署參與者授權合約 (請參閱cla2.dotnetfoundation.org)

如所預期的開發人員熟悉 Git，請確定您在（複製到您的電腦）的本機分支中工作，並再送出程式碼的考量，透過項目。當然，您可以建立在本機的分支，但當您提交您的 PR 時您將提交至 master。

有幾個程式設計和工作流程指導方針，要牢記在心。首先，是要考慮的程式碼撰寫樣式。雖然您可以找到 C# 撰寫程式碼處的樣式bit.ly/2woQv3u，一般的摘要是以遵守現有檔案的標準。這是 true，即使現有的檔案不同的記載標準。這表示，直到您撰寫程式碼的整個檔案（或將它沒有任何優先順序已經在檔案中的項目），指導方針是簡單 — 請依照下列範例中，其餘的檔案。即使沒有優先順序，不過，有只有 16 個項目列在 C# 程式碼撰寫樣式的文件，都特別令人意外。這些項目包括：

在各自的行上的大括號
以四位數空格來縮排（而不是索引標籤）
常數的本機變數和欄位內部的私用欄位和 PascalCasing _camelCase
避免這個問題。除非必要否則
一定要指定可見性（也就是使用私用即使成員預設為私用）
避免中斷程式碼的多個空白行
指派的類型明顯時，只能使用 var (請參閱itl.tc/UsingVar)，除了 Roslyn 專案，其中使用 var 無所不在
指定型別宣告內頂端的欄位

一般而言，您可以在其中找到.editorconfig (請參閱editorconfig.org) 針對每個目錄，落實這些標準的設定檔。請務必要使用的檔案，以確定您遵循的指導方針，並避免封鎖您的 PR。

對於 Visual Basic 中撰寫程式碼，請遵循的精神和 C# 指南的目的。

雖然不在清單中所述，單元測試會產生需要的品質等級的關鍵。

設計說明

某些存放庫，例如語言、 CoreFX 和 Dotnet CLI 需要更大的層級的經驗和專業知識，而且此情況下，會採用不同的處理序。透過這些程式庫中，進入點是在討論區層級，而不是程式碼層級。直接提交到這些程式庫，與新功能或語言關鍵字的程式碼提取要求不太可能成功。

通常看設計程序時，它不是戰鬥。事實上，這些存放庫提交甚至可開始提案。(簽出的 C# 語言提案資料夾bit.ly/2BVUbjf如一下目前列入考量的主要功能。) 相反地，如果您想要建議功能，您會啟動所提交的問題，並標記的「討論區」標籤。如果討論的項目會達到某種程度的共識，使得進一步評估應該被視為，它們被挑選在語言設計會議，接著會收到通知的進一步討論區、實驗和離線的設計工作。提案本身 — 不完成功能 — 然後伎倆之語言設計小組的成員。

處理程序就是要開啟的意見反應，而不是每個人都可以只進行變更，但他們所選擇。分配的磁碟區，並變更的影響是太大，無法不嚴格控制（非常類似於 Linus Torvalds 具有與 Linux 的控制項）。在結束時，專案會是仍處於開啟狀態的來源。如果您想要能夠自由地變更您的核心想要的方式中的程式碼，只是派生存放庫，並立即開始。

這個方法很重要的差異，共同作業程式碼實作開始之前。即使如此，可能會變更為個別的分支中長時間而它們是程式設計（而且重複重新撰寫）及評估。社群是決定什麼東西的形狀將會不可或缺的。開啟討論問題、註解，並提供與現有的提案的意見反應提供給小組的直接存取。

您將會發現，參與可以執行的範圍從簡單到非常困難。加入 API 的方法或類別，比方說，是一件事，但新增了新的語言關鍵字完全是其他項目。

提交 PR 之後發生的情況

在 2018 年 4 月，Roslyn 小組會發現，他們已落後處理已送出的所有 Pr。包含所有變更的 Pr 之後發生的很有可能，其中一些不再是相關項目。若要解決此問題，Microsoft 逐步的，並指派至每個專案的人員。這是他們的工作，以回應所有未來的 Pr，以確認放入的工作更容易無法引領成功。這方面，向他們適當加諸的 Pr 下列類別：

由專案負責人的核准：已核准的 Pr 會指派專案小組，來改善成功採用的機會，並協助將提取要求合併到程式碼基底好友或教練。就表示教練可確保會參與社群成員，遵循與參與者在三個工作天內如果因為任何原因將會拒絕提取要求。
暫止的討論：有時候重要的問題發生，單元測試是遺失、目的不清楚或程式碼無法大幅符合指導方針。在這些情況下，專案負責人會引發社群參與者，找出需要進行哪些方面的疑慮。在兩週內追蹤參與者，是負擔。此外，此群組中的 Pr 需要跟上程式碼基底在這段期間。
已拒絕：提取要求不符合專案的願景、牽涉到太多風險或無法成功解決的優先權。在此情況下的潛在客戶將會拒絕 PR，清楚地識別問題。雖然可以重新提交提取要求，它將會需要重大的變更或重做。

總結

有時候，您可以觀察行為在開啟的遠低於正當性標準的原始碼專案。這可能包括參賽者粗暴、受挫或一再失敗聆聽相反的檢視。它也會包含無法接受的 Microsoft OSS 專案的最終仲裁者為 Microsoft 的角色、重複垃圾郵件存放庫或否則會中斷共同作業的程序的參與者。任何人都無法符合一般 civility 的規則將會發現自己封鎖從存放庫（並傳回下具有相同的假名行為不會收到您任何進一步）。Microsoft 致力於讓參與正面的體驗，並強制執行的程式碼進行是承諾用量的核心。

我建議您檢閱 Microsoft 開放來源辦法在bit.ly/2wmAYlB。同時檢閱在其相關聯的常見問題集bit.ly/2NwNNRa。

我的經驗，如何您的方法變更 Microsoft OSS 主要取決於什麼會產生您想變更表示興趣。我預期大部分的催化劑是缺失或功能遺失的表單中的問題。一開始，觸發程序可能是瑕疵或文件和想要修正此問題的其他讀取器中的問題。或者，也許您正在檢視的基底的 Xamarin 程式碼並探索，您想要覆寫的方法不是虛擬的所以提交 PR，以讓這類。

有些人會想要花上更具挑戰。使用.NET Core，我已被震驚（仍）沒有可輕鬆地接受命令列引數並加以剖析成強類型物件，我可以透過它存取值在程式中的一個命令列剖析器的事實。這是此 itch 提示我開始與 Microsoft 的 Jon Sequeira （下面是撰寫命令列剖析 Dotnet cli）共同作業，來建置這類剖析器。可惜的是，程式碼仍然不太穩定而且我們需要專案太業餘我們參與開放原始碼。希望它不會太多時間才能讓它才能受惠於 OSS 社群的參與，我們可以開啟給大眾使用，此專案是。在過渡期間，如果您有很長的時間，若要設定專用和有興趣在我們的剖析器專案，磾氆咘迼 Kathleen 或我，我們可以算出取得您所涉及的方法。而且，您也可以是，我剛才介紹另一種方式來參與 — 自發性之前的程式碼是公用。

Mark Michaelis是的 IntelliTect，他擔任其技術架構設計人員和培訓講師的創辦人。他已成為 Microsoft MVP 近二十多年的同盟，以及 Microsoft 區域經理自 2007年。Michaelis 是數個 Microsoft 軟體設計檢閱小組，包括 C#、 Microsoft Azure、 SharePoint 和 Visual Studio ALM。他在開發人員會議上發表演說，並寫過許多本書，包括他最新，「基本 C# 7.0 （第 6 版）」 (itl.tc/EssentialCSharp)。在 Facebook 上連絡他facebook.com/Mark.Michaelis，在他的部落格上IntelliTect.com/Mark，在 Twitter 上： @markmichaelis或透過電子郵件地mark@IntelliTect.com。

感謝下列 Microsoft 技術專家協助進行共同作業，並檢閱這篇文章：Kevin Bost (IntelliTect)，Kathleen Dollard、 Neal Gafter、 Sam Harwell、 Immo 解、 Jared Parsons、 Jon Sequeira Bill Wagner，Maira Wenzel

MSDN Magazine 論壇中的這篇文章的討論