聞いてくれてありがとうございます！この質問に答えている完全なドキュメントがあります。Contributing to Django をお読みください。
\n心配しないでください。私たちはあなたを無視していません！
\n「チケットが無視されていること」と「チケットがまだ関心を集めていないこと」との間には違いがあることを理解することが重要です。Django のチケットシステムには数百もの未解決のチケットがあり、機能の点でエンドユーザに与える影響の度合いも様々です。そのため、Django の開発者はそれらをレビューして優先順位付けをする必要があります。
\nその上、Django の作業をしている人はみなボランティアです。そのため、Django のために働ける時間は限られていますし、その時々によりどの程度の時間が確保できるかが変化します。我々が忙しい場合には、十分な時間を Django のために費やすことができないかもしれません。
\nチケットが受け付けられる前に止まってしまわないように最良の方法はその分野のコードに詳しくない人でも簡単に問題を理解し、修正が確認できるような内容にすることです。
\nバグを再現するための明確な手順は書かれてますか？もし、依存関係(たとえばPillow)や contrib モジュールや、ある特定のデータベースなどが関係しているのであれば、それらに関する手順も詳しくない人にとっても十分分かりやすく書かれていますか？
If there are several branches linked to the ticket, is it clear what each one\ndoes, which ones can be ignored and which matter?
Does the change include a unit test? If not, is there a very clear\nexplanation why not? A test expresses succinctly what the problem is,\nand shows that the branch actually fixes it.
If your contribution is not suitable for inclusion in Django, we won't ignore\nit -- we'll close the ticket. So if your ticket is still open, it doesn't mean\nwe're ignoring you; it just means we haven't had time to look at it yet.
\nA polite, well-timed message in the forum/branch is one way to get attention.\nTo determine the right time, you need to keep an eye on the schedule. If you\npost your message right before a release deadline, you're not likely to get the\nsort of attention you require.
\n丁寧なIRCのリマインダーでも良いでしょう。繰り返しになりますが、可能ならタイミングを見計らってください。例えば、バグスプリントの期間はとても良いタイミングでしょう。
\n目に付きやすくするためのもう一つの方法は、いくつかの関連するチケットをまとめることです。誰かが腰を据えてバグのレビューに取り組む時、対象の領域にしばらく触れていないと、関連するコードの動作の詳細をはっきりと思い出すために少し時間がかかります。あなたが関連するグループのバグフィックスをまとめておけば、取り組むのに魅力的なターゲットにすることができ、複数のチケットに分散しているよりもコードをすぐに思い出せるようになります。
\n個人的に誰かにメールを送ったり、すでにある同様の issue を繰り返し上げることは避けてください。この種の振る舞いをしてもあなたは注目されませんし、問題を解決するために必要な振る舞いでは決してありません。
\nSeriously - we're not ignoring you. If your contribution is not suitable for\ninclusion in Django, we will close the ticket. For all the other tickets, we\nneed to prioritize our efforts, which means that some tickets will be\naddressed before others.
\nバグ修正の優先順位を付ける一つの基準は、そのバグによって影響を受ける人々の数です。多くの人々に影響する可能性があるバグは通常、非常に特殊な状況下で発生するバグよりも高い優先度が付けられます。
\nAnother reason that a bug might be ignored for a while is if the bug is a\nsymptom of a larger problem. While we can spend time writing, testing and\napplying lots of little changes, sometimes the right solution is to rebuild. If\na rebuild or refactor of a particular component has been proposed or is\nunderway, you may find that bugs affecting that component will not get as much\nattention. Again, this is a matter of prioritizing scarce resources. By\nconcentrating on the rebuild, we can close all the little bugs at once, and\nhopefully prevent other little bugs from appearing in the future.
\nいずれにせよ、あなたが特定のバグに定期的に遭遇しても、必ずしも全ての Django ユーザーが同じバグに遭遇するとは限らないことを留意していてください。異なるユーザーが、異なる環境下で異なる部分にコードが影響を与えるいろいろな方法で Django を利用しています。相対的な優先度の評価に際して、通常私たちは個別のユーザーにとっての重症度だけでなく、コミュニティ全体の需要を考慮しようとしています。これはあなたが遭遇した問題を私たちが軽視するということでなく、利用できる有限な時間内において、私たちは 1 人よりも 10 人を幸せにした方が良いと考えているだけなのです。
\n申し訳ありませんが、ありません。チケットは常に他の視点で見る方が良いのです。もし、他の視点を得るのが難しい場合は、上記の質問を参照してください。
\n