なぜパッチノートのバグIDを引用するのは悪い習慣と見なされるのでしょうか?


28

Bug reopen vs newからのコメントとそれに続く賛成票に基づいて:

パッチノートでバグIDを引用するのは、とても友好的ではありません。–クレルプ

少なくとも一部の人々は、パッチノートでバグIDを参照するのは良い考えではないと感じているようです。私はかなり経験の浅い開発者なので、なぜそうなのか疑問に思っています。


27
パッチノートでバグIDを引用しないのは、ただ...非常に専門的ではありません。ゴミの種類持つことの全体のポイント課題追跡を
ブヨ

StackExchangeが答えとしてのみ掲載することは眉をひそめているリンクと同じ理由-あなたがいる場合にのみ場合に(1)を説明し、(2)を取得するには、次の必要があるために悪いですSE上のリンクを投稿するには、将来的に無効になる場合がありリンクが切れるか、内容が変更されます。同様に、パッチノートにバグID のみを入れるには、(1)バグトラッカーにアクセスして説明を取得する必要があり、(2)バグトラッカーシステムが変更された場合、将来無効になる可能性があります。SEの回答にリンクを含めるか、パッチノートにバグIDを含めることは、通常の説明に追加することで問題ありません(実際には良い方法です)。
ベン・リー

回答:


51

私の意見では、ユーザーがバグデータベースへの読み取りアクセス権を持っていると仮定すると、それは良い習慣です。アップグレードするタイミングを決定するために、特定のバグが修正されるのを人々が待っていることがよくあります。

眉をひそめているのは、バグID だけを引用していることだと思います。また、バグトラッカーにアクセスしなくても理解できる説明を常に提供する必要があります。また、以前のリリースノートを完全に無効にすることなく、将来バグトラッカーを切り替えることができます。


抽象参照リゾルバー、別名URLリダイレクトを使用して引用できます。
ドナルフェローズ

あなたが言うように、「修正されたバグ」(または同様の)セクションにはIDとタイトルを含める必要があります。これにより、読者はバグを調べて含まれるものと含まれないものを正確に理解する必要がなくなります。
StuperUser

5
@StuperUser -イドやタイトル、で最小
Oded

面倒なのは、参照されたバグ/要件IDシステムが使用されなくなったときに、コメント内のバグIDのみの表記を見つけることです。
jfrankcarr

14

それは、引用されたコメントで述べたように...友好的ではありません。

自分に不親切

次のシナリオを想像してください。ソース管理でログを表示しています。あなたはコミットが何を変えたのかと思っています。わかりやすい英語で説明する代わりに、次のように伝えます。

解決した#1307

バグ追跡システムを実行し、何か役に立つものを望んでいます。バグ#1307は解決済みとして報告されています。説明には以下が表示されます。

#1284と同じバグ

ありがとう、とても助かります。ここで、バグレポート#1284に移動して、バグ#1112、#1065、および#1067を参照するバグ#1113の複製であることを確認する必要があります。

5分後、最初に何を探しているのかわかりません。

はるかに役立つバージョン管理ログメッセージは次のようになります。

