注意

本稿は何かしらのアクションなど解決を求めるものではありません。
いちポエムとして笑って流してください。

言いたいこと

（日本の）世の中にはハッカソンにアイデアソンもあるのに、意見やアイデアはコントリじゃないんですか…？

Q. `git log`に反映されないからコントリに反映できないのでは？

Issueやコードレビューはしっかりコントリに反映されるので、そんな事はないはず。

Q. アイデアだけでは貢献性が低いのでは？

アイデアをいただいて対応する事を考えた場合、貢献性が低いアイデアを実装した場合はコントリに反映されます。
貢献性が低いアイデア自体はコントリに反映されません。これはおかしいと思います。

Q. 直接運営に言ってみては？

今回の問題はGithubの問題を提起したいものではなく、Github転職プロジェクトの一環で気付いたものです。
元記事主やサービスにクレームをするものではありません。

誤解させてる気しかしないので、言い訳

フォローというワケではないんですが、私個人として採用基準を色々模索してみて実施しているエージェント・スカウト事業社は好感を持っています。
そもそも私自身もGithub転職プロジェクトを掲げて試行錯誤している最中なので、こういったサービスがうまく定着してくれればエンジニアに新しいバリューを提供していけると思います。
もちろん、空pushをbatで見た目上のコントリ数を増やせてしまうため、単純なコントリ数を計測するだけでは問題点もありますが記事主さんは認識していそうな印象を持っています。

参考までに、過去に公開リポジトリのコードをAIに掛けて独自基準で評価するシステムを活用したエージェントがありました。
少しだけ私も関わったんですが、今でも活動されているんでしょうか。

エンジニアリングスキルとマネジメントスキル

今回の趣旨はここなんでしょうね。
Githubが評価しているのはエンジニアリングスキルであって、マネジメントスキルではないという意味であれば納得できます。
サイト名にgitがあるので、コントリビューションにgitの使い方が上手い人を想定していそうな気がしないでもないですが、git submodulesとかgit filterを評価しているようには思えないので、この辺りも判断が難しそうです。

コントリ数で評価する方法もアプローチとして面白そうですが、課題は多そうです。

採用者は見極めを、被採用側は発信を

これまた誤解を与える表現になってしまいましたが、採用者がする見極めとは応募者の演技を見抜くとかそういう話ではありません。
今回のケースだと自身（自社）の採用システムは応募者に正しいメッセージを発信できているか、勘違いさせてしまった結果、期待していた人物とは異なる方が応募してしまった場合はサービス側の問題だと受け取れているかどうか、というお話です。
実際は採用側はシステムに明るくない人事部の方である事が多いと思いますので、なかなか議論されにくいですが採用で独自システムを使用している場合、エンジニアの方は上記の観点で採用活動に同席されると自社サービスの問題点に気付きやすいと思います。
また、案件を取ってくる営業の方にとってデータを投入しやすいシステムである事も重要な観点です。この辺りは運用の仕方もあると思いますが、結局のところ人材マッチングの精度を上げていく事ができれば、どんな採用システムでも解消できていくと思います。

被採用者は、エントリーシート(通称ES)を送るのがよくやる発信作業ですが、ESに書いていない（書けない）内容で公開可能なものはバンバン出してしまっていいと思います。
この考え方が合う企業からは別途メッセージが来るでしょうし、逆に合わない企業からはメッセージが来なくなるので、一種のフィルタリングができます。
後は、発信者（被採用者）が企業の話を聞いてみて、両者が合うものを選べば良いと思います。
もちろん、専門性の高いスキルやキャッチーな経歴があるならESを作り込むのも一手です。

おまけ：Github Wikiをコントリビューションに反映する方法

https://github.com/(ユーザーID)/(リポジトリ名).wiki.gitがWikiの更新履歴の全部を持っているので、これをコントリビューションに反映させるために通常の手段でリポジトリを作ってpushするだけです。
Wikiの更新をトリガーに出来たかどうかは分かりませんが、リアルタイムでなくてもいい場合はGithubActionsのworkflowトリガーをタイマーにすることで自動化できます。

次の記事