スターを買わずにGitHubスターの増幅を図る
開発者ネイティブなクリエイターのデモが、偽のスターや裏付けのないコンバージョンの主張なしに、GitHubリポジトリへ質の高い注目を集める方法。
Saidクリエイター, AISCスターはシグナルであって、製品上の成果ではない
GitHubのスターはブックマークであり、公に示された関心のシグナルだ。それは誰かがそのプロジェクトをインストールした、成功裏に使用した、あるいは貢献するという証明ではない。クリエイター向けのコンテンツを発注する前に、目標を定義しよう。有用なリポジトリ訪問、インストールの成功、アクティブなユーザー、質の高い貢献などだ。スターはその目標と並行して追跡すべきであり、その代わりにすべきではない。
クリエイターによる増幅は、有用なデモンストレーションを通じて発見を勝ち取るべきものだ。スターを購入する、空虚なクリックに報酬を与える、スター数を導入実績のように見せることは、プロジェクトについて誤解を招く印象を作り出す。投稿が消えた後も、開発者はコード、ドキュメント、メンテナンス体制を見て判断し続ける。
馴染みのない開発者に向けてリポジトリを整える
READMEは問題を説明し、結果を示し、動作するクイックスタートを提供すべきだ。前提条件、ライセンス、対応環境、限界が見つけやすいようにしておくこと。メンテナーのノートパソコンに依存するのではなく、クリーンな環境で手順をテストすること。
認識しやすい結果を生む例を一つ含め、より詳しいドキュメントへのリンクを用意しよう。セットアップに認証情報が必要な場合は、それを安全に取得する方法を説明すること。画面録画の中でキーを露出させたり、非公開の設定を公開するようクリエイターに求めたりしてはいけない。
実際のユースケースを軸にビルダーへブリーフする
プロジェクトを実際に動かし、そのトレードオフを説明できるクリエイターと組み合わせよう。リポジトリが革新的だと言うだけの台本ではなく、再現可能なワークフローを提供すること。有用な投稿は、入力、出力、それが何を置き換えるか、まだうまく機能しない部分を示す。
異なるデモンストレーションは異なるオーディエンスに役立つ。開発者向けの統合の手順解説、評価者向けの比較、ユーザー向けのエンドツーエンドのワークフローなどだ。クリエイター自身の判断を尊重し、報酬を受けた参加であることを開示させよう。
ソーシャルでのエンゲージメントとリポジトリへの影響を分けて考える
yuliaiscとNozelcodeについて提供されたAISCクリエイターの事例は、それぞれ390万回と1000万回の閲覧を記録している。提供されたエンゲージメントの合計は、yuliaiscが3万件のいいねと4万3000件の保存、Nozelcodeが6万2000件のいいねと7万8000件のブックマークである。これらはソーシャル投稿上の数値であり、測定されたGitHubスターの増加数ではない。
リポジトリへの影響を測定するには、スターの初期数を記録し、リポジトリ所有者が利用できるトラフィックと参照元を調べよう。該当する場合には、クリエイター経由のトラフィックを識別可能なランディングリンクで追跡すること。有機的な発見や他の告知も結果に影響することを認めつつ、定められた期間での変化を報告すること。
やってくる開発者に備える
リリース期間中、イシューとインストールに関する質問のためにメンテナーの時間を確保しよう。突然の注目の流入は、開発者がツールを実際に動かせて初めて有用なものになる。新規参入者の目に触れる場所に、修正とドキュメントの更新を公開すること。
強力なフォローアップとは、新しい例や、繰り返し寄せられる技術的な質問への回答であって、再びリポジトリにスターを付けてほしいという依頼ではない。増幅がうまくいった最良の証拠は、開発者がプロジェクトを使い、改善するために戻ってくることだ。