2017年は大規模オープンソースプロジェクト貢献に挑戦してみました

Technology

オープンソースの世界に参加してみたいけど、何から始めればいいのか分からない。そんなことを言いながら2年ほど経っていた現状に危機感を覚え、2017年の目標を「10人以上のコミッターからなるオープンソースプロジェクトへの参加」に設定していました。

準備期間入れると2016年からやっていたのですが結果として2017年1月3日にMergeされて年明け早々に達成していたので、今年の締めも兼ねて書いておこうと思います。

目次

参加したいプロジェクトができるまで

まず、こちらのツイートを見てhabiticaというタスク管理サービスを使い始めました。

タスクをこなすことで自分のキャラクターのレベルが上がっていき、お金も手に入って装備も買えるようになる。そんなゲーミフィケーションが堪らなく、楽しくタスク管理をして日々を過ごし始めました。

しかしこのhabitica、macOSから使っている時に妙な挙動がありました。タスク名を日本語で入力して漢字の変換を確定すると、タスク自体が確定されてしまうのです。これは1ユーザとして改善を望んでいました。

そしてGitHub Repositoryとコントリビュートについてのドキュメントを読み終えた時、参加したいプロジェクトができていました。

Issueを上げる

今回の場合、まずはWebサービス内の質問用チャットで管理者に問い合わせる必要がありました。問い合わせるにあたって、

  • GitHubに同様のIssueが上がっているか・上げられたことはあるかの確認
  • 事象をgifで録画・保存
  • 発生する詳細条件の絞り込み

を行っていました。

不幸にもこの質問用チャットにファイルアップロード機能がなかったため、今回の事象をすべて文字ベースで英語で説明する必要がありました。
そして予想通り、英語圏には存在しない概念である「ひらがなを漢字に変換する」という行為をなかなか理解してもらえませんでした。もし海外で生活していなければ、この辺りで心が折れていたかもしれません。

やり取りを続けていると、変換に理解があり英語表現が堪能な他のContributerの方がわかりやすい例を挙げながら補足説明してくれました。
当時の自分の様子を、伝えられない焦燥感と「GitHubのIssueでなら画像で説明できるからIssueを立ててもいいか」という一辺倒さ加減が相まって、何でもいいからただコミットしたい人という風に映ったのではないかなと今になって思います。そんな状況でも助け舟を出してくれたこのContributerの方にはとても感謝しています。

補足説明のおかげで「そういうことであればIssueを立てるべき」と判断してもらい、次のステージへ。「ふたりのどちらかがGitHubにIssueを立ててね」ということなったのでContributerの方にお願いすることにしました。

Issueを立てる際の注意ですが、それぞれのプロジェクトでフォーマットが用意されていると思うのでそれに漏れの無いよう記述しましょう。

そして立ちました。感謝の気持ちと最初に録画しておいたgifの添付、このまま修正を担当したい旨をコメントしました。

コードに変更を加える

晴れて自分が主となって立てたIssueの修正を担当できることになりました。

さて、修正するにもまずは開発環境を作らなければなりません。今回はDocker環境が用意されていました。最近ではDocker, docker-composeで開発環境を簡単に作れるようにしてくれていることが多いです。Dockerは使えるようにしておくと良いですね。

ようやくコードレベルまできました。

当時クライアント部分に使われていたのはAngularJS 1.xで、それまで全く触れたことがありませんでした。
それでも落ち着いて、ブラウザの開発機能を使ってDOMのidやclass名を取得してソースコードにgrepをかけて該当箇所を洗い出しました。慣れてくればFrameworkが何であろうが該当するコード一瞬で見つけられると思います。ただ、コンポーネント指向に触れたことがなかったらもう少し時間がかかったように思います。ReactとVue.jsに触れておいてよかったです。

根本原因が「変換確定時にキーアップイベントのみ検知されてしまうこと」だったので色んなアプローチがあったのですが、「タスク確定処理をキーアップイベントからキーダウンイベントに変更する」という対応を取りました。懸念事項として、今後キーイベント周りで何かやりたいことが出てきたら上の変更では面倒なことになるのではないかと考えたのですが、AngularJSからVue.jsへのリニューアルが並行で進んでいたこともあり、『今必要ないものは、必要になったときに加えれば良い』という判断に至った結果です。

結局問題なかったのですが、今でも当時の判断が正解だったのか考えるときがあります。うーん。

Pull Requestを投げる

コードの修正が終わったらForkしてきた自分のRepositoryでTravis CIのテストを通しました。git, Dockerに併せてTravis CIもしくはCircleCIも使っておくと良いと思います。
テストが無事に通ったので、自分のRepositoryから本家のRepositoryにPull Requestを投げました。

Issueと同じく、用意されたフォーマットを確認します。フォーマット以外で気を付けたのは、

  • やったことを一言で書く
  • その一言に至ったまでの調査内容を書く
  • 修正前と修正後がひと目で比較できるようにする

でした。

Reviewersは多くのコードをレビューしなければならないので、余計な時間を省くためにも丁寧に記述すべきです。

PRを投げたら見てもらえるまで静かに待ちましょう。
今回、年末年始にもかかわらず4日ほどで返事をもらえてそのままマージされ、次のリリースで本番に乗りました。

まとめ

オープンソースに貢献することで感じることが多くありました。

このフィールドで戦っているプログラマは強い印象がありましたが、理由がわかりました。参加するためには例え向かう先が使ったことのない技術であろうと、変わらず良いものを作り続けなければならない状態に置かれるため、強くなりますよね。
そして世界中のプログラマたちが近くに感じられました。インターネットってすげぇの再来でした。モチベーションを高い状態で保つことができました。

何の面白みもない言葉になってしまいますが、楽しかったです。

あ、habiticaはゲーミフィケーションの取り入れ方が上手で、Contribute後にhabitica内でもボーナスが貰えます。そりゃこのサービスのことが好きになりますよね。

今回の貢献で一般ユーザからBlacksmithに昇格しました。チャットでも発言するだけで目立てる！

良かったら使ってみて下さい。

オープンソースプロジェクトに参加するにあたってのまとめ

以上、長々と当時の記憶を書き出しましたが、反省点も含めまとめておきます。

  • みんな優しい
  • 英語を勉強しよう
  • 一つ二つの英語の言い回しが伝わらなくても落ち着いて他の言い回しや例を挙げよう
  • 使っているツール・サービスに不満を覚えたらGitHub RepositoryとHow to Contributeを探そう
  • GitHub Repositoryがあったら関連するIssueがないか探そう
  • Issueを立てる時は図や画像や動画を使ってわかりやすくしよう
  • Pull Requestも同様にわかりやすくしよう
  • DockerやCIに慣れておこう
  • Frameworkなど日々新しい技術を試しておこう
  • 自分が使ったことのないLibraryやFrameworkに携わる機会を大切にしよう
  • 妥協したコードを書かないようにしよう
  • 修正過程で思ったことや感じたことは抱え込まず共有しよう
  • やることをすべて終えたら静かに待とう