Paolo

Python製のダウンロードマネージャーをメンテナンスしています。1週間前には1,500スタ—があり、外部からの貢献者はゼロでした。今日は9人の人がプルリクエストをマージされています。コードが変わったわけではありません。変わったのはイシュートラッカーであり、具体的に何を間違えていたのかが、何が正しかったのかよりも役に立つと思います。

何を触るべきかを示すイシュー
最初の「good first issue」は「テストを追加せよ」と同等の内容でした。誰も手を上げませんでした。実際に人が取り組むのは、ファイル名、関数名、受け入れ基準を明示し、さらに——これが最も重要でしたが——OSが必要かどうかを記載したものです。私のプロジェクトはWindows専用ですが、ほとんどの作業はWindowsを必要とせず、各イシューにその旨を記載することで大半のキューが解消されました。

大規模な整理をスライスに分割
3つのファイルにまたがる30件のほぼ同一の変更がありました。1つのイシューとして数週間放置されましたが、誰も30件に着手したくはありません。4つのラベル付きスライスに分割し、行範囲を指定したところ、3つが1日以内にクレームされました。

2つのミスがありました。1つのファイルで7件数え損ねました。また、行範囲が誤って1件をどのスライスにも含めず、誰もクレームできない状態にしていました。どちらも、自分のイシューを信用せずソースに対して再集計したことで発覚しました。

ロードマップイシューをピン留め
オープンなすべての作業をサイズ順およびOSの必要性でランク付けした1ページを作成しました。これはリポジトリ内で最も訪問されたものです。

すでにクローズ済みのイシューを2件ピン留めしており、3スロットのうち2つを無駄にしていました。皆さんも確認してください。

公に訂正する
これまでに自分のイシューに対して数回、誤った数字と正しい数字を訂正投稿しました。気分は悪いですが効果があり、マージした最高のプルリクエストは、イシューの誤りを修正してくれた人からのものでした。

貢献者がイシューの記述を権威的だと考えるなら、彼らはあなたのミスを実装してしまいます。

説明ではなく差分を読む
3つの改善点を挙げたプルリクエストが届きました。差分にはそれらが一切含まれず、空のテストファイルだけでした。著者は不正をしていたわけではなく、実施しようとしたことを記述しただけでした。今ではマージ前にすべての箇条書きを実際の変更と照合し、CONTRIBUTING.mdにもその旨を記載しています。

自分でソフトウェアを使うと、読むよりも多くのバグが見つかる
約5,000行を監査して1つの本物のバグを見つけました。その後、実際に1時間実行したところ8つ見つかりました。速度表示が実際の約9倍の値を表示していたことも含まれており、画面の表示と実行ログを比較することで証明できました。

これらすべてを測定値付きのイシューとして登録したため、貢献者は「感覚」ではなく「数値」で修正を検証できます。その日の午後に現れた5人のうち4人がこれらのいずれかを選びました。

予想外だったこと
7月に、同じ週に作成されたアカウントから18件の1行プルリクエストをマージしました。本物の貢献のように見えましたが、コントリビューション・ファーミングでした。同じアカウントがStripe、DataDog、Microsoftのリポジトリにも単発の些細なPRを投稿していました。

善意でマージしたため、それらは私の履歴に永続的に残っています。hacktoberfestトピックを付けている場合、10月にこれがやってきます。コントリビューションの定義を事前に書き留めておいてください。

やり直すなら
イシューではなくロードマップページから始めます。各作業にOSが必要かどうかを明記します。大規模な整理は、誰かが依頼する前に名前付きスライスに分割します。そして、コードを読む前に自分のソフトウェアを1時間実行します。

これらすべてについて、うまくいかなかった部分も含めて質問があればお答えします。