エンドユーザーのアプリケーションで発生した問題をリアルタイムで（電子メールで）送信する自動クラッシュレポートシステムを開発しました。すべての詳細（たとえば、どのユーザー、どのクラス/メソッドなど）を取得します。
これは素晴らしいことであり、クラッシュレポートシステムでさえ、ログファイルに書き込むセカンダリクラッシュレポートシステムを備えています（障害が発生した場合）。
プラス面として、クライアント/ユーザーが呼び出すよりも早くバグが通知されます。場合によっては、バグが呼び出される前にバグを解決しました。
私の問題は、この情報をいつクライアントに返すか、そしてどれだけ返すかです。バグが明らかになるのは素晴らしいことですが、同時にそれが問題です。私たちは足で自分自身を撃っていますか？
私たちが彼らに言うならば、私たちは否定的な反応を得るかもしれません、そして私たちが彼らに言わないならば、私たちは否定的な反応を得るかもしれません！
お知らせ下さい！
私はあなたが彼らに言うべきだと思います。悪いニュースの伝達（たとえば、「バグは3か月以内に次のリリースで修正される」）は、まったく伝達しないよりも優れています。
クライアントが気付く前にバグを修正することは非常に良いことです。また、バグをそれほど速く修正できない場合でも、すでに認識していることをクライアントに回答して作業するのは良いことです。
そして、最も重要なことは、 「リリースごとに吸う量が少ない」ソフトウェアを用意することであることを忘れないでください。
アプリケーションに「ステータスメッセージ」タイプの機能がある場合...主要な問題が解決されたときにそれを更新するだけです...または主要な問題が存在することを通知したい場合...
例えば
「請求システムが再起動されています-推定ダウンタイム：15分」
「課金システムが復旧しました-2009年7月17日13:54」
エンドユーザーは、何かが機能していない理由を気にしないことがよくあります。「IT」がそれを認識しているだけで、修正される予定の時間があります。
したがって、「クライアントモジュールのnullポインタ例外が修正されました」はまったく意味がありません...しかし、次のような注意が必要です。
「クライアント検索画面の午前9時30分の問題が修正されました。-9：47am」
アプリケーションが外部の電子メールをそのように送信することをあなたが彼らに知らせてくれることを願っています。なぜなら、存在するその通信メカニズムを知らないことはせいぜい疑わしいからです。
クライアントへの通知に関しては、統計的アプローチを採用できます。これは、サポートコールの前に修正されたバグの数など、あらゆるケースをサポートするために貸し出すことができるためです。しかし、最終的には、オープンなコミュニケーションによるプロアクティブなアプローチは、できるだけ少なく伝えるよりも良い方針など。
次に、プログラミングに関係のない問題、クライアントとの関係、信頼と尊敬の関係の確立、期待の管理などについて説明します。
利他的なことは、彼らにすべてを伝えることです。しかし、正直なところ、それはあなたの仕事をより簡単にし、人々を幸せに保つという点で、常に最善のことであるとは限りません。
私がITに携わっていた頃から、一般的に最善のルールは、情報を求められた場合は情報を提供することでしたが、近い将来（つまり、ダウンタイム）に悪影響を与えない限り、それ以外の方法で情報を提供することはしませんでした。そうすれば、他の方法で気にしない人を動揺させることはなく、すでに動揺している人は、平和の提供として情報を提供することができます。
一般的な経験則では、基本的に目立たないようにし、突く必要のないものやユーザーを突くようなことはしないでください。
バグについて正直に、そしていつどのように修正されたかについて正直に言ってください。
バグについて正直であることは、QAプロセスを改善することによって製品を安定させるためのインセンティブになります。これにより、より安定した製品が得られ、クライアントはあなたの製品をより安定していると考えます。
バグがいつどのように修正されたかについて正直に言うと、クライアントサービスと応答性に関するイメージが向上します。
私の会社がそれを処理した方法は、ストアドプロシージャ、検証などのエラーコードで発生したすべてのエラーに対して発生したことです。これらは、PKを介してデータベース内のテーブルにマップされました。次に、ユーザーフレンドリーバージョンと技術面の2つのテキストフィールドがありました。
同様のことを行うか、例外処理でよりわかりやすいメッセージをラップしてデータベースに記録し、参照する必要がある場合はユーザーに参照コードを提供することができます。
結局、何も起こらなかっただけでなく、今はうまくやっていると思います。
通常の解決策は、ユーザーに決定させることです。メールを自動的に送信する代わりに、「クラッシュして申し訳ありません。問題に関するすべての情報を収集しました。問題を修正できるように、今すぐ開発者に送信できます。送信しますか？はい/いいえ」
また、送信されているデータを目立つように表示して、ユーザーが知識に基づいて自分が何をすべきかを推測できるようにします。
[編集]ほとんどのユーザーは、アプリケーションが通知せずに自宅に電話をかけていることに気付いた場合、特にユーザーが外に出たくないと思われる大量のデータを送信した場合、非常に不満になることに注意してください。
エラーメッセージに個人データが含まれている場合は、コンピュータ詐欺で訴えられる可能性があります。