OSS の門をくぐってみた

OSS Gate は OSS 開発への入り口 (門) の付近でまごまごしがちな、OSS に興味あるけどあまり活動できていない人 (ビギナー) たちを、積極的に OSS 活動できるようにできる人 (サポーター) たちがサポートしてくれるコミュニティです。

今日、OSS Gate のオンラインワークショップにビギナーで参加したので、その体験記をしたためます。

学び

楽しく物事をやるために大事なこと

• プロダクトへの愛
• 開発者への尊敬
• 貢献への感謝

身につけるべきよい習慣

• 作業メモを残す

OSS とか関係なく、仕事でも趣味でも大事なことを学べた気がします。

やったこと

参加した各ビギナーがそれぞれ日頃使っていたり関心のある OSS を実際に使ってみて見つけた「不」に対して、プルリクとかバグレポートとかに仕上げて出します。

半日でこれをやります。え、できんの？って疑いながら参加しましたが、サポーターのみなさんの手厚いフォローもあり、なんやかんやでできちゃいました。

貢献する OSS を決める

事前にお題の OSS があってそれについてやる、とかいう仕込みはありません。100% ガチです。サポーターの人とどの OSS にしようね？ってところから決めていきます。普段からよく使うもの・関心があるものから選びます。そういったものにはユーザーとして愛着が湧いていたり、湧きやすいからです。OSS への貢献はあくまで自発的なものであり、そうでないと本当に意味のある,ユーザーのためになる貢献が生まれにくいということでしょう。

ちなみに、実際には「OSS らしきもの」をリストアップして、貢献対象の候補が OSS かどうかを調べて (要するに、どういうライセンスか調べて) る作業をやりました。たまにライセンスがよく分からないものとかあるみたいです。

実際に使ってみる

一人のユーザーとしての視点で改善点を見つけるために、実際に使ってみます。プロダクトの開発者はこの世で最初かつ最もプロダクトへの愛着をもったユーザーでもある訳ですが、彼らはプロダクトの内情を詳しく知っています。そうであるが故に、事前に十分な知識のない一般のユーザーの視点はもちづらい、ということもあります。一般のユーザーとして自分がつまづいたところは、他のユーザーもつまづきやすい一方で、開発者としては気づいていない・放置せざるをえない状況である可能性もあり、そういうところをカバーするような貢献ができるとみんなハッピーという訳ですね。

実際に使う際は、何をやったか・どう考えたか、後から振り返られるようにするために作業メモをなるべく詳細に残します。README など公式のドキュメントにしたがってインストールからやる訳ですが、どのステップをやってどうなったとか、どういうキーワードでググったとか、なるべく詳細に。GitHub の Issue や Slack、Twitter など、URL とか画像も貼れて、時系列でトレースできるものでメモを残すのが便利です。サポーターの人が実際にこういう感じでやるんだよ、と作業メモを残す様子を実演してくれたので分かりやすかったです。

どういう貢献ができるか探す

サポーターの人と一緒に作業メモをつかってやったことを振り返りながら、貢献できそうなことを探します。貢献と言っても色々な方法があって、コードを追加・修正するものから、ドキュメントを整備するものや、バグレポートなど幅が広いです。正直大したことができていなくても、何かしら貢献できそうなネタが見つかるものです。そういう勘所を押さえているサポーターのみなさんはさすがです。いずれにしても、作業メモが全てであり、失敗したこと、つまづいたこと、ググらざるを得なかったこと、などはちゃんと記録しておくのが大事です。

正直開発者が手をかけたくない・かけられないけど、ユーザーみんなにとって意味のあるような事柄で貢献できると実はみんなハッピーになれるんだよ、開発者は大事な機能・重大な問題にリソースをかけたいからね、というサポーターの方からの解説になるほどとうなずくばかりでした。

プルリクを出してみる

どのような形で貢献するにしても、ユーザーとしての意図を開発者に正しく伝えなければならないため、両者の視点を埋められるように情報を整理して提供しなければなりません。具体的には次の三つにまとめます。(日常の仕事でもみんなこういう風に問題を報告してくれればなー、と思ってしまいました。なんか怒られました、とか。知らんがな。)

• 再現手順
• 期待される結果
• 実際の結果

今回はドキュメント通りに操作したけど、フレーム内に期待通りにウェブページが表示されず、504 Gateway Time-out が出る、という現象をたまたま引き当てました。ただ、フレームにあるリロードボタンを押せば解消できました。そこで、そういう事態になったらリロードボタンを押せばいいよ、というちょっと気の利いた一文を入れてもらうためのプルリクを出すことにしました。ただそれだけの内容なのですが、気を配るべきポイントがいくつもあることが実際に作業をしてみて分かりました。確かに、受けとる側の身になったら、指摘のポイントはいいけど伝え方・直し方がムチャクチャだとちょっと萎えますもんね。自分のプロダクトのように愛着がないと、そうそうここまで気配りできないですね。(自分は果たしてここまで相手のプロダクトに気を配って日常の仕事をしていただろうか、と思ったり。)

• プルリクで出すべきか、バグレポートで出すべきか
  • プルリクで出せばドキュメントのどこにどういう説明があるといいと考えているかが伝わりやすくなる
  • ユーザーで対応すべきならドキュメントに書けばいいが、実装を直すべき問題ならバグレポートの方がいい
• 既にプルリクや Issue が出されていないか調べる
  • 人気の OSS になるほどプルリクや Issue の数がえげつないので、重複した報告はなるべく避ける
  • 結果的に重複しても、それは既にあるものと同じという結論で処理されるので、過度に気にしなくてもいい
• 貢献の仕方のガイドライン
  • CONTRIBUTING.md とかで貢献の仕方・貢献する際の注意事項が書いてあるときはちゃんと読んで従う
• 追加する一文の体裁
  • 改行の仕方、一文の長さ、言葉遣いなど、今のドキュメントの書き方の特徴にそろえる
• コミットのメッセージの流儀
  • 本家のリポジトリでのコミットメッセージの書き方・情報量に合わせる

あと、プルリクで変更点の説明文を書く前に、その OSS に対する感謝や賛辞を伝えるといい、というアドバイスもサポーターの方からいただきました。習わし・テクニック的な側面があるっちゃあるのかもしれませんが、その OSS への愛着があれば自然な感情ですし、こういう機会を活かしてそれを開発者に直接伝えるというのはいいことだな、と思いました。

さいごに

サポーターのみなさんに大いに助けられたとはいえ、半日でできちゃうのね、というのが分かったので、自分の中でかなりハードルが下がりました。半日といっても講義や振り返りの時間もあるので、実際の作業時間は数時間くらい。OSS コミュニティでの貢献の仕方を学んだつもりが、日々の仕事の姿勢まで勝手に自省することになって、OSS 活動は深いです。

あと、サポーターの方の、OSS の貢献に失敗はない、という言葉が心に染みました。今回出したプルリクが採用されるかどうかは分かりませんが、正直、出せた時点で成功であり、運よくとり込んでもらえれば大成功。ダメでも、なぜダメか分かれば次に繋がるので、それも大成功。プラスしかないので、みなさんやるしかないですね。

(2020.12.16 追記)

なんとあっさりマージされました！OSS Gate サポーターのみなさん、改めてありがとうございました。