Help us understand the problem. What is going on with this article?

初めてのPull Requestを送りたいあなたへ

More than 5 years have passed since last update.

OSS活動をしてみたい、Pull Requestを送ってみたい・・・!

だけどそんな気になるリポジトリもないし(あってもRubyやRailsみたいに敷居が高い)、コントリビューターになれるほどの技術力もそこまで・・・と、そんな状態の人は結構多いんじゃないかと思います。

私自身もそうで今も大して変わりませんが、Pull Requestは送ることがあるという状態になってきたので、こうすればいいんじゃないかということをまとめてみたいと思います。

1.Webサービスやアプリを自分で作ってみる

仕事でも趣味でも構いません。まずはWebサービスなりモバイルのアプリなり作ってみるのがいいと思います。
今時は開発していてOSSを一切使わないなんてことはほぼないと思うので、これでまず「身近なOSS」を増やしていきます。

そもそも何をつくったらいいのかわからん、それほど作りたいものもない、ということもあると思います。
そういう時は、以下の方法がお勧めです。

  • 他の人に聞く
    「どんなアプリがあったら便利かな?」みたいな話をすると結構みんないろいろ言ってくれます。自分に作りたいものが特になければ、誰かにとって便利なものを作ってみるのがいいと思います(私はこれで作りました)。

  • 日頃使っているサービスのAPIを使ってみる
    GitHubやQiitaはAPIを提供してくれています。自分が普段使っているアプリの情報を抽出して何かできないか考えてみるとアイデアが出てくるかもしれません。

  • コンテストのサイトを見る
    CookpadのコンテストMash up Awardのサイトを見てみると、テーマや応募作品などが見られます。これをヒントにすると作りやすいんじゃないかと思います。
    特にMasu up AwardはAPIの一覧があるので、これは結構ヒントになります。

くだらないことでもいいので、思いついたらとにかくメモっておいた方がいいです。いざ作ろうと思って机の前に向かうとアイデアがなかなか出てきません。

2.issueを作る・見る

OSSを使っていると、バグを発見したり「ここ、こうできないのかな?」みたいなことが出てきます。

普通にみんな使っているOSSなのでバグを発見することは稀ですが、JavaScript系のライブラリはIEで動かすと結構バグが出てきてそれがとっかかりになりやすいです(幸か不幸か・・・)。私が初めてissue、Pull Requestを出したのも使っているライブラリのIE6のバグでした。jQueryのプラグインなどはコード量もそれほど多くないものが多く、とっつきやすいと思います。
自分で作る場合は理想的な環境で作ると思うので、バグについては仕事での方が発見する機会が多いかもしれません。

それでGitHubなどのリポジトリのissueを見てみると、自分と同じ現象で悩んでいたりあるいは「これなら自分でも解決できそうだな」というissueがあったりします。あんまり大きいリポジトリよりは、小~中のプラグイン的なポジションのものの方が見つけやすいと思います。

発見したバグのissueをあげる、もしくは解決できそうなissueを見つけたら、Pull Requestはもう目の前です。
※issueをあげる際は、ルールがある場合があるのでそこのところはきちんと確認。例えば、私がお世話になっているSlickGridというライブラリでは、issueはバグ報告のみに限定されています。

3.Pull Requestを送る

ここから先の手順はいろいろなところにまとめられているので(こちらなど)、そこを参考にすればよいと思います。
基本的には、以下原則を外していなければそう身構えなくてもよいと思います。

  • masterで作業しない
    issueがすでにあるので、issue10みたいなissue番号がわかるブランチで作業すればよいと思います。他の人のPull Requestを見て参考にすると良い。
  • ルールを確認する
    Pull Requestを送る際はこうしてくれ、というルールがままあります(例:jQueryの場合)。それをきっちり確認しましょう。
  • 送る前に差分を確認する
    特に注意すべきなのが、エンコードやインデントです。タブと空白の違いで差分が異常に出ていたりしたらNGですし、forやifのインデント、細かいですがa=bなのかa = bなのか、みたいなものも他ときちんと合わせておくことが重要です。 また、差分はPull Requestを送る直前の状態と比較してとらないと意味がありません。upstreamでmasterをきっちり最新に合わせておきましょう。

issueからのPull Requestだと、#10の修正です、みたいな感じで送る際の文面も書きやすいです。
英語も含めた最後のチェックをして、Pull Requestを送ったらそれがOSS活動の第一歩です!

しばらくコメントがついてないか何回も確認したりしてドキドキしますが、マージされることを祈り気長に待ちましょう。リポジトリによると思いますが、当然OSS活動が本業という人は少ないので、すぐにリアクションがあることは稀です。

また、Pull Requestを送らないまでも情報が足りていないと思えばWikiに追記したり記事を書いたり、バグのissueで「私の環境ではxxだった」と情報を追加するなど、できることは色々とあります。

もしこの記事を読んでPull Requestを初めて送った方がいたら、これほどうれしいことはないです。
よきOSSライフを!

icoxfog417
All my statements are from fun fancies, not a boring story that represents a company that I belonging to.
https://github.com/icoxfog417
tis
創業40年超のSIerです。
https://www.tis.co.jp/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした