バグ報告する方法 » 履歴 » リビジョン 3
リビジョン 2 (toshi_a 初音, 2018-02-25 17:51) → リビジョン 3/5 (toshi_a 初音, 2018-03-02 18:03)
{{>toc}} h1. バグ報告する方法 h2. はじめに mikutterのバグを見つけた時に、バグを報告する方法です。 このバグトラックシステムは、コミッタにバグ修正を依頼するものではありません。どのようなバグがmikutterに存在しているのかを、みんなで情報共有する場所です。当然報告したバグは修正されることも多いですが、開発者以外の人が修正してくれたり、場合によっては誰も興味を持ってくれない可能性があることは頭に入れておいてください。 h2. 既にあるチケットを探す あなたが発見したバグはもうあるかもしれません。バグはみんなこのRedmineに報告されるようになっているので、まずは既存のチケットを探しましょう。 !c4b337af-3124-4c90-b2ba-2247a37dae62.png! このページの左上に、「検索」と書かれたテキストエリアがあるので、そこに検索キーワードを入れてエンターキーを押すと、そのキーワードが入ったチケットやコミットといったものが検索できます。 *複数キーワードを指定する時は、半角スペースで区切ってください* 。全角スペースだと一つの単語だと思われてしまってヒットしません。 h3. 見つかった場合 あなたが報告しようとしていたバグが既にチケットになっていたら、何もする必要はありません。 あなたも同じ問題を踏んでしまったという旨をそのチケットに書くと良いでしょう。とくに、議論がしばらく止まっているような場合、この問題で現在も困っている人間が居るということを表明しておくと、対応される可能性が上がります。 もちろん、あなたが修正できそうな問題であれば、そのチケットに対してあなたがパッチを送ってくれると嬉しいです。 h3. 見つからなかった場合 未知の問題であれば、次の手順に進んでチケットを登録しましょう。 もちろん、あなたが見つけられなかっただけで既にあるかもしれませんが、その場合は他の貢献者が重複チケットとして整理してくれるので、ミスを恐れずとりあえずやってみましょう。 h2. チケット作成画面 画面左上の「＋」のマークにマウスをポイントすると、「新しいチケット」というメニューが出てくるので、クリックします。 !DeepinScreenshot_select-area_20180302172801.png! !0cd379c9-f5a0-4f9f-a271-617c016f881b.png! 「新しいチケット」という画面に移動するので、各項目を埋めて、「送信」を押すと報告完了です。 「新しいチケット」という画面に移動するので、「トラッカー」「題名」「対象バージョン」「説明」「再現手順」を埋めて、「送信」を押すと報告完了です。 これらの項目に埋める内容も、不備や間違いがあればこちらで訂正したり追加質問をするので、気軽にやってください。 h2. トラッカー 「バグ」を選んでください。 「バグ」を選びます。 h2. 題名 報告する不具合がどういったものかを1行で説明します。 h3. 対象バージョン バグを発見したmikutterのバージョンを選んでください。 複数のバージョンで再現することを確認できている場合は、選べる中で一番 *低い* バージョンを選んでください。 h3. 説明 この不具合がどういったものかを具体的に説明する場所です。 h3. 再現手順 バグは、修正する人が手元で同じ状況を発生させることができないと、修正できません。どのような手順で操作するとバグが再現できるかを箇条書きで書いてください。 バグは、修正する人が手元で同じ状況を発生させることができないと、修正できません。 h3. プラグイン名 バックトレース クラッシュするプラグインが何なのか分かっている場合は書いてください。 トラッカーで *致命的* を選んだときだけ出現する項目です。 基本的に、コミッタが作業を振り分けるために使うフィールドなので空欄でもいいです。 下の方法を順番に試して、最初に得られたものを貼ってください。 h3. クラッシュする # STDERRに出力されたRubyバックトレースを貼ってください。セグメンテーションフォールトなどでランタイムがクラッシュした場合は、その寸前にRubyレベルのバックトレースが出力されていることがあります。 # mikutterを再起動して、バグ報告の送信ダイアログが表示される場合、書いてある内容を全てコピペしてください。 # mikutterを再起動して、バグ報告の送信ダイアログが表示される場合、バグ報告を送信して、その時の時刻を書いてください（例: 2018年2月1日18時35分ごろに送りました、等） # 上記いずれの方法もできなかった又は分からなかった場合は、その旨を書いてください。 このバグによってクラッシュすることがあるならチェックを付けてください。 ある操作をすると数回に一回クラッシュすることがあるといった場合でも、チェックをつけてください。 表示が崩れている、項目が選べないといった問題の場合はチェックを付けないでください。 h3. 添付ファイル クラッシュした時の出力や、修正パッチなど、バグの解決や状況の把握に役立つファイルがあれば添付してください。 h2. 送信ボタンを押した後 チケットを登録した後は、そのバグに興味を持った人が追加の情報を書き込んでくれたりして、そのバグの情報が集まってきます。 運よく開発者に興味を持ってもらえたら、修正してもらえることも珍しくありません。 h3. ステータス !mikutter-redmine-bug.png! ステータスというのはチケットの状態です。バグ修正の経過に合わせて更新していくので、今どのような状態なのかがひと目でわかります。灰色の部分はコミッタが担当するので報告者は気にする必要はないですが、こちらから質問する可能性もあるので、その場合は返答してください（後述）。 *分類待ち* というのは、チケットを作った直後の状態で、まだ受理されていません。この状態の間に、どのような対応を取るのか議論して、上図のいずれかの状態に遷移します。 *レビュー待ち* というのは、パッチを適用した結果や、開発者が行った実装を報告者に見てもらうフェーズです。実装者が報告の意図を取り違えて全然違う問題を修正したり、別のバグが入ったりすることもあるので、報告してくれた人に確認してもらうようにしています。 *マージ待ち* は、報告者が修正後の内容を確認した結果問題ない場合、報告者がこのステータスにします。 *まだダメ* は、バグが直ってないなど、さらなる修正が必要な場合に、報告者がこのステータスにします。当然このステータスにすると同時に、何がいけないのかを注記に書いてください。このタイミングであなたが修正方法を分かっている場合は、パッチを添付しても良いです。その場合も *まだダメ* にしてください。 h3. 議論が進んであなたが返信しなければいけない場合 バグ報告として情報が足りない場合は、チケットの注記機能（返信機能みたいなもの）で、更に具体的な情報を聞かれる可能性もあります。その場合は、下の写真にあるような「編集」というリンクをクリックしてください。 !117d10b5-be05-4776-8b57-461428875b4b.png! これをクリックすると↓のような画面になるので、「注記」のところにメッセージを書けば、返信できます。 !d162a396-7ac3-4740-874b-f301dcfe8478.png! この時に、コメントで「ステータスを変更しておいてください」などと追加のお願いをする場合があるので、この画面で注記を書く時にどうじにやることもできます。 この時に、コメントで「ステータスを変更しておいてください」「担当者を○○にしてください」などと追加のお願いをする場合があるので、この画面で注記を書く時にどうじにやることもできます。 解決までの流れはチケットによって様々で、随時案内していくことになるためここにはこれ以上書きませんが、大まかな流れはだいたいつかめたと思います。よく分からなければMastodonで "@toshi_a@social.mikutter.hachune.net":https://social.mikutter.hachune.net/@toshi_a に聞いてくれれば案内します。 h2. 解決されやすいバグ報告の仕方 冒頭で、ここはバグ修正をお願いする場所ではないと書きましたが、まあバグ情報を共有したら修正されてほしいですよね。 同じバグ報告でも、見る側も人間なので、書き方一つで修正される確率をあげることができます。わざわざこの文書を読んでくれたあなたには、開発者側の視点でこっそり教えてあげましょう。 h3. 修正パッチを添付する あなた自身がmikutterのコードを修正して、バグを直してしまって、パッチを当ててくれさえすればバグが直る、という状態にするのは、どの方法よりも有効です。 バグ修正は大変ですから、開発者からすると、修正してくれたのにおまたせするわけにはいかない！と思ってしまうものです。当然いそがしいときなんかは対応は遅れますが、時間が出来た時に真っ先に見るのは、修正パッチが提供されているチケットです。 h3. 正確に情報を入力する 「正しく情報が書かれていなくても良いのでお気軽に」とは書きましたが、情報が欠落しているとやりとりに時間がかかるので、しんどい時にはちょっと、また今度にして別のチケットからやろうかなとか思ってしまうことも正直あります。 貢献者の中には、特定の機能にだけ詳しい人もいます。バグ情報を詳しく書いておけば、そういう人たちが自分のカバーしてる範囲の問題だということに気づいてくれるかもしれません。もちろん、詳しく書くことによって「俺には興味がない機能だ」と思う貢献者もいるでしょうけど、何も説明がなければ、誰も見てくれないでしょう。