Webサイト自体で使用されているものと同じパスワード長ポリシーをデータアクセスレイヤーに適用することを削除することにより、ユーザーが25文字を超えるパスワードでログオンできない問題を解決しました(#1307を参照)。

同様に、バグ追跡システムでは、レポート#1307がより自明で、バグレポート#1284が何であったか、新しいレポートが古いレポートとどのように異なるかを思い出すことができます。

顧客に不親切

これが唯一の親しみやすさの問題ではありません。

2つ目は、追加情報なしで参照しすぎることにより、パッチノート/バージョン管理ログ/バグ追跡システムレポートを、それらのシステムにあまり詳しくない人には使用できないようにすることです。バグ追跡システムを毎日扱うとき、レポートをすばやくナビゲートしたり、複数のレポートを並べて表示したりする方法を知っています。技術的なバックグラウンドのない顧客であれば、簡単に迷子になります。

ここでも、単なる参照よりも詳細なメッセージが非常に役立ちます。まだ参照を保持する必要があることに注意してください。2週間前に遭遇したバグと同じですが、そのIDを思い出さないでください。


注として、同じ問題が多くの管轄区域に存在します。たとえば、フランスでは、法律が複数の情報源を参照することは珍しくありませんが、その間に変更される可能性があります。これは、それを完全に理解するために、ライブラリで数時間を費やし、各テキストが他のテキストを参照している多数の参照テキストを検索する必要があることを意味します。


5
これはリリースドキュメントの問題ではありません。これはバグの詳細レベルの問題です。タイトルには実際の問題を説明し、各バグの本文には「期待される結果」と「実際の結果」があります。あなたが説明したようなバグは重複として閉じられるべきではありませんか?
StuperUser

編集に基づきます。あなたははるかに役立つメッセージでIDを引用しました。元のコメントで、適切な説明とIDが役立つのに対して、追加情報のないIDのみを引用するのは役に立たないということですか?
-StuperUser

1
@StuperUser:正確に。説明を提供することは、参照されたコンテンツを10分間読むことなく、コミットログ/パッチノート/バグレポートの内容を知りたいだけの人に役立ちます。追跡と、非常に詳細で正確かつ完全な情報が必要な人には、IDが引き続き必要です。
アルセニムルゼンコ

2

ユーザーが引用されている問題を読むことができれば、パッチノートで問題番号を引用することに何の問題もありません。バグデータベースで誰でも読むことができる場合、バグ番号を引用することは非常に便利です。(より良いのは、パッチノートがリンクを許可する形式である場合、それらの問題IDを問題の問題へのリンクにすることです。)これは、すべての問題を一般に公開する必要があることを意味しません。シュラウド化されたパスワード(たとえば、ライブパスワードが入っている場所)があると便利です。

読んでいる人がバグの詳細や履歴を調べることができない問題番号を引用すると、それは非常に不親切です。問題IDなしでそのような問題を引用する方がずっと使いやすいというわけではありません。


「人の読みが行くと細部まで見ることができないところ」などとなっているものとして人を、私はこれは本当に無愛想を呼び出すことはありません。私は問題IDを使用して、サポート/開発チームとやり取りし、チームは問題トラッカーにアクセスしました。それは個人的に私には見えなかったという事実は、単にマイナーな不快感だった
ブヨ

2

パッチノートを読む人が誰であるか、ソフトウェアのターゲットユーザーに依存することは明らかです。

しかし、ほとんどの場合、大部分のユーザーはバグIDが何であるかを気にしません。彼らはそれが壊れた理由、修正内容などを気にしません-彼らは変更ごとに別のページに移動することなく、非常に簡潔なテキストの説明で何が変わったかを知りたいだけです。

バグIDを引用することで私は立ち止まって考えるようになり、ユーザーとしては考えたくありません。それは一種のユーザビリティの問題です。

で、例えば見てくださいのVisualアシストXの変更ログを。リンクされたバグIDはすべてノイズであり、変更された内容を理解するのを妨げます。そして、これはプログラマを対象としたVisual Studioのアドオンです。そして私はプログラマーです。これが気になる場合は、バグトラッカーが何であるかさえ知らない平均的なユーザーを想像してください。

PS:私は質問のきっかけとなったコメントの著者でした


1
正直なところ、私はそのリンクの最後にあるドキュメントが役立つと思います。概要から始めて、詳細を説明します。マイクロソフトはKB記事で同様のリンクを行うことがよくありますが、それを行うことで良いプラクティスになるわけではありませんが、確かに普及しており、明らかに多くのユーザーに価値を提供します。
ジョシュアドレイク

1

バグIDは参照ポイントに必須です。その理由:

  • あいまいさを防ぐ: 2つ以上のバグに同様の説明がある場合があります。したがって、それらを区別するためにアンカーが必要になります。
  • 利便性:顧客とまたは内部でバグを議論するとき、バグIDはしばしば短い形式として使用されます。IDがパッチノートから省略される場合、それらについて議論することは困難です。

3052はすでに修正されており、3077に取り組んでいます

より便利です:

「適用ボタンでのアプリケーションのクラッシュ」は修正されましたが、「ユーザーの変更でのNullReferenceException」で引き続き動作していました。


(1)MainMaが示唆するように、何がそれを結合できないのですか?(2)なぜ1.5個のバグを修正するのですか?3052が修正された後、3077で作業を始める前にコミットしてみませんか?
JensG

0

私はそれはあなたのシステムに依存すると言うでしょう:私は幸運にも私が使用 するものがコミットメッセージでそのような参照を検出し、バグトラッカーに保存されたチケットへのリンクを追加するので、それは問題ではありません。

しかし、私はそれが利用できないシステムにいた場合、バグが何であるかの簡単な説明と一緒にチケットID(チケットIDによってログですばやく検索できるように)に言及します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.