結城です。
ノータブルコードに便乗して、実際のOSSのフィードバックを見て「ノータブルフィードバック」と題してお届けする記事の7つ目は、前回フィードバック対象となったMouse Dictionaryに対して筆者が別に行った、連続した一連のフィードバックです。
実際の報告
最初に行ったのは、前回のフィードバックで表示されるようになった初期設定の案内文の内容が、Firefoxでの実際のUIに整合しない状態だったために行ったフィードバックです。
■タイトル 初回使用時の案内がFirefoxでの状況にマッチしていない ■説明 初回使用時に辞書が未設定だと、ページ内に開いたポップアップの中に「初めに辞書データをロードしてください(拡張のアイコンを右クリック→「オプション」)」という案内のメッセージが表示されます。 しかしながら、Firefoxにはこのメニュー項目がありません。実際には、 [[" * アイコンを右クリック→「拡張機能を管理」を選択→「...」をクリック→「オプション」を選択"]] とする必要があります。 初回使用時に戸惑ったため、メッセージを各実行環境向けに変えることが望ましいと思われます。
このイシューに対応するプルリクエストは以下の内容でした。
■タイトル Show initial setup guide for Firefox ≪Firefox用の初期設定案内を表示する≫ ■説明 #32 に対する実装の提案となります。 こんな感じでいかがでしょうか？ ■変更内容 メッセージの定義部にFirefox用のメッセージを追加し、実行環境によってメッセージを切り替えるようにした。
そのレビューの中で「コーディングスタイルをprettier準拠に揃えて欲しい」という指摘を受けたのですが、それをきっかけに作成した別のプルリクエストが、次の物です。
■タイトル Add prettier ≪prettierを追加する≫ ■説明 #33 でコーディングスタイルのご指摘をいただきましたが、コーディングスタイルもlintの一環とすることでコーディングスタイルの揃え忘れを減らせるのではないかと思いました。 いかがでしょうか？ 変更内容: package.jsonの文法チェック用の指定に変更を加え、コーディングスタイルをチェックするようにした。
注目したい点
状況に合わせたフィードバックの仕方
コミットメッセージから自動的に埋められたプルリクエストのタイトルを除いて、英語と日本語の併記ではなく、日本語だけでの報告となっています。これは、
-
プロジェクトオーナーが日本語話者だと分かっている。
-
小規模な問題で、すぐにプルリクエストを出して問題を解消するつもりなので、イシューが長期に渡って残ることをあまり考慮しなくてもよさそう。
という前提があったためです。また、説明文については、「再現手順」「実際の結果」「期待される結果」を見出しを立てて強調するということもなく、自然文の中に入れてサラッと流してしまっています。これも、「初回起動時の一幕」という前提があるため、要点さえ押さえておけば伝わるだろう、という判断に基づいています。
フィードバックの経験が少ない状況では、どの情報を含めてどの情報を省略するべきかということの判断基準が不足していますので、下手をすると「その情報じゃなくて、こっちをむしろ残すべきだった」というような情報を省略してしまいかねません。そのため、「これでできる！ はじめてのOSSフィードバックガイド」では「情報不足よりは情報過多の方がよい」という考えに基づいて、基本的な報告のフォーマットを紹介しています。
そのような取捨選択の感覚は、恐らく、報告をする立場だけだとあまり身に付きません。というのも、フィードバックは 「フィードバックを受ける側（開発者）にとって助けとなる内容」であること が望ましく、「どういう報告なら開発者は嬉しいか」ということは、突き詰めると開発者でなければ分からないからです。筆者の場合は、自分自身が開発者としてフィードバックを受ける機会が重なる中で、「こういう場面では、この情報をもらっても開発者の自分はあまり嬉しくない」という経験を得ており、それが取捨選択の判断基準になっています。
フィードバックの連鎖と、開発者以外の人に役立つフィードバック
また、もう一つ注目して欲しいのは、「プルリクエストに対するレビューを受けたときに気が付いたことを、別のプルリクエストで即座に（カジュアルに）フィードバックしている」という点です。1つフィードバックをすると、それがまた次のフィードバックにつながるということは、非常によくあります。
そうして行った2つ目のプルリクエストは、実はプロジェクトオーナーの方にとっては直接的には必要のない変更です。筆者は特に文法チェックや整形などの開発支援の仕組みを持たないテキストエディタを使っていますが、プロジェクトオーナーの方ご自身は、コーディングスタイルの整形はVSCodeの設定でファイルの保存時に行うようにされているからです。
このようなときには、自分が使っているテキストエディタの設定を変更したり、そのような設定がなければ別のテキストエディタへ乗り換えたりと、自分の手元の環境の範囲で改善を図る方が多いでしょう。しかしここでは、それを 「個人の環境設定の問題」とは捉えず、「プロジェクトオーナーがプルリクエストの内容を一々チェックしないといけないという、プロジェクトの問題」と捉え 、それを解消するプルリクエストを出したのでした。「問題をプロジェクトの問題だと捉えると、フィードバックできる点になる」ということの実例と言えるでしょう。
まとめ
ノータブルフィードバックの7回目として、フィードバックの連鎖の中で行った、「開発者の方にとって直接的には役には立たないけれども意味のある改善」の例をご紹介しました。
このような「身近なところで遭遇したつまずきをOSS開発プロジェクトにフィードバックする」ということをテーマに、まだOSSにフィードバックをしたことがない人の背中を押す解説書 「これでできる！ はじめてのOSSフィードバックガイド ～ #駆け出しエンジニアと繋がりたい と言ってた私が野生のつよいエンジニアとつながるのに必要だったこと～」を、電子書籍としてリリースしました。本記事の内容はこの本からの抜粋となっています。4月5日までオンライン開催されている「技術書典 応援祭」内のマーケットにて紙版＋電子書籍（または電子書籍のみ）を購入頂けますので、ゆっくりオフラインで読みたい方はぜひチェックしてみて下さい。
