フィードバック

DBFluteに対するフィードバックに関する手順や連絡先などについて。

フィードバックとは?

DBFluteを利用していて、"あれ、これ明らかにおかしいんじゃないか?(バグ報告)" とか "もっと、こうしたほうがいいんじゃないかな(要望)" など、DBFluteに対する現象・改善等の報告を意味します。

また、広い意味で言えば単なる質問も、"そのことがドキュメントに書かれてない証拠" であり、"わかりにくい仕様になってしまっている" と言えるため、フィードバックと言えます。また、質問が来ることで "ユーザがDBFluteをどのように捉えているのか" そして、"どういう使い方をしているのか" という面もわかり、DBFluteのコミッタもさることながら、他のユーザにも利益になります。 (というわけで、DBFluteでは "質問" もフィードバックと表現することがあります)

DBFluteでは、フィードバックを歓迎しています。 全てに対してフィードバックされた方に最高の結果を出せるとは限りませんが(申し訳ありません)、 そのときの最善を尽くして対応させて頂きます。

フィードバックのポイント

フィードバック内容として、以下のポイントを一緒に添えて頂けると助かります。

テーマ
一行で要約する、そのフィードバックのタイトル。例えば、"MySQLのReplaceSchemaのデータ登録で例外発生" や "共通カラムの自動設定の中で区分値機能を利用する方法の質問" というようなものです。悪い例は "質問です"、"困ってます"、"教えて下さい" というように、そのテーマから何も想像ができないようなものです。
利用環境
DBFluteのバージョンや利用しているDBMSの種類とバージョン、また、そのテーマで関連する周辺のツールに関する情報。 特に、予期せぬ現象に対する報告の場合は、できるだけ多くの情報を頂けると助かります。
現象の説明
(現象報告を含むのであれば)その現象の詳細な状況の説明。どういう状態で、何をしたら、何が起きたのか? コード例やテーブル構造、例外メッセージ・スタックトレース、そのときのデバッグログなどを織り交ぜた説明があると、 状況確認のやり取りを省略することができるため、早い対応が見込めます。但し、業務情報に関しては必ず伏せる ようお願いします。また、DBFluteでは、特に再現手順、再現環境が明確になっていると助かります。例えば、dbflute-basic-example で、こう修正してこう実装すると再現する、というように皆が共通のリソースとして扱うことのできる DBFlute Example を利用して再現ができると誰もが気軽に検証することができます。
考察の提示
現象の説明から原因についてどういったことを考えられるのか、ユーザからの視点で提示して頂けると助かります。 それは正解である必要は全くありません。特に再現が難しい現象に関しては、ユーザ視点の考察があることで、 "(特にリモートで)対応する方としてはどうしても得ることのできない視点" が共有できるからです。原因追求というのは、仮説検証の繰り返し とも言えます。少なくとも、例外メッセージに対する考察があると議論が進みやすくなるでしょう。
また、何かわからないことがあるのであれば、具体的に何がわからないのか を提示すると良いでしょう。("わからないこと" が明確になってないと、回答者はコメントしづらいものです)

背景の提示 (本当の問題領域は?)

そのフィードバックに至った背景をできるだけ明示することが早い解決につながります。

例えば、もともと A という問題があって、それを回避するために B の方法をやろうとして C の問題が出て、その C を回避するために D の方法をやろうとして...という場合、端的に言うと "既に道を踏み外してる" 可能性があります。そのような状況で、"S をやろうとして T という問題が..." という唐突に浮世離れした問題領域の話が挙がってきても、前向きな答えがでない可能性が高いです。実は A を解決する B+ という最良な別の方法があるかもしれません(本当の問題領域は A だったと)。

また、手段が主眼になっている場合も同じく、その手段を話題にした背景、つまり、その手段が達成する目的を明示すると良いでしょう。 例えば、よくある典型的な例が "ConditionBean で group by はできるか?" という質問です。これにストレートに答えると答えは NO です。ですが、子テーブルの導出カラムを取得したい、 そのためにインラインビューで group by を使って集計ビューと結合して...という話であれば、そもそも group by を使わなくても ConditionBean の select 句で相関サブクエリを行う (Specify)DerivedReferrer で事足りるかもしれません。"group by" (道具) の話だけに捕われていると、本質的な問題解決になかなか達しない可能性があります。

そして、その問題領域に至るまでのロジックを再整理すること自体が大事です。 相手に伝えるための再整理の段階で、自分であるべき解決に気付く可能性もあるからです。 フィードバックはDBFluteにとってはうれしいものですが、(ユーザからすれば)ないのにこしたことはないでしょう。

