バグ報告をする前に

概要 †

バグ報告を受ける側の視点から、バグ報告に求めていることを記載する。
良いレポートは開発者の負担を軽くする。
すれ違いを減らし、より円滑にバグを修正していきたい。

そもそも、報告があることに気づかなければ話が始まらない。
開発者はコミュニティの反応を注視してはいるが、全てを拾い上げることは不可能だ。
公式へのバグレポートは開発者の負担を軽減する。
情報を集約する意味もあり、githubのIssueを利用することを推奨する。

同じバグが複数回報告されると、開発者はその度に確認作業をする。
項目数が多く大変だが、既知の問題の一覧を確認してほしい。
あなたが確認して重複を避けることで、開発者のリソースをその分だけ確保できる。

ただし、既知のバグと同種のものか迷った場合は重複を恐れず報告してほしい。
未知のバグを発見することは、確認の手間を省くことよりも優先される。

開発者は自分の手元でバグを再現することを最初の目標にしている。
バグが再現できれば問題の8割は解決したと言っても過言ではない。
報告者にはバグを再現するだけの情報を求めている。

バグが発生した変愚蛮怒のバージョン、種族、職業、性格、現在のダンジョン、現在の階層。
直前の行動、周囲のモンスターなど。可能な限りの情報が必要だ。
情報は多すぎるくらいで丁度良い。不要な情報は開発者の側で読み飛ばせば良いが、記載のない情報を読み解くのは至難だ。

一番良いのは問題発生直前のセーブデータを開発者に渡すことだ。
次に良いのは問題発生直後のセーブデータを開発者に渡すことだ。
致命的だと思われるバグに出会ったら、できればセーブデータを保管してほしい。

○○をすると××になるはずが、△△になった。
このように、動作、期待される挙動、観測された挙動を報告すると良い。
動作の重要性は先に述べた通り。
観測された挙動はバグを修正するための重要なヒントなので、過剰なくらい詳細な情報が求められる。

最も詳細に報告する手段は、開発者にバグを再現させて手元で観測させることだ。
次に詳細に報告する手段は、バグが発生したセーブデータを開発者に渡して手元で確認させることだ。
致命的だと思われるバグに出会ったら、できればセーブデータを保管してほしい。

バグの挙動を理解する、バグを再現する。
この2点が重要であり、これ以外の情報は不要である。
再現できたバグを修正する方法については開発者に任せてほしい。

最も悪いバグ報告は報告されないバグ報告である。
おかしいなと思ったら恐れず報告してほしい。
その上で、もし開発者の負担を軽減してくれるのであれば上記を心掛けてほしい。

変愚蛮怒開発陣にはテストプレイのリソースが不足している。
些細なことから重大な症状まで、あらゆるバグ報告を歓迎します。