今さらGoConference 2019 Springに登壇した話 - Tech Do | メディアドゥの技術ブログ　

f:id:hrk02:20190722195317j:plain — Go Contributorの武田さんと、Contribution活動を見守るGopherくん*1

こんにちは、シニアエンジニアの武田です。

本当に今さらなのですが、2019年5月18日(土)に開催されたGoConference 2019 Springで登壇してきたので、そのレポートを書きたいと思います。参加後すぐにサービスローンチ・稼働ラッシュに見舞われ、ようやく着手出来ました、、、という言い訳を許してください、、、

TL;DR

スライドはこちら： HOW A ”NOT THE GREATEST ENGINEER” BECAME A GO CONTRIBUTOR - Speaker Deck
GoへのContributionは決して簡単ではありませんが、時間さえかければなんとかなるものも多いです。粘り強く頑張りましょう！
発表は大変でしたが楽しかったです。とりあえずCfP*2の応募からやってみましょう！

はじめに

そもそも今回の発表は、GoにCommitした経験を良かったところも悪かったところも含めどこかで共有したいなと思ったのがきっかけです。
GoのContributionに関する記事やスライドはいくつかありますが、手続きの紹介だったり一般的な話が多く、いざ自分がやろうと思うと手を付けにくいなと思いました。私は情報科学系の学歴がある訳ではありませんでしたし、Go歴も長い方ではないので、そんな自分でも頑張ったらGoにCommit出来たよ！という話は需要があるのではと考えました。

TwitterでCfPの募集が始まったことを知り、「気軽に応募してください！」という文言を字面通りに受け取って応募したところ、トピックがニッチだったこともあったのか幸運にも当選しました。
案内ページが全て英語だったため英語で諸々進めましたが、全然日本語でも問題ありません。というよりも、日本語の方が多数派でした。そのような流れで、当日話すことは決まりました。

どんな話をしたか

スライドはこちらです： speakerdeck.com

以下、各セクションについて簡単にまとめます。

Contribution活動にチャレンジした理由

なんかかっこいいからです！本当に、それ以上でも以下でもありません。でも、エンジニアとしてキャリアを積み始めた方なら、どなたでもこれは共感してもらえるはず、、！
そんな思いを抱えながらも、でもどうせ自分なんかに出来るはずはないと思って特にアクションを起こさないまま時間だけが経っていったのですが、そんな時にこのスライドに出会いました：

about.sourcegraph.com

これを見て、もしかしたら自分でもContribute出来るかも！と思ったのがきっかけです。

取り組むための準備

まずは公式ドキュメントに従ってセットアップします。これはただひたすらTerminalなどでコマンドを叩く作業です。専用ツールのインストールなどを含めても30分くらいあれば終わります。

取り組む課題の見つけ方

GoのGitHubのIssueページから対象を探すことになります。
そもそも一般のユーザーが取り組めるような課題なのか、解決方針の合意が取れてるかどうか等を見る必要があるため、取り組みやすいQueryで探すことが大事です。そもそも自分が取り組めそうなものが見つからないとすぐに心が折れるため、上手く探し出すことが一歩踏み出す上で大切です。

結果、Goのビルドに関するコマンド（compile, link）のドキュメント改善タスクに取り組むことに決定しました。もちろんソースコードの修正が必要なIssueもありますが、まずはより簡単そうなドキュメント修正からやってみることにしました。

修正提出までの流れ

まずはIssueの内容をちゃんと理解することです。とりあえずはgo compileの-mオプションと、go linkの-a -buildidオプションのドキュメントがないというIssueだというのは理解しました。

ただ、これを直すだけではつまらないなーと思い、compile linkコマンドで他にもドキュメント化されてないオプションあるんじゃないの？ということで各オプションのドキュメントも追加するようにしました。

あとは、とにかくソースや記事を読んで各オプションの振る舞いを理解します。ソースを読み込む中で、簡単に各オプションの振る舞いの説明文を付している箇所を見つけたので参考にし、ドキュメントに追加することにしました。CommitからPRの追加（Gerritというツールを使うとPRという文言は出てきませんのでご注意ください）まで、なんとか最初の修正提出を行うことができました。

フィードバックの対応

フィードバックはとても優しかったです。ただ書き方が優しいだけで書いてあることが易しいわけではありません。ここは英語が苦手であればGoogle翻訳を使ったり、時にはフィードバックの解釈が合ってるかどうかを確認したりしてとにかく進めることが大事です。正直、正しく理解出来ているか自信がない部分もあったため、再修正のCommentにその旨を記載しました。

直接対面して会話できるわけではないので、最短時間で前に進むためには正直になることが一番大事だと考え、格好悪いと思うようなことも書いていきました。
あとは、度重なるフィードバックの理解・修正の繰り返しです。業務が忙しくなったりして全然手が付けられなくなった期間もあり諦めそうになった時もありましたが、そんな私を見捨てずに指摘を続けてくれたレビュワーの方のおかげでなんとか続けることが出来ました。

作業まとめ

Issueを理解する時間や、フィードバックの内容を理解する時間含め、所要時間は合計2,30時間くらいだったと思います。
決して簡単な英語ばかりではありませんが、口頭で即レスポンスを求められるわけではないため、時間をかけてしっかり理解したほうが良いです。もちろん、それでも分からなければ相手に質問を！
関連するソースコードの全てを理解する必要があるわけではありません。思っているほどハードルは高くないかもしれません。
大変でしたが、楽しかったですし、自信も付きました！簡単に出来ることではありませんが、時間さえかければContribution自体は難しいことではないこともあります。ぜひチャレンジしてみてください！

質疑応答

ありませんでした、、発表が英語だったことが原因かと思いましたが、他のセッションでもない時はなかったです。その日の空気というかテンションというか、そういうのに左右される気もします。セッションを終えた時にGoogleのエンジニア（Go言語の開発をしている人）の方が話しかけてくれて、すごく良かったよと言ってくれたのはとても嬉しかったです。登壇するとこういう喜びも味わえますよ！