フィードバックの宛先

seasar-user

DBFluteは、Seasarプロジェクトのプロダクトとして開発されています。 よって、Seasarプロジェクトが提供するメーリングリスト seasar-user にてフィードバックを受け付けています。 DBFluteの修正を伴わないものであれば、ユーザ同士で対応して構いません。ユーザ同士の情報交換の場として利用できます。

メーリングリストを利用するには入会の手続きが必要です。

DBFlute.NET(C#版)の場合は、seasar-dotnet となります。

DBFluteユーザの集い

Google Group として "DBFluteユーザの集い" というものがあります。これでもフィードバックを受け付けています。seasar-user は、他のプロダクトでも利用されるメーリングリストですが(大勢の人が見ます)、こちらは "DBFluteのユーザ" というテーマに絞られていますので "気軽に質問したい"、"相当マニアックな質問をしたい"、"困ってないんだけど興味本位で質問したい" というような場合は、こちらが向いています。 DBFluteの修正を伴わないものであれば、ユーザ同士で対応して構いません。ユーザ同士の情報交換の場として利用できます。 (返事を求めない)ただのみんなに知らせたいだけ、というような通知のような投稿も受け付けています。

DBFluteユーザの集いで投稿するには入会する必要があります。

ブログコメント

コミッタ(作者)のブログ("はてな" など)のコメントでもフィードバックを受け付けています。 但し、非常に議論はしづらい環境ですので、"seasar-user" や "DBFluteユーザの集い" がどうしても利用できないというような場合(例えば、匿名でないとつらいような場合)に利用します。 もちろん、フィードバックとかではなく、単に話題を振ってコミュニーケーションを取るというコメントはいつでも大歓迎です。

ブログ記事

遠回りになる可能性がありますが、ユーザ自身のブログの記事としてフィードバックする方法もあります。 もちろん、それをコミッタ(作者)が見つけるかどうかはわかりませんが、最も気軽に書ける場所です。 見つけた場合は、積極的にコメントさせて頂きます。コミッタ(作者)と同じブログシステム上のブログであれば、見られる可能性は高いでしょう。

カンファレンス会場

DBFluteは、カンファレンスなどのセッションで話題にされることがあります。会場には、コミッタ(作者)もいる可能性があります。 そのとき、袖を捕まえて、直にフィードバックをするのも良い方法です。 会話に加えて、(ノートPCがあれば)一緒の画面を見ながらやり取りができるため、スムーズにことが運ぶ可能性が高いです。

早い解決のために

インターネット上は、インタラクティブなやりとりの難しい環境です。 それぞれの人にそれぞれの都合があるため、すぐに反応ができない可能性があります。 例えば、質問や要望をMLに投稿して、しばらく何も反応がないというのはよくあることです(それは、仕方のないことです)。 そういうことから、もし内容が固まっているのであれば、投稿のタイミングは早い方が効率的です。

また、完璧な文章を書くのは難しいものであることから、投稿内容に対する反応者からの質問、確認など何度かやり取りが発生する可能性があります。 先述の通りやり取りのタイムラグが想定されるため、投稿内容が不十分であればあるほど解決は遅くなります。 このページの "フィードバックのポイント" をよく読み、内容を充実させた上で投稿することが早い解決につながります。

一方で、そういう性質から、話題(質問や要望など)を提供する場合は、しばらくの間(例えば、2, 3日の間)、 できる限りの頻度でメールチェック(or ブログチェックなど)は欠かさずすることが重要です。 タイミングよくすぐに反応があるかもしれませんし、または、特に日中は大抵の人が仕事中なので仕事が終わってからの夜に反応があるかもしれません。

またそれは、話題を振る側の回答者、閲覧者に対する礼儀にもつながります。 例えば、金曜日の遅くに投稿して(土日は休んで)月曜日まで放置すると、もし投稿後すぐに投稿内容に関する(逆)質問がきていたとしても話が進みません。 もしかしたら回答者、閲覧者は不十分な情報だけで二日間考えてしまうかもしれません(投稿された問題を自分の問題のように親身に考えてくれる方もいらっしゃいます)。 あまり厳密に考えて気重になる必要はありませんが(仕方がないときは仕方ないので)、 話題を振るからにはできるだけ投げっぱなしはせず、(日に一度だけのチェックでも)インタラクティブなやり取りによる早い解決につながると良いでしょう。