はじめに
世界は、ひとつずつ変えることができる。1 nikkieです。
先日、VSCode拡張のハンズオンテキストに取り組みました2。
その中でテキストに見つけたtypoを修正するプルリクエストを出しています！
こういったtypo修正プルリクエスト、実はブラウザだけで完結させられちゃうんです！
今回はGitHubにブラウザだけでプルリクエストを作る秘密を明かしちゃいます。
目次
nikkieとtypo修正
ドキュメントを読んでいるとtypo（誤植）に気づくことってありますよね？
そんなとき私はなるべくプルリクエストまで作るようにしています。
Webに公開されているページは今後も見る人がいるでしょうし、その人も「あれ？」と思うでしょう。
できないときもあるのですが、「気づいた以上はなるべく直したい！」と時間を捻出してプルリクエストを作ります。
最初はgitリポジトリをローカル開発環境にcloneしてやっていました。
この手順でtypoを修正する目的は果たせるのですが、何回かやってみて「ローカル開発環境を経由するのが手間だな」と感じ始めました。
1日の時間は24時間と有限ですから、なるべく短時間でtypo修正プルリクエストを作りたいのです。
そこで、ローカルにcloneせずにブラウザだけで完結させる方法を探し始めたのです。
ブラウザ操作でラクラクtypo修正プルリクエスト！
以下の手順でブラウザだけでできます：
ローカルにcloneせずにこれだけでできます！！
2は言葉で伝えるのが難しそうなのでスクリーンショットもお見せします。
鉛筆マークからブラウザ上でファイルを編集できます。
このエディタは検索もできます。
typoを修正したら、ブラウザを一番下までスクロール！
コミットが作れます。
操作は
- Create a new branch for this commit and start a pull request（新しいブランチを作ってプルリクエストを始める）を選択
- ブランチ名を入力
- 「Propose changes」（変更を提案）をクリック
です。
これでforkしたリポジトリのブランチにtypo修正コミットができました！
このあとは、自分が持っているforkしたリポジトリに対してプルリクエストが作れる画面に遷移するのですが、これはやりたいことではないのでそっ閉じします。
今回やりたいことはfork元のリポジトリへのプルリクエスト作成です。
手順3にあるように、fork元のリポジトリ（のトップ）を開きましょう！
そうすると「あなたが持っているforkしたリポジトリのこれこれブランチからプルリクエストが作れるよ」と通知が出ます。
この通知に従ってプルリクエストを作ります。
以上、ローカルを介す方法よりも簡単になったと感じています！
補足情報
typo修正時のtips
(1)OSSへのプルリクエスト作成手順としては聞くことが多いのですが、すでに同じプルリクエストが出ているかさっと検索しましょう。
typoの内容で検索して判断しています。
(2)意見が分かれるかもしれませんが、私の場合はtypoを見つけたIssueを作ります。
リポジトリ内を検索し、「こういったtypoがこことここにあるよ」とtypoと対応箇所を列挙します。
いきなりプルリクエストを作るよりはまずIssueまで作ります。
こういったIssueはGood firstなので他の方にやっていただいても、作者も私もとてもありがたいと考えています（「なんとしても私がこのtypoを直すんだ！」という気持ちはnikkieにはありません）。
自分のタスクを調整して時間を作り、上で紹介した手順でブラウザを操作していくわけですが、直すところが列挙されているので高速な操作に集中できます。
typo修正よりもう少し込み入った変更はできないの？
github.devでできるかもしれません。
変更箇所が多かったときはURLをgithub.devに書き換えて遷移し、VSCode風UIで複数ファイルに渡った置換をし、その後コミットを作りました。
GitHubの方針としてブラウザだけで開発が完結する世界を目指している3ように見えるので、もっと可能性はあると思います（ブラウザだけでこんなプルリクエスト送ったよ！という事例ができたら教えてください！）
作業を始めたら別のtypoにも気づいたとき
これも好みですが、プルリクエスト1つ1つは小さい方が望ましいと考えているので、私の考えとしては一度に対処せずに分けて対処します。
また、過去に徹底的にやったほうがいいなと判断したときは、ローカルにcloneしてVSCodeのCode Spell Checker拡張で一網打尽にしました。
書いていて浮かんだのですが、github.devでCode Spell Checker拡張をインストールしてもよいかもしれません（今度試してみよう）。
コンテンツを生み出す方と読者の役割分担
技術同人誌を書くにあたっての心構えとして印象に残っている言葉があります。
コンテンツを生み出そうとしているとき、typoを恐れずとにかく1文字でも書き進めるという教えです4。
私も経験があるのですが、締切は待ってくれませんし、書き切らなければそのコンテンツは世に出ません。
なので、typoはない方がいいですが、それはnice to haveで、書き手はmustな「書き切る」に全集中になるのだと思います。
人間はすごいので多少のtypoがあっても読み切れます。
OSSで公開されているチュートリアルのようなコンテンツの場合、読み手は書き切った書き手に感謝し、気づいたtypoがあれば直すプルリクエストを送るというのが、いまの私が考える役割分担の形です。
ゼロからコンテンツを生み出してくださり、とにかくありがとうございます！
そして気づいた点があったときは、一緒によりよくしていく手伝いをちょっとだけでもさせてください！
終わりに
typoに気づいたらプルリクエストを送るを重ねる中で生み出した「全部ブラウザで完結させる方法」を紹介しました。
本記事を読んで「私も見つけたtypoの修正プルリクエスト出しました！」という方がいらっしゃれば、それ以上に嬉しいことはありません。
小さな点でも立派な改善だと思うのです。
公開いただいているコンテンツに小さなプルリクエストという形でも感謝を伝えてみてはいかがでしょうか。
P.S. ボーイスカウトルール
Uncle Bobが『プログラマが知るべき97のこと』に寄稿しています。
たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。
今回取り上げたケース、当然自分がtypoしたわけではないですが、気づいた以上はきれいにするというのが、ボーイスカウトルールに通ずるなと思い出しました。
なお、コードの品質をよくしていくためのボーイスカウトルールの適用は、Uncle Bobの新刊『Clean Craftsmanship』を読むとTDDと切り離せないように今は感じ始めています。
テストハーネスがあれば、コードの品質をよくしようという際に自信を持って進められますもんね。
