開源項目的最佳實踐

來自GitHub的Phil Haack在Channel 9網站上舉辦了一次座談會，專一於談論開源項目的最佳實踐。

本次會議的四位與會者都是開源項目的維護者，包括來自微軟拉美區的聽衆佈道經理（Audience Evangelism Manager）Carlos Rojas，用於建立鬆耦合、可維護、易測試的XAML應用的PRISM框架的做者Brian Lagunas，參與了多個開源項目工做的David Paquette，以及適用於C#及VB的分析器庫CodeCracker的維護者Carlos dos Santos。

Haack爲與會者所提出的第一個話題是：對於那些但願加入本身的開源項目的開發者們，他們有哪些指望？Lagunas認爲，提交issue是一種 與項目的維護者開展對話的重要方法。Rojas則指出，對於但願爲項目做出貢獻的開發者，首先瀏覽一遍未解決問題的列表也很是重要。他們兩位都提到了一種 很是實用的相關實踐，即爲某些未解決問題打上一個「隨意領取」的標籤，願意參與這個項目的開發 者均可以領取這些問題。如今甚至還出現了一個「隨意領取」的網站，那些潛在的貢獻者們能夠在此查到來自多個開源項目的各類可「隨意領取」的未解決問題。Dos Santos表示，對他來講，重要的是貢獻者們可以爲項目提交及修復bug，而且切實地用到這些項目。

全部與會者們都認爲，貢獻者應當避免將代碼直接提交併推送至master分支。正確的作法是提交一個pull請求（PR）。Lagunas談論了這 方面更多的細節內容，他所指望的方式是貢獻者可以建立一個屬於本身的分支，在其中實現某些特性或進行bug修復，而後添加相應的測試代碼，最後再提交 PR。到了適當的時機，這個PR將經過某種集中式的篩選操做進行測試，一旦它經過了全部的測試，維護者就將組織一次複審，以確保其中的代碼變動符合項目的 標準。

dos Santos表示，爲了幫助貢獻者們，保證他們的PR符合項目的標準，能夠在項目的根目錄中加入一個CONTRIBUTE.md文件，這種作法很是實用。 Haack也指出，若是項目中已有CONTRIBUTE.md文件存在，那麼在貢獻者提交PR時，GitHub就會自動顯示一條信息，提醒貢獻者去閱讀該 文件。Lagunas特別強調了仔細閱讀CONTRIBUTE.md文件的重要性，由於它有些時候會包含一些重要的內容，而這些內容並不侷限於代碼標準。 舉例來講，Prism項目要求貢獻者經過一個永久的、不可撤消的貢獻者許可協議（Contributor License Agreement），放棄所貢獻代碼的全部權，將其轉交給該項目全部。若是貢獻者自己就受僱於某些公司，那麼這一點就變得尤其重要，由於說不定有貢獻者 會回頭宣稱他對於該項目擁有知識產權。總的來講，與會者都認爲，項目的許可條款必須明肯定義，這一點十分重要。Paquette還特別強調，這種重要性不 僅限於貢獻者，同時也包括項目的潛在用戶。

Haack又將討論的方向轉回了原來的話題上，即如何確保PR不會對項目產生破壞。Lagunas提到了適用於.NET平臺上的開源項目的一個免費服務appveyor，能夠經過該服務對每一個PR進行構建與測試。Haack進一步表示，只要你的GitHub項目中沒有什麼特別古怪的問題，那麼appveyor一般都可以正確地處理項目的各類依賴。

另外一個讓人感興趣的話題是項目的文檔。Rojas表示，在項目中最低限度也要提供一個README.md文檔。Haack以Prism的文檔做爲示 例，指出編寫項目文檔的正確方式，即經過readme文件說明整體狀況，而後再經過其它文件描述各類細節。Rojas還提到了GitHub所提供的另外一個 工具wiki，他認爲能夠經過使用wiki有效地創建文檔。

隨後話題轉向了開源的文化。開源社區在這方面存在着一個問題，若是貢獻者出了某些差錯，有時可能會換來一些粗暴的迴應。與會者們都認爲：應當以良好 的態度對待貢獻者，認識到這些貢獻者們的出發點是幫助這個項目。尤爲某個PR或許是這個開發者第一次爲開源項目貢獻代碼，那麼項目維護者的溝通方式就可能 會直接影響到這名開發者從此看待開源項目的態度。

最後，全部的與會者們都表示，貢獻者們應當努力嘗試克服膽怯的心態，去尋找那些可以點燃本身激情的項目。不要忘記，開源的核心是協做。有許多人對於他們所維護的項目充滿了熱情和感情，尤爲是看到有人在實際使用他們的項目，或是爲這些項目做出貢獻時。

查看英文原文：Best Practices for Open-source Projects

轉載自：infoq.com/cn