下面是一個事實：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 和一個不成功之間的差異。

此外，文檔團隊是最快響應提出的問題和 Pr，分配給每個區域對輕微地址貢獻的人員之一。一個原因文檔編輯很簡單：它通常不需要您來克隆存儲庫提交更改。相反，您可以使用 GitHub 基于 Web 的編輯 UI，它能自動使用分叉并為您提交拉取請求。

PR 評審也是參與的重要方法。每個項目需要拉取請求反饋和 Microsoft 團隊是感謝 PR 評審發布內容。我知道我已經非常感謝 — 和學習從 — 我已提交到.NET 的工作原理的評審。為我的最大經驗是時間的，我不能在跳轉，并隨意或執行其他操作之間薄片中做出了重要貢獻。在此級別的代碼需要經過認真的考慮，仔細地實現和重要的協作。最后，我很感謝拒絕的 Pr 和接受的 Pr。PR 評審是一個很好的步驟，并幫助解決開放源代碼開發。

第一次可接近問題

為準備采取行動上多個文檔，Microsoft 提供了一些指導。使用"第一個問題"等描述符標記，并且容易很適合不熟悉游戲開發人員的問題。Microsoft 甚至要求活動項目成員，為了避免快要結束的版本中，直到第一次可接近問題，因此將更容易問題提供的熟悉的開發人員保持到項目和降低復雜性欄的入門知識。此外，第一次可接近頻繁問題描述了如何查找問題的文檔鏈接，而不是新的開發人員在嘗試查找特定缺陷大海撈針 flailing 的是大型存儲庫。Roslyn 團隊，例如，一個很好的第一個問題必須包括：

• 解決方法是很有必要的文件的鏈接

• 測試需要轉到標識

• 開始使用 Roslyn 的設置說明

• 常規發布內容策略

傾向于選擇來自新用戶的貢獻承諾可以擴展到如何接受 Pr。對于標記為"良好第一個問題"的 Pr，Microsoft 不提供首選項設置為新的參與者，Pr 接受通過來自現有 contributors （參與者）。更重要的是，Microsoft 職員標記為"良好第一個問題"的問題將直接回答問題的人員而言，若要解決此問題。該位獲得詳細可以是指導的在參與的第一個階段中重要。

很明顯，Microsoft 轉去獲取第一次參與者參與。Roslyn，例如，是一個復雜、 4 萬行代碼庫不是重點所在。通過具有吸引力的新參與者，Microsoft 的 OSS 工作使外部開發人員組成的活躍社區。

定期撰寫

接受在第一個拉取請求后，可能要執行更復雜的問題和功能。有"想要幫助"和"最，無法用于 grabs"等來表示問題可能是很好的目標為社區的問題標記 — 盡管不一定適用于第一個計時器。(請參閱最多為 grabs.net來瀏覽項目和相應問題的列表標記此類與第一次可接近或想要的幫助。) 標記為使用這些標記可能的問題涉及更多的工作或更深層次的項目不是可以提供主體;但是，它們是定義完善，并且不需要與項目團隊的廣泛協作。但是，還有您最好按照定義工作流：

• 應與團隊和路線圖，以避免被拒絕的時間范圍內討論了超過 bug 修補程序級別的發布內容

• 發布內容應該是針對主 — 不是針對一個實驗性功能分支

• Pr 必須與主分支的提示輕松合并

• Contributors （參與者） 應確保登錄參與者許可協議 (請參閱cla2.dotnetfoundation.org)

如所料 Git 具有豐富經驗的開發人員，務必在本地分叉 （克隆到您的計算機） 中工作，并提交 PR 通過要考慮的代碼當然，您可以創建本地，一個分支但提交 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 需要明顯更高級別的經驗和專業知識，并在這種情況下，使用不同的進程。使用這些庫的入口點是在討論級別而不是代碼級別。直接提交到這些庫使用的新功能或語言關鍵字的代碼 PR 不太可能成功。

