「GitLabコミュニティへのコントリビュート」聴講レポート #gitlabjp

発表資料

docs.google.com

自己紹介

• @hiroponz
• (株)ルビー開発
• 勤務地は仙台
• 今日はこれのために出張してきた

GitHubとの違い

• GitLab ECは開発に参加できる！

類似のOSSとの違い

• 似たようなものがあるが、それぞれ開発言語が違う
• 開発リソースが違う
  • GitLabは営利企業が開発を主導
• マシンスペック
  • 他よりもマシンスペックをくう
    • Gogs < GitBucket < GitLab
• 大規模利用
  • GitLabはGitLab.comで利用されているので、スペックを上げれば大丈夫（数千人単位も可能）

コントリビュートの話

• ソースコードの修正
  • 今回メインで話す
• ドキュメントの整備
  • タイポ直し
• バグ報告
  • twitterで文句を言ってないで
• 新機能の提案

きっかけ

• 前職でGitLabを導入したらバグを踏んだ
  • ShiftJISのバグ
• わかりそうだったので修正してPRを投稿
• すんなりマージされた
  • You are Welcome!

わーい、たのしーっ

• いっぱいPRを出した
• GitLab MVPに選ばれた
• 毎月22日に新バージョンがリリースされる
• 各リリースのブログポストで発表される
• 基本的には栄誉賞

コントリビュートのメリット

• GitLabが便利になる
• 効果的な使用方法を学べる

GitLabが便利になる

• 仕事の効率が上がる
• EEに追加予定の機能をCEにも追加できる
  • EEのissueで見て、実装してCEにMRを送れば良い
  • EEに追加された後のMRはリジェクトされる
• 社内のGitLabを魔改造しなくてよい
  • GitLabはVerUpのサイクルが早いので辛くなる

GitLabの効果的な使用方法を学べる

• GitLab社自身がヘビーユーザー
  • 使い方を学べる
  • リリースサイクルの仕方とか
  • 6000を超えるissueの捌き方
    • 多分捌けてない
  • 高速な機能追加の実現方法
• 開発者間のコラボレーションを眺められる
  • GitLab社はフルリモートチーム
  • 効果的なコードレビューの方法

実践的なRailsの開発知識が身につく

• Gem fileの参考
• メンテナンスしやすいコードの書き方
  • コミットログを眺めるだけでも学べる
• テストコードを書くことをルールとしている
• 比較的モダンなJS開発ができる

英語でのコミュニケーション能力が身につく

• ソフトウェア開発の共通言語
• 応用範囲が広い
• キャリアにも繋がる

その他諸々

• 転職の時にプラス
• 執筆依頼が来る
• スピーカー依頼が来る

コントリビュートの方法

• ガイドラインを熟読して下さい
  • 3回ぐらい読めばなんとなく分かる
• Community Contributionのラベルを貼られた他人のMRを参考にする
  • 社員以外の人

マージされやすくなるポイント

• Issueがあるかどうか
  • なければ起票してから
• バグ修正の方がマージされやすい
• 機能追加の場合、簡単なテストを追加する
  • 1個の正常系のテストだけでも良いので…
• UIの修正の場合、修正前後のスクリーンショットを貼る
• パフォーマンスの場合はベンチマークの結果を載せる

注意点

• DBマイグレーションが必要な場合はダウンタイムを発生させないようにする
  • カラム削除とか
• パフォーマンスを著しく悪化させない
  • アクセスを著しく増加させるのはNG
• コードのライセンス
  • CEのマージはEEのマージもされるので、商用利用を認めていないのはNG
  • 機械翻訳のコピペはNG
    • 近々多言語対応されそう
• 礼儀正しく

英語の壁

• 高校レベルの英語でもOK
• 分からなかったらGoogle翻訳で
  • 相手も慣れてる
• GitLab社社員は親切

GitLabIssueBash

• IssueのCloseキャンペーン
• 3月4日 9:01〜3月8日 8:59
• Tシャツとか貰えるかもしれない
• https://about.gitlab.com/2017/02/10/gitlab-issue-bash-march-2017/