- “我不是一個很優秀的程式設計師。”
- “我沒有太多的時間投入進去。”
- “我不知道什麼專案值得去努力。”
開始聽
在開原始碼的一切涉都及到其他人。如果你想加入一個團隊，這意味著瞭解社會，瞭解它是如何工作的。進入一個專案中，並說：“這是我認為這個專案應該做的事”，這通常不視為一件好事。有些專案可能會喜歡這樣的想法，但是如果專案已經執行了一段時間，那這種態度被接受的可能性就很小。聽是要知道這個專案需要以什麼樣加入方式為最佳。
1. 加入郵件列表
對於許多專案，郵件列表都是關於專案開發溝通的主要渠道。在大型專案中，有許多郵件列表可供選擇。例如，PostgreSQL 的專案有不少於 12 個面向使用者的列表和 6 個開發人員的郵件列表。我建議主要從面向使用者的列表和核心開發者的郵件列表開始聽。
2. 關注部落格
由核心開發人員維護的部落格往往會給出在將來的版本當中出現的一些資訊，以及什麼時候能夠得到那些資訊等等。
3. 加入一個 IRC 頻道
很多開源專案都有專門的網際網路中繼聊天（IRC）的渠道，開發人員和使用者掛出問題以及討論專案的進展等等。
4.入門工作
程式碼是任何開源專案的核心，但編寫程式碼並不是幫助入門的唯一途徑。程式碼以及周圍程式碼系統的維護通常都容易被忽視，這些地方不僅能修正錯誤而且能夠創新功能，可以從這些地方入手來參與一個專案。
5. 診斷錯誤
診斷和篩選一個錯誤可以幫助開發人員節省更多的時間來找出問題的細節。如果使用者反映到，“當我做x工作的時候軟體不工作”，那麼這時候你應該檢查這個問題的細節。是否這個問題是重複的，如果是你可不可以建立一組解決這類問題的步驟，將此類問題縮小。即使你不知道是什麼原因造成的問題，你可以把問題的範圍縮小從而減少其他人員解決問題的時間。
6. 關閉修復的錯誤
錯誤往往是固定在程式碼庫的，清理這些東西可能非常的耗費時間，但是對整個專案非常有價值。檢查專案釋出的更改日誌，看看錯誤是否是固定的，如果是可固定的，注意版本號並將其關閉。
處理程式碼
所有有經驗的程式設計師都可以在整個專案的程式碼當中起到很大的作用，你不必認為只有天賦異稟的程式設計師才能對專案起到作用。每個專案都有自己的工作流程，所以在提交程式碼之前詢問清楚如何做。當你修改程式碼時，請確保你作為專案當中的一員，並保持你的程式碼風格和程式碼庫的其他程式碼是相匹配。
7. 測試一個測試版或釋出一個候選版
任何專案執行在多個平臺都可能遇到各種各樣的相容性問題。當測試版或候選版釋出後，該專案負責人希望它會由很多不同的人在不同的平臺進行測試，你可以負責這個工作來幫助專案能夠順利的完成。
8. 修正 bug
這通常都是程式碼工作者剛開始想從事的工作，這很簡單：在 interesting-sounding 系統中找到錯誤並且嘗試修復程式碼，並檢查程式碼的放置是否合適。同時新增測試的套件來測試那些固定的程式碼。有些專案需要 bug 修正並且測試。
9. 編寫一個測試
大多數專案都有一個測試套件的測試程式碼，但很難想象一個測試套件不能附加給它更多的測試。使用類似於 gcov 或者C的測試工具來檢測到未通過測試套件的原始碼領域，然後新增一個測試套件來掩蓋它。
10. 無聲的編譯器警告
構建許多以C為基礎的專案往往會在螢幕上出現奇怪的編譯器警告標誌。這些警告通常是沒有問題的指向的，這時你應該檢查是否該程式碼實際上有隱藏的錯誤。
11. 新增評論
當你開發過的程式碼你感到疑惑時，別人也可能在同樣的地方感到疑惑。此時你應該記錄這樣的程式碼同時提交一個補丁。
使用文件
文件在一個專案中往往是遭到冷遇的一部分。文件可能是以熟悉專案的角度來編寫的，而不是以一個剛接觸專案的角度。因此很多專案的試用文件並沒有被重視起來。
12. 建立一個示例
沒有一個專案有太多的示例，無論是 web API，還是一個 GUI 應用程式都沒有使用的較好的示例，也沒有可以更明顯和迅速解釋正確使用的程式的示例。對於一個 API 或庫，建立一個使用的示例程式，這甚至可以從你寫的程式碼提取出來。因此我覺得建立一個使用的示例是非常必要的。
評論(1)