GitLabへのコントリビュート

(株)Ruby開発

佐藤　洋行

自己紹介

会社�　(株)Ruby開発

仕事�　ソフトウェアエンジニア�　主にRuby on RailsでWEB開発

OSS活動�　GitLabコントリビューター�　GitLab MVP (5.1, 10.0)

Twitter: @hiroponz79

GitLab: hiroponz

2

コントリビュートの種類

GitLabへのコントリビュートと一言で言っても�以下のように様々な方法があります

• エンジニア
• 新機能の追加　←　今回のメインテーマ
• 不具合の修正
• 非エンジニア
• ドキュメントの整備
• バグの報告 (Issueに投稿)
• 新機能の提案 (Issueに投稿)
• Issueの整理 (GitLab Issue Bash 2017 Q4 in Japan)
• UIの日本語化 (Slack #translation)

3

コントリビュートのモチベーション

GitLabにコントリビュートするモチベーションは人それぞれです。�例えば、以下のような感情がコントリビュートするきっかけとなります。

• 好奇心
• 向上心
• 承認欲求
• ストレス
• 不満
• 怒り

​

4

GitLabを使用していて感じたストレス

自分が👍したGitLab CEのIssueを簡単に見つけられない

【背景】

GitLab CEのIssueをチェックしていて、欲しいと感じた機能や遭遇して困っている不具合に対して👍を付けていました。数日後に👍したIssueの現在の状況を確認するために、Issueを探しましたがIssueの数が多すぎてなかなか見つけることが出来ませんでした。�※ちなみに、現在オープンされているIssueは9,000件を超えています。

【願望】

自分が👍したIssueを絞り込む機能が欲しい。

5

類似のIssueを探す

とりあえず、既に同じような要望がIssueに投稿されていないかI検索しました。その結果、自分の要望と完全に一致するIssueは見つかりませんでしたが、以下のようなIssueが見つかりました。

• Feature proposal: GitLab Bookmarks (CE #34390)
• List of all subscribed issues (CE #12697)
• Show issues I :star:ed (EE #1939)

上記のIssueのいずれかが解決すれば、自分がやりたいことは達成できそうでしたが、残念ながらまだ誰も手を付けていませんでした。�そのため、ソースコードを調査して、それぞれの実装コストを見積もって、簡単そうなら自分で実装してみることにしました。

​

6

GitLabソースコードの基本的な調査方法

Railsアプリの一般的な(?)デバッグ方法ですが、参考までに紹介します。

1. 追加したい機能に関連がありそうな機能を動かしてみる
• Issueに👍を追加する
• Issueをauthorで絞り込む
2. ログファイルの出力を「tailf -f log/development.log」などで追跡する
• 関連しそうなModel, Controller, Viewの当たりを付ける
• 上記のファイルに書かれているメソッド名やクラス名などでgrepする
3. ソースコードを理解するためにデバッグする
• putsで変数の中身を表示する
• rails consoleでクラスの動作を調べる

​

開発環境の構築は公式サイトを参考に行って下さい。

7

実装方法を調査・検討 (1)

とりあえず、提案されている機能を実装するには、どれくらいの実装コストが必要かを見積るために、ローカルの開発環境でソースコードを調査しました。

• Feature proposal: GitLab Bookmarks (CE #34390)
• バックエンド
• Bookmarkモデルを追加
• BookmarkデータのCRUD処理
• BookmarkしたIssueを絞り込む処理
• フロントエンド
• BookmarkボタンをIssueの画面に追加
• BookmarkしたIssueを一覧表示する画面

8

実装方法を調査・検討 (2)

• List of all subscribed issues (CE #12697)
• バックエンド
• Subscribeモデルの変更
• Subscribeデータのマイグレーション
• SubscribeしたIssueを絞り込む処理
• フロントエンド
• SubscribeしたIssueを一覧表示する画面
• Show issues I :star:ed (EE #1939)
• バックエンド
• Starを付けたIssueを絞り込む処理
• フロントエンド
• Starを付けたIssueを一覧表示する画面

9

調査・検討の結論

調査・検討の結果「Show issues I :star:ed (EE #1939)」は比較的簡単に実装できそうとの結論に至りました。

次の問題は、Starを付けたIssueを一覧表示するUIをどうするかということでした。Issueのディスカッションでは様々な意見が出ていましたが、これと言った方針は決まっていない感じでした。�そのため、基本方針として出来る限り既存のUIを流用し、実装工数が少なそうなUIデザインを検討することにしました。

10

既存のUI: authorでの絞り込み (1)

11

既存のUI: authorでの絞り込み (2)

12

既存のUI: authorでの絞り込み (3)

13

絞り込み機能に共通するUIパターン

GitLabのIssueの絞り込み機能には、以下のような共通するパターンが見つかりました。

1. 何で絞り込むか(token)をドロップダウンで一覧表示する。
2. 選択したtokenの絞り込み条件(value)の候補を�ドロップダウンで一覧表示する。
3. 選択した「token:value」をテキストボックスにセットし、�ビジュアライズする。

14

デザインの検討

「Starを付けたIssueを絞り込む」機能をこのUIパターンに合わせると、(2)の候補の一覧表示が不要となります。�そこで、既存のUIパターンにマッチするように、以下のように機能を変更することにしました。

1. tokenの一覧に「my-reaction」を追加する
2. 「絵文字」の候補を一覧表示する
3. 選択した「my-reaction:emoji」をテキストボックスにセットし、�ビジュアライズする。

15

デザイン案: my-reactionでの絞り込み (1)

16

デザイン案: my-reactionでの絞り込み (2)

17

デザイン案: my-reactionでの絞り込み (3)

18

WIPのMRを投稿してフィードバックをもらう

この時点では、デザイン案は私の頭の中にしかありませんでした。�そのため、通常はこの段階でデザイン案をIssueに投稿して、GitLabのコアチームからフィードバックをもらい、実装の手戻りが発生しないようにするべきです。�しかし、私の場合はデザインを作成して英語でのディスカッションするのが面倒だったので、とりあえず動くものを実装して、WIPのMRを投稿してGitLabのコアチームからフィードバックをもらうことにしました。

投稿したMR: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12962

19

MRの説明に書いた英語

GitLab CEにはMRのテンプレートがあるので、必要な項目を埋めます。

• What does this MR do?
• Add filter by my reaction.
• Are there points in the code reviewer needs to double check?
• UI/UX
• SQL performance
• This filter is ignored if an anonymous user seaches the issues in public projects
• Why was this MR needed?
• I want to search issues that I have added a reaction 👍, 👎 , ⭐ , etc.
• Screenshots (if rerevant)
• 自分のリアクションでIssueを絞り込む様子のスクリーンショット�

20

MRのディスカッションで使用した英語 (1)

実装の区切りがついてコードレビューを依頼する時

「Could you please review this/again?」

「この機能は〜ですか？」という質問に答える時

「Yes/No」

「この機能はIssueとMRのどちらに適用されますか？」という質問に答える時

「Both issue list and merge request list.」

指摘された不具合を再現できなかった場合

「I could not reproduce that.」

指摘された不具合を修正した場合

「Fixed.」

21

MRのディスカッションで使用した英語 (2)

APIパラメーターの仕様について複数案からどれがいいか意見を聞きたい時

「I think there are two options.� * Option 1. my_reaction=star� * Option 2. reaction=start@hiroponz� wdyt」

MRがマージされた時

「Thanks!」

​

以上のように、ディスカッションは中学生レベルの英語でも大丈夫です。

また、フィードバックをもらうためには、遠慮せずどんどんメンションしたほうが良いです。メンションをしない場合、気づいてもらえない可能性があります。

22

最終結果

レビューの指摘に全て対応し、GitLab 10.0で「Filter by my reaction」がリリースされました。また、GitLab EEのIssueをクローズすることが出来ました。

​

しかし、残念ながらGitLab 10.1で「Filter by my reaction」は壊れています。

​

つい先日、バグ修正のMRを投稿してmasterにマージされましたが、

10.2の機能凍結に間に合わなかったので、10.3で修正される見込です。

23

Let’s contribute!

GitLabへのコントリビュートは難しくありません。

みなさんもGitLabにコントリビュートしましょう！

GitLabの開発に興味のある方はSlackの#devにご参加下さい

24

まとめ

• GitLabへの不満はコントリビュートのチャンス
• GitLabへのコントリビュートは難しくない
• GitLabはバージョンアップで割りとよく壊れる
• 壊れても自分で直せる
• 日本人コントリビューターが増えると👍

25

宣伝

(株)Ruby開発ではエンジニアを募集しています！

https://www.wantedly.com/companies/ruby-dev

26