Paolo

我維護一個 Python 下載管理員。一週前，它有 1,500 顆星，卻沒有外部貢獻者。今天有九個人有合併的 pull request。程式碼本身沒有任何改變導致這種情況——真正改變的是問題追蹤器，而我認為我做錯的具體事情比做對的更有用。

明確指出要修改的問題
我第一個「適合新手貢獻的問題」說的是「新增測試」的意思。沒有人接受。真正有人接受的問題會寫出檔案名稱、函式名稱、驗收標準，以及——這後來證明是最重要的——是否需要我的作業系統。我的專案只能在 Windows 上執行，但幾乎所有開放的工作都不需要 Windows，而且在每個問題中清楚說明這一點，解除了大部分的阻塞。

一個大規模清理，分成小塊
我有 30 個幾乎相同的修改，分散在三個檔案中。當它只是一個問題時，已經停滯了幾週；沒有人想一次認領 30 個任何事情。我將它分成四個有標籤的片段，並附上行號範圍，三個在一天內就被認領了。

我做這件事時有兩件事出錯。我少算了一個檔案七行。而且我的行號範圍意外地讓一個項目落在所有片段之外，所以沒有人能夠認領它。這兩個問題都是因為我重新對照原始碼計數，而不是相信自己發佈的問題，才被發現的。

一個已置頂的路線圖問題
一個頁面列出所有開放的工作，按照大小和是否需要作業系統進行排序。這是儲存庫中被瀏覽次數最多的單一項目。

我還置頂了兩個已經關閉的問題，默默地浪費了三個置頂名額中的兩個。請檢查你的。

公開修正自己的錯誤
我已經發表了幾次對自己問題的修正，包含錯誤的數字和正確的數字。這感覺不好，但有效：我合併的最好的 pull request 來自一個人，他修正了他所發起的問題中的一個錯誤，並且說出來了。

如果貢獻者認為你的問題文字是權威的，他們就會實作你的錯誤。

閱讀 diff，而不是描述
有一個 pull request 列出了三個改進。diff 裡面卻沒有這些改進，還有一個空的測試檔案。作者並不是不誠實——他們描述了他們原本打算做的事情。我現在在合併前會檢查每個要點是否與實際的變更相符，並在 CONTRIBUTING.md 中說明我會這麼做。

使用你自己的軟體比閱讀它能發現更多問題
我審核了將近 5,000 行程式碼，只發現一個真正的錯誤。然後我花了一個小時實際執行這個東西，發現了八個錯誤，包括一個速度讀數顯示的速度大約是實際速度的九倍——可以透過將螢幕上顯示的內容與執行紀錄檔進行比較來證明。

每一個都變成了一個有測量數據的問題，所以貢獻者可以用數字而不是感覺來檢查他們的修正。那天下午出現的五個人中有四個接受了其中一個。

我沒預料到的事情
七月，我從當週建立的帳號合併了十八個只有一行的 pull request。它們看起來像是真正的貢獻。它們是貢獻農場——這些帳號在 Stripe、DataDog 和 Microsoft 的儲存庫中都有單一的微不足道的 PR。

我出於善意合併了它們，它們現在永久存在於我的歷史記錄中。如果你維護任何帶有 hacktoberfest 主題的東西，十月就是這種情況發生的時候。在那之前寫下什麼算作貢獻，而不是之後。

我會做什麼不同的事情
從路線圖頁面開始，而不是從問題開始。說明每件事是否需要你的作業系統。在任何人詢問之前，將大型清理工作切成有命名的片段。並在根據閱讀程式碼撰寫任何問題之前，先執行你自己的軟體一個小時。

很樂意回答任何相關問題，包括那些沒有效果的部分。