Elm Advent Calendar 8日目です。たまにはメタなのどうでしょう。
バグ報告・機能要望の出し方
基本的にオープンなのでどんどん報告して大丈夫ですが、少々癖があるのでツボを押さえておくとよりスムーズにいきます。
バグ報告の仕方
バグならGitHubにIssue、議論が必要そうならelm-discuss、まず質問したいのならSlackなど使い分けると良いです。ただし、Slackだと流れて終わってしまう場合があるので、やはりIssueの形で残すのがベストでしょう。
バグ報告は可能な限りSSCCEをつけること推奨。SSCCE(Short, Self Contained, Correct (Compilable), Example)は最小手でバグを再現するコードスニペットのこと（例１、例２）。加えて、バグの発生した環境（OS、ブラウザ、Elmのバージョン、ライブラリのバージョン）を併記します。あとはもちろん、Issue被りがないか事前にチェックするなど基本的なマナーは守ります。この辺りの事は、Issueを立てた直後にbotがチェック事項を教えてくれるので、そこで確認して直せばOKです。
バグ報告する場所
基本的に、該当するリポジトリを探してIssueを出せばOK。太字だけが少し分かりにくいです。
| 報告先 | 報告対象 |
|---|---|
| elm-lang/elm-compiler | コンパイラのバグ |
| elmlang/elm-package | elm-packageのバグ |
| elm-lang/elm-core | コアライブラリのバグ |
| elmlang/virtual-dom | デバッガーのバグ(0.18現在ここ) |
| elm-lang/elm-lang.org | 公式サイトの不具合 |
| elm-lang/package.elm-lang.org | パッケージサイトの不具合 |
| Error Message Catalog | 分かりにくいエラーメッセージ |
機能要望の出し方
基本的に新しい機能に対しては慎重なので、いきなりPRを送ってもまずマージされません。特に議論が必要になりそうなものは、Issueではなくelm-discussでコンセンサスを取るところからはじめるのが良いでしょう。
要望の内容は、ユースケースを一緒に書くと喜ばれます。ただ「この機能がほしい」と言っても「なぜそれが必要になるのか？」と問い詰められるので、「こういうことをする時にこの機能がなくて困るから追加してほしい」と説明するのが良いです。そうすると、今のAPIがそのようになっている理由を説明されたり、別の解決方法じゃなぜ駄目なのかという話になり、最終的に「もっともらしい」と判断されると人知れずタスクに詰まれます。
例えば、「型クラス追加して欲しい」よりも、「辞書のキーにBoolを入れられるようにして欲しい」とか「回避策としてBoolをStringにシリアライズするとコード量が3倍になった」とか「それが必要になるケースは10アプリ中8アプリにあった」とか具体的に説明すると、受け入れられる確率が上がります。
解決のタイミング
Issueの内容や報告するタイミングによっては結構待たされたりしますが、無視されているわけではないので気長に待ちましょう。Evan Czaplicki氏のトーク「Code is the Easy Part」の"Batching Work"で触れられている通り、ある程度Issueを集めて傾向をつかんだ上で似たようなものを一気に片付けるという方法を取っているため、とのことです。
とはいえ、タイポなどの比較的軽微なものや、リリース直後の重大なバグなどはすぐに解決されることが多いです。
フォーラム
要望や質問の問い合わせ先は主に次の３つがあります。Elmコミュニティは初心者フレンドリーなので質問は気軽に投げて大丈夫です。
| 場所 | 話題など |
|---|---|
| elm-discuss | 初心者の質問・相談、より高度な議論、ライブラリ公開のアナウンス、なんでも可なメーリングリスト。大抵はこちらを使う。 |
| elm-dev | Elm自体の開発に関するメーリングリスト。最新版の開発状況などが共有される。トピック設立はEvanやコアメンバーが中心で、elm-discussよりも敷居が高い。誰でも読めるが、最新版の情報はSNSなどで拡散すると怒られる。 |
| Slack | おすすめチャンネル（#general, #random以外）は #dev, #news-and-links, #help。初心者の質問はMLよりもSlackの方がすぐに回答が来る。 |
elm-discuss には「質問するときは XY Proglem を考えてね」という注意書きがあります。XY Proglem とは「本当は X という問題の解決策が知りたいのに Y が解決策だと思って Y について質問しに行く」という良くある問題です。例えば「Cmdを連鎖する方法を教えてくれ(Y)」「何がしたいの？」「HTTPリクエストを続けて投げたい(X)」「それならHttp.toTaskがあるよ」のような回り道を避けましょう（というか、これElmに限らず本当によくありますね…）。
リアルでコミュニケーションを取りたい場合は、カンファレンスにも足を運びましょう（いきなりハードル高いですが）。
| イベント | 詳細 |
|---|---|
| elm-conf 2016（終了） | 2016/9/15 アメリカ・セントルイスにて |
| Elm Europe 2017 | 2017/6/8-9 フランス・パリにて |
まとめ
色々書きましたが、怖いところではないので積極的に参加しましょう。特に、具体的・実践的なユースケースは向こうも情報として欲しがっているので、フィードバックすると喜ばれます。もちろん、雰囲気をつかむために最初はフォーラムをROMってるだけでも面白いですよ。