設計過程通常可見時，它不是 free-for-all。事實上，甚至不使用征求建議書啟動這些存儲庫的提交。(簽出的 C# 語言征求建議書文件夾在bit.ly/2BVUbjf為仔細查看當前正在考慮的主要功能。) 相反，如果你想要推薦一種功能，您首先提交問題并標記與"討論"標簽。如果討論項目達到一定程度的一致性，以便進一步評估應被視為，它們被選取在語言設計會議，這樣又知悉的進一步討論、 試驗和脫機設計工作。征求建議書本身 — 不會被終結的功能，然后提出語言設計團隊的成員。

盡管過程用于打開反饋，并非每個人都可以只需進行更改，但他們選擇。分發數量，以及更改的影響是太好不嚴格控制 （非常類似于 Linus Torvalds 具有與 Linux 一起的控件）。最后，該項目是仍開放源代碼。如果您希望能夠自由地更改需要的地方的任何方式中的代碼，只需將存儲庫分叉，并開始。

這種方法是進行協作處理代碼實現開始前的重要方法。即使這樣，可能會變化很長一段是一個單獨的分支中，而它們進行編程 （并反復重新進行編程） 和計算。社區中決定什么某事物的形狀將會至關重要。打開要討論的問題，注釋，并提供使用現有的征求建議書的反饋提供給團隊的直接訪問。

你將注意到，導致可運行的域范圍從簡單到極其困難。將方法或類添加到 API，例如，是一回事，但添加新的語言關鍵字完全是其他內容。

提交 PR 后發生的情況

在 2018 年 4 月 Roslyn 團隊意識到他們具有對處理所有具有已提交的 Pr 方面滯后。與 Pr 后發生的所有更改，很可能，其中一些將不再相關。若要解決此問題，Microsoft 單步執行和分配給每個項目的人員。這是為了響應所有未來的 Pr 以確保將放入的工作是更有可能會成功。向該工作，他們落實到位，Pr 的以下分類：

• 項目主管已審批：已批準的 Pr 是從分配的同學或教練項目團隊提高成功被采用的機會，幫助將拉取請求合并到基本代碼。教練可確保社區成員已同時參與，這將執行 contributors （參與者） 在三個工作日內如果由于任何原因拒絕拉取請求。

• 掛起的討論：有時非常重要的問題突然出現 — 單元測試是缺少、 目的不明確，或代碼無法顯著滿足這些指導原則。在這些情況下，項目領導會引發與社區參與者，確定應該做什么的問題。潛能，參與者可以在兩周內執行后續操作。此外，在該分組中的 Pr 需要及時了解代碼基在此期間。

• 已拒絕：拉取請求不符合的項目愿景、 涉及巨大的風險或不能成功解決優先級。在這種情況下該潛在顧客將拒絕該 PR，清楚地確定問題。雖然可以重新提交拉取請求，它將需要進行重大更改或重新編寫。

總結

有時，您可以觀察中的行為會打開源代碼項目組成的遠低于體面而主動的標準。這可能包括原始、 某事或反復失敗偵聽對立視圖的參與者。它還包括無法接受 Microsoft OSS 項目最終仲裁器作為 Microsoft 的角色、 重復垃圾郵件存儲庫或否則會中斷協作過程的參與者。任何人都不能遵循常規 civility 的規則將發現自己阻止從存儲庫 （并且返回下具有相同偽行為不會使您任何進一步）。Microsoft 致力于為所有，使參與積極的體驗和強制行為準則是上述承諾量的核心。

我鼓勵您查看 Microsoft 開放源代碼行為準則處bit.ly/2wmAYlB。此外可以查看在其關聯的常見問題解答bit.ly/2NwNNRa。

在我的經驗，如何方法對 Microsoft OSS 進行更改取決于很大程度上生成想更改您關注的內容。我希望大多數人將對，從而促進是有缺陷或缺少的功能的窗體中的問題。最初，觸發器可能缺陷或文檔，并希望修復其他讀取器中的問題。或者，也許你正在努力 Xamarin 代碼庫中并發現您希望重寫的方法不虛擬的因此提交 PR 以使其此類。

有些人將需要在更大的挑戰。使用.NET Core，我都已通過這一事實 （仍然） 沒有一個可以輕松地接受命令行自變量并將他們解析到從中我可以訪問我的程序中的值的強類型對象的命令行分析器已 astounded。這是提示我開始與 Microsoft 的 Jon Sequeira （Dotnet CLI 為編寫的命令行分析器） 人員協作來構建此類分析器此得。唉，代碼仍然不太穩定并對我們進行項目太休閑我們參與開放源代碼。但愿不會太長之前此項目是我們為公開，因此也可以受益于參與度的 OSS 社區可以打開。在此期間，如果您有很長時間才能將專用和對我們的分析器項目感興趣，將一封電子郵件發送給 Kathleen 或與我們可以推斷出獲取涉及一種方式。并且，是的我只是引入了另一種方式參與 — 自發之前代碼是公共的。

---

Mark Michaelis?是 IntelliTect 的創始人，擔任首席技術架構師和培訓師。他一直是 Microsoft MVP 在近二十，和 Microsoft 區域總監自 2007 年以來。Michaelis 還是多個 Microsoft 軟件設計評審團隊（包括 C#、Microsoft Azure、SharePoint 和 Visual Studio ALM）的成員。他在開發人員會議上發表演講，并撰寫了大量書籍，包括最新"Essential 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 Landwerth、 Jared Parsons、 Jon Sequeira Bill Wagner，Maira Wenzel

原文地址: https://msdn.microsoft.com/zh-cn/magazine/mt830359

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的[机器翻译]参与 Microsoft 开放源代码软件项目的方式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。