昨今のプロダクト開発でOSSを何も使っていないという人はほぼいないという前提で、日々OSSを使っていてバグを踏むことも稀にあるんじゃないかと思います。
ここでは、簡単なところから始めるOSSコントリビューションについて書いてみます。
OSSコントリビュートは難しくない
もうこれに尽きます。
簡単なところではドキュメントの日本語や英語に誤字脱字を見つけたら、それに対してPull Requestを投げるだけでも十分なのです。
Issueを検索・立てる
もし技術的なところで困ったらまずはIssueを見てみましょう。
検索をして自分と同じ状況で困ってる人がいたら、そのIssueや内部のコメントにリアクションをしたり、「I have same issue」と追加コメント入れたりするだけでOKです。リアクションが多ければ多いほど人目につく＝誰かが対応してくれるかもしれない優先度が上がるのです。
もし困ってる人が他にいなさそうで、自分だけ踏んだバグそうでしたらIssueを作りましょう。
ただし各OSSでIssueの書き方にテンプレートやルールがある場合もあるので注意が必要です。（大体はREADME.mdやCONTRIBUTING.mdに記載あり）
英語に自信がないという方は、日本語で書いたIssueの下書きをAI「この文章をエンジニアがGithubで使う英文に書き換えてください」とでも投げれば大丈夫です。
git fork → 修正 → Pull Requestを投げる
この部分は皆さん解説されているので詳細は参考サイトを参照してください。
参考：
マネージャーの人はOSSコントリビューションチャンスを見逃すな
マネージャーやテックリードの場合、技術的課題や問題について議論する場面も増えると思います。
そういうときは是非メンバーにOSSコントリビューションチャンスを譲ってほしいわけです。
例えばペアプロやモブプロでドキュメントの相互リーディングをやっていたときに見つけた誤りや他言語との差分。これらを修正する作業をそのままメンバーに振りましょう。
また、ジュニア層のメンバーが技術的につまずいてる点がOSSのバグが起因だったとき。このときも具体的な修正の方法や方針を提示したうえでOSSに対するPull Requestまですべてメンバーにやらせてください。
こうすることでメンバーは自信が持てますし、キャリアとしてもプラスになります。
OSSコントリビューションは、仕事を作ることと同じです。自分が損をするという思考にならないよう「メンバーの成長が自分のアウトプット」と意識することが大事です。
組織全体で快適なOSSライフを楽しみましょう！