質問、相談、要望などフィードバック！
dbfluteに対するフィードバックに関する連絡先や手順などについて。
フィードバックの宛先
メーリングリスト (dbfluteユーザの集い)
dbfluteユーザの集い という Google Group があります。 実質的にメーリングリストとなっており、こちらでフィードバックを受け付けています。また、ユーザ同士の情報交換の場として利用できます。 ただみんなに知らせたいだけ、というような通知のような投稿も受け付けています。
dbfluteユーザの集いで投稿するときは、Google Group に入会をお願いします。
Twitter (jflute)
Twitterでもフィードバックを受け付けています(もしくは、Twitterでdbfluteについてつぶやいたら、何か反応させて頂くかもしれません)。 ただし、文字数制限があって非常に議論はしづらい環境ですので、込み入った話になってきたら、"dbfluteユーザの集い" や "dbflute Slack" でやり取りさせて頂く方が良いかもしれません。
ブログコメント (jfluteの日記)
コミッタ(作者)のブログのコメントでもフィードバックを受け付けています。 ただし、非常に議論はしづらい環境ですので、"dbfluteユーザの集い" や "dbflute Slack" がどうしても利用できないというような場合 (例えば、匿名でないとつらいような場合) に利用すると良いでしょう。
ブログ記事
遠回りになる可能性がありますが、ユーザ自身のブログの記事としてフィードバックする方法もあります。 もちろん、それをコミッタ(作者)が見つけるかどうかはわかりませんが、最も気軽に書ける場所です。 見つけた場合は、積極的にコメントさせて頂きます。コミッタ(作者)と同じブログシステム上のブログであれば、見られる可能性は高いでしょう。
カンファレンス会場
dbfluteは、カンファレンスなどのセッションで話題にされることがあります。会場には、コミッタ(作者)もいる可能性があります。 そのとき、袖を捕まえて、直にフィードバックをするのも良い方法です。 会話に加えて、(ノートPCがあれば)一緒の画面を見ながらやり取りができるため、スムーズにことが運ぶ可能性が高いです。
フィードバックのポイント
フィードバック内容として、以下のポイントを一緒に添えて頂けると助かります。
- テーマ
- 一行で要約する、そのフィードバックのタイトル。例えば、"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にとってはうれしいものですが、(ユーザからすれば)ないのにこしたことはないでしょう。
早い解決のために
インターネット上は、インタラクティブなやりとりの難しい環境です。 それぞれの人にそれぞれの都合があるため、すぐに反応ができない可能性があります。 例えば、質問や要望をMLに投稿して、しばらく何も反応がないというのはよくあることです(それは、仕方のないことです)。 そういうことから、もし内容が固まっているのであれば、投稿のタイミングは早い方が効率的です。
また、完璧な文章を書くのは難しいものであることから、投稿内容に対する反応者からの質問、確認など何度かやり取りが発生する可能性があります。 先述の通りやり取りのタイムラグが想定されるため、投稿内容が不十分であればあるほど解決は遅くなります。 このページの "フィードバックのポイント" をよく読み、内容を充実させた上で投稿することが早い解決につながります。
一方で、そういう性質から、話題(質問や要望など)を提供する場合は、しばらくの間(例えば、2, 3日の間)、 できる限りの頻度でメールチェック(or ブログチェックなど)は欠かさずすることが重要です。 タイミングよくすぐに反応があるかもしれませんし、または、特に日中は大抵の人が仕事中なので仕事が終わってからの夜に反応があるかもしれません。
またそれは、話題を振る側の回答者、閲覧者に対する礼儀にもつながります。 例えば、金曜日の遅くに投稿して(土日は休んで)月曜日まで放置すると、もし投稿後すぐに投稿内容に関する(逆)質問がきていたとしても話が進みません。 もしかしたら回答者、閲覧者は不十分な情報だけで二日間考えてしまうかもしれません(投稿された問題を自分の問題のように親身に考えてくれる方もいらっしゃいます)。 あまり厳密に考えて気重になる必要はありませんが(仕方がないときは仕方ないので)、 話題を振るからにはできるだけ投げっぱなしはせず、(日に一度だけのチェックでも)インタラクティブなやり取りによる早い解決につながると良いでしょう。
