エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント3件
- 注目コメント
- 新着コメント
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
プログラマに伝えるためのIssue(バグレポート)の書き方【GitHub編】
GitHubでアプリケーションを公開してから、Todoの代わりとしてIssueを書きたくなった。 ということで、... GitHubでアプリケーションを公開してから、Todoの代わりとしてIssueを書きたくなった。 ということで、プログラマに伝えるためのIssue(バグレポート)の書き方をまとめてみた。 ついでに、前職の炎上プロジェクトで多くのバグ報告を書いて、対応してきたので、そのときの経験も踏まえて書いておく。 Title タイトルを書くときのポイントは次のとおり。 簡潔であること バグの内容が把握できること 設計要素の名称を書くこと 発生した状況がわかること タイトルの先頭に【優先度】や【機能名】のように、隅付き括弧で目印を書くことが多い。 Comment 「Leave a comment」には、バグの詳細情報を書く。 問題の内容(現象) 複数のバグをひとつのIssueにまとめないこと どのようなバグが発生したのが、できるだけ具体的に書くこと エラーのスクリーンショットやログを添付すること 「バグ」
2015/08/11 リンク