WP-CLIのコミッターになってからの4週間でやったことと感じたこと

約4週間前にWP-CLIチームの4人のコミッターの一人として、コミット権限が与えられ、WP-CLIのメンテナンスに深く関わるようになりました。

4週間という節目を機に、自分が取り組んだことや、その中で感じたことをつらつらと書いていきたいと思います。

この記事を読んだ人たちの中から一人か二人でもこちら側の世界に飛び込んで来てくれる人が増えると超うれしいです。

この4週間でやったこと

コミッターになる際に長期間持続可能なペースでやってほしいと言われていたので、今はまだペースを探る感じです。

この4週間だけをみると週平均7時間ぐらい貢献している感じなので、多すぎると言われるでしょう。

ただ、これは今後減るかなとも思っています。もうちょっと要領がよくなるかなと。あと英語でのコミュニケーションにも時間がかかっておりますので。

プルリクエスト

過去4週間でWP-CLIに送ったプルリクエストは14件。マージされなかったものはそのうち2件です。

送ったプルリクエストで最も多いのはテストで、これは他のコミッターが開発している新機能などに対して、マルチバイトのテストを書くというようなことが自然と僕の役割になってる感じです。

コードレビュー

WP-CLI チームのすべてのリポジトリは master ブランチが保護されていて、他のコミッターによるレビューをパスしないとマージできません。

コードレビューは13件行いました。そのときにマルチバイト系のテストがあったほうがいいなと思ったら、そのプルリクエストに対してマルチバイトのテストを追加するプルリクエストを送るというパターンがちらほらあります。

次のバージョンのWP-CLIでは、データベース内を横断的に検索する wp db search というコマンドが追加されますが、やはりこういうのはほっとくとマルチバイトでは期待通りに動かなかったりしますので、マルチバイトユーザーの一人として僕がコミッターにいることはそれだけでちょっと貢献できているかなと思っています。

多くの場合、自分がレビューをしたらその場でマージしているのですが、たまに判断に迷うことがあって、以下のスクリーンショットのように自分の意見だけ書いて他のコミッターに再度レビューをアサインすることもあります。

コミット

この4週間で31コミットしました。コミッターになった当初、プルリクエストをマージすることは少し遠慮があったのですが、線引を確認するという意味で自分の判断でじゃんじゃんマージするように心がけています。

もちろんワークフローやフィロソフィー的な部分にはそれなりに注意が必要で、これは今までにWP-CLIでボツにされた自分のプルリクエストがいいガイドラインになっていると思います。

基本的にはすべてドキュメント化したり自動化することでコミュニケーションコストや参加するための障壁を減らしたいと考えられていて、以下のスクリーンショットのように適時 Issue が作られてワークフローについても議論されたりします。

その他

他にも Issue やプルリクエストにコメントを書くことは多いですし、Slackでやりとりすることもあります。

ミーティングには出ていません。毎週火曜日の深夜2時から行われるのでなかなか参加が難しいですね。

コミッター4人の中では、僕の貢献度合いは圧倒的に少ないです。客観的な件数とか行数とかで見てもだいたい他の人の1/3ぐらいじゃないかと思います。

そういう意味ではあきらかに能力不足がありますので、もうちょっとスピードアップを意識しないとダメなようです。

学んだこととか感じたこと

まとめてやろうとしない

たとえば週末だけまとめて貢献しようとかは難しいみたいです。

毎日Issueをチェックするのが大事で、そのときにやれることがあればささっと手を出す感じです。

まとめてやろうとすると、そもそもできることが少ない上に、流れをつかむための学習コストが必要になります。

理想的なのは1日30分ぐらいかなと思います。現状は1時間近くかかってしまっていますが、これが数年とかになると持続するのが厳しいかなと思います。

毎日届くGitHubからの通知はこんな感じ。追いかけるだけでも大変です。

 

なにがなんでも課題は解決

僕以外の3人のコミッターは課題を解決することに対してはとても貪欲です。

治す!理屈なんか関係ないぜ!って感じ。

たとえば「この問題は○○だから難しいよ」みたいな意見は100%無視されます。

先日、いくつかの国の文字列で、幅は半角だけど文字数としては複数みたいなシチュエーションがあることがわかったんです。

https://ja.wikipedia.org/wiki/%E6%9B%B8%E8%A8%98%E7%B4%A0

これをターミナル上にテーブルで出力するには正確に文字幅を取得し等幅で出力しないといけないわけですが、世界中の言語全てに対応するのは無理じゃないの?と僕は一瞬であきらめたんですよね。

いやー、そしたら翌々日には完璧になんとかなってました。

上のスクリーンショットはタイ語でのテスト結果なんですが、これ mb_strwidth() とかでも誤った結果を返すパターンなんですよね。すごいです。

おかげで Unicode についてかなり勉強になりました。

https://github.com/wp-cli/php-cli-tools/pull/118/files

英語の壁は意外と大丈夫

僕は英語があまり得意ではないのですが、最近では、むしろ日本語での普段のコミュニケーションを基準にすることをあきらめることが大事じゃないかと思っています。

僕が英語のやりとりで意識していることはなるべくイエス・ノーをはっきりさせることと、顔文字をなるべく使うことですね。

ただし親切だったりフレンドリーだったりする必要はあります。これはかなり大事な気がします。実際に僕がそうであるとは思いませんが、そうであるかのように振る舞うことは重要です。

国際化のノウハウ

国際化の実装については、日本でクライアント向けにサイトを作っているだけではとても勝てないほど、ノウハウが蓄積されているように見受けられます。

これに関しては、まったく話についていけないほど僕と他のコミッターの間に知識の差があるようです。やばいです。

貢献者のみなさんは大事

プルリクエストに対しては、99.999%ぐらいは感謝しかありません。

マージされないで閉じられることもたくさんありますが、そういう経験は考え方等を学ぶいい機会になります。

少しでもみなさんがプルリクエストを送りやすいように地味ですがいろいろな努力もしています。

ぜひみなさんからのプルリクエストをお待ちしています。

この4週間での成果

この数週間の間の WP-CLI のマルチバイト関連の改善は胸をはって自慢できます。たとえばテーブルの出力がとてもきれいになりました。

日本語だからということでなんとなく諦めてる事とか、開発者に対して遠慮してることってどうしてもありますよね。

そこにどんどん突撃していけるようになったことは、みなさんにも貢献できているのではないかと思います。

あと、WordPress 本体でもいろいろ問題をみつけました。今後は WordPress 本体にも貢献できる機会が劇的に増えると思います。

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください