| revision-up-to: | 17812 (1.4) |
|---|
よくぞ聞いてくれました！まさにこの質問に答えるためのドキュメントを用意して あります。 Django プロジェクトへの貢献 という文書です。
心配しないでください。無視しているわけではないんですよ！
まずは「チケットを無視する」ことと「まだチケットを検討していない」ことの違 いを理解してください。 Django のチケットシステムにはオープン状態のチケット が何百もあり、個々のチケットがエンドユーザの使い勝手に与えるインパクトも様々 です。そのため、Django の開発者達はチケットをレビューして、優先順位を決めね ばならないのです。
なにより、 Django プロジェクトに関わっている人たちは全てボランティアです。 ですから、彼らがプロジェクトにかけられる労力には限界があるし、彼らがプロジェ クトに割ける時間もその時々で変化します。忙しいときには、十分な時間をかけら れず、なかなか要望に応えられない場合もあるのです。
チケットを速やかにチェックインさせたいなら、チケットの内容をできるだけ簡単 にして、分野の違う人であっても問題を理解でき、修正内容を検証できるようにし ましょう。そのために、以下のことをチェックしてください:
また、あなたのリクエストを Django に取り込まないとはっきりした場合でも、チ ケットを無視せず、必ずクローズします。従って、チケットがまだオープンの状態 なら、リクエストは無視されているのではなく、いま一時的にリクエストに目を通 す時間を取れないという状態なのです。
丁寧に書かれたメッセージを、メーリングリストにタイミングよくポストするのが コツです。タイミングをはかるには、開発のスケジュールを追いかける必要がある でしょう。コアチームの開発者が開発スケジュールの締め切りを目指しているとき やプランニングを行っているときには、思ったように注意を引けないでしょう。 逆に、コアチームの開発者がバグフィクスに注意を払っているとき、たとえばバグ フィクスのためのスプリントを控えているときや、ベータリリースの最中には、建 設的なレスポンスをもらえることでしょう。
IRC で適度にリマインダを送るのもそこそこ効果があるでしょう。もちろん、可能 なら戦略的にやりましょう。たとえば、バグフィクススプリントの最中などは、と てもよいタイミングのはずです。
注意を引くもう一つの方法は、関連のある複数のチケットを一つにまとめるという ものです。コアの開発者がしばらくいじっていない分野のコードのバグフィクスに 取りかかるときには、コードがどのように動くかを細かく思い出すまで時間がかか るものです。同じ分野の小さなバグフィクスを複数まとめて、共通のテーマをもっ た一つのグループとして提示すれば、特定の分野のコードに慣れるまでのコストを 複数のチケットに分散させられるので、開発者にとっては魅力的なターゲットにな り得ます。
コアチームの開発者に直接メールを送るのは避けてください。また、同じ問題を何 度も何度も繰り返すのもよくありません。その手の行動は、あなたの大切なバグの 解決につながるような注意を全く引きません。
本当に、本当に無視はしていません。トラッカにあるパッチを Django に組み込ま ないと決めたなら、チケットは閉じられます。それ以外のチケットに対しては、優 順位付けをして取り組んでいます。従って、チケットによっては先にポストされた 他のチケットよりも前に解決されることがあります。
バグフィクスの優先順位を決める基準の一つは、そのバグによって影響を受けると 考えられるユーザの規模です。多くのユーザに重大な影響を与えるようなバグは、 極端なケースでのみ発生するバグよりも優先されます。
もう一つ、バグが無視されたかのように扱われる状況があります。それは、バグが より大きな問題の一症状である場合です。時として、たくさんの小さなパッチを書 いてテストし、適用していけば解決できる問題の中に、いっそ再構築してしまうの が正しいようなケースがあります。あるコンポーネントの再構築やリファクタが提 案されていたり、作業中だったりする場合には、そのコンポーネントに関するバグ には注意が払われないことがあるのです。再構築に集中すれば、小さなバグをまと めて一気に閉じられるし、将来にわたって似たような小さなバグが現れるのを防げ ます。
理由はどうあれ、あなたの環境では常に問題化するバグが、他のすべての Django ユーザの環境で問題化するとは限らない、ということを覚えておいてください。 Django のユーザはそれぞれに違う方法で Django を使っていて、コードに負荷をか ける場所も違えば条件も違います。全般的に、バグフィクスの優先順位を相対的に 決めるときには、私たちは特定のユーザにとっての深刻さより、コミュニティ全体 にとっての必要性を考慮します。だからといって、あなたの環境で起きている問題 が重要でないと考えているわけではありません – 限られた時間を使うときには、 1 人のユーザを救うことより、10 人のユーザを救う側に立たざるを得ないのです。
Oct 26, 2017