聞いてくれてありがとうございます！この質問に答えるための完全なドキュメントがあります。Contributing to Django をお読みください。
\n心配しないでください。私たちはあなたを無視していません！
\n「チケットが無視されていること」と「チケットがまだ通っていないこと」との間には違いがあることを理解することが重要です。Djangoのチケットシステムには数百もの未解決のチケットがあり、機能の点でエンドユーザに与える影響の度合いも様々です。そのため、Djangoの開発者はそれらをレビューして優先順位付けをする必要があります。
\nOn top of that: the people who work on Django are all volunteers. As a result,\nthe amount of time that we have to work on the framework is limited and will\nvary from week to week depending on our spare time. If we're busy, we may not\nbe able to spend as much time on Django as we might want.
\nThe best way to make sure tickets do not get hung up on the way to checkin is\nto make it dead easy, even for someone who may not be intimately familiar with\nthat area of the code, to understand the problem and verify the fix:
\nAre there clear instructions on how to reproduce the bug? If this\ntouches a dependency (such as Pillow), a contrib module, or a specific\ndatabase, are those instructions clear enough even for someone not\nfamiliar with it?
If there are several patches attached to the ticket, is it clear what\neach one does, which ones can be ignored and which matter?
Does the patch 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 patch actually fixes it.
If your patch stands no chance of inclusion in Django, we won't ignore it --\nwe'll just 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 to the mailing list 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 when the core developers are trying to hit a feature\ndeadline or manage a planning phase, you're not going to get the sort of\nattention you require. However, if you draw attention to a ticket when the\ncore developers are paying particular attention to bugs -- just before a bug\nfixing sprint, or in the lead up to a beta release for example -- you're much\nmore likely to get a productive response.
\nGentle IRC reminders can also work -- again, strategically timed if possible.\nDuring a bug sprint would be a very good time, for example.
\nAnother way to get traction is to pull several related tickets together. When\nthe core developers sit down to fix a bug in an area they haven't touched for\na while, it can take a few minutes to remember all the fine details of how\nthat area of code works. If you collect several minor bug fixes together into\na similarly themed group, you make an attractive target, as the cost of coming\nup to speed on an area of code can be spread over multiple tickets.
\nPlease refrain from emailing core developers personally, or repeatedly raising\nthe same issue over and over. This sort of behavior will not gain you any\nadditional attention -- certainly not the attention that you need in order to\nget your pet bug addressed.
\nSeriously - we're not ignoring you. If your patch stands no chance of\ninclusion in Django, we'll close the ticket. For all the other tickets, we\nneed to prioritize our efforts, which means that some tickets will be\naddressed before others.
\nOne of the criteria that is used to prioritize bug fixes is the number of\npeople that will likely be affected by a given bug. Bugs that have the\npotential to affect many people will generally get priority over those that\nare edge cases.
\nAnother reason that bugs might be ignored for while is if the bug is a symptom\nof a larger problem. While we can spend time writing, testing and applying\nlots of little patches, sometimes the right solution is to rebuild. If a\nrebuild 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 just 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.
\nWhatever the reason, please keep in mind that while you may hit a particular\nbug regularly, it doesn't necessarily follow that every single Django user\nwill hit the same bug. Different users use Django in different ways, stressing\ndifferent parts of the code under different conditions. When we evaluate the\nrelative priorities, we are generally trying to consider the needs of the\nentire community, not just the severity for one particular user. This doesn't\nmean that we think your problem is unimportant -- just that in the limited\ntime we have available, we will always err on the side of making 10 people\nhappy rather than making 1 person happy.
\n