Getting a Bug Fixed Sooner
Let's say that you found a bug that affects you, you searched for it and found that it's already submitted. Now you want to ensure that it gets fixed. Here are a couple things you can do to improve the likelihood of the bug getting attention from a developer.
Improving Bug Reports
Many bug reports don't get attention simply because the quality of the report is low making it harder to understand and work on the bug. It will help the developer tremendously if you can take these bugs and improve them so that they have enough information. If necessary, ask questions of the original reporter. Try to repeat the problem yourself and note and differences or similarities in the results and the system configurations. If a developer sees a bug with a clear report that has been repeated then it is much easier for them to fix it.
In addition validating the description, make sure that the status, version, priority, and other values are set correctly.
Increase Visibility of the Issue
Once you have already ensured that the issue is well documented, repeatable, and properly categorized, it's important to make sure that people are aware of the issue. Many times an issue only affects a subset of the population so a developer who might be able to fix your bug might not be aware of it. Several easy ways to help increase the visibility of a particular bug is the write about it in your blog, join #drupal-support on IRC and ask around about the bug, add the bug to your email signature on the account that you use for the mailing lists or to your Drupal.org signature and then be sure to provide lots of help in the forum and the mailing lists so your signature is visible.
How not to increase visibility: send private emails to the module owner. If they are the owner they've probably already seen the bug via email from the issue tracker so another email is just a waste of time to them.
Providing a Patch
Many times the bug report will contain a description of what to change or will have the text of a patch pasted into the bug. While it may seem trivial, a patch makes the maintainer's job easier than just describing the change or pasting the patch into the comments of the bug.
If you can write the necessary code - by all means, create a patch. Again, it makes the maintainer's life simpler if someone creates a patch and all
Improving a Patch
Many times a patch exists but does not conform to Drupal's coding standards or lacks in some other ways. You can help to review the patch and ensure that it conforms to the coding standards. This is relatively advanced for someone who doesn't know how to program PHP, but it isn't terribly difficult and helps you understand how Drupal works.
Improve Your Karma
Another way to get the maintainer to want to fix your bug is to have good karma or a good relationship with them. One easy way to do that is to read through the issues in their queue and "clean them up" as much as you can. This will reduce the workload on their plate which helps motivate them to help you out.
Hire Someone or Providing a Bounty
Many times a bug just needs a bounty. Putting out some money on a bug (or getting others to join together to create a big bounty) can result in the quick resolution. Sometimes you just need a solution now. In that case, take a look at the Support and Professional Services page in the handbook to try and find someone who might be interested. You can also read the HOWTO: Hire a Drupal site developer to help you in finding the right person.
All of the above
Sometimes you have to try out all of these things to get your bug fixed.
Ineffective Methods of Getting a Bug Fixed
- Marking a "closed" or "won't fix" bug as active again without providing a convincing argument as to why it should be opened again. It's better off to provide the convincing argument and let someone else reopen the bug
Suggested addition: Providing a Test
Providing a Test
Remember. Being able to reliably reproduce the bug is the first step to developing a fix to that bug. If you have programming or quality assurance skills, you might consider writing an automated test which will reproduce the bug and create the error.
Even if you don't have the skills to write an automated test, you can still design one. An automated test is simply a program which takes the steps you would in interacting with the application being tested. The automated test gives the input you would give if you were to test the application manually. It then checks the output the application being tested produces and compares that output to the output that the test designer expected to see. If the expected output and the actual output match, the test passes. If they fail to match, then the test fails.
Simply describe what you do to recreate the bug in painstaking detail. Say what output you expected and what outcome you got. If you do that part, you make it easier for someone who does know how to write an automated test to then do so.
More and more programmers are beginning to develop their code using a process known as Test Driven Development. TDD requires a programmer to first write a test of the code they want to write. Run the test and watch it fail. Then write the code the test is designed to test. Run the test and refine the code and the test until the test passes. Once the test passes, it then becomes a part of the application's regression test suite. A regression test suite is an automated tool designed to test whether new changes to a piece of code under development have broken any existing working functions.
If a module has a regression test suite of thirty tests and you work to resolve a bug, but the changes make six of your tests fail, then that tells you you have further work to do integrating the fix for the bug under consideration with the rest of the code. Its not fair to resolve a bug by introducing others in known working code. A regression test suite is a means for ensuring we don't do that.
Users can design and programmers can code automated tests, which will serve three purposes in this process:
(1) they help define the bug to be resolved;
(2) they provide a tool to help test the code while its being debugged;
(3) they provide a regression test to ensure that future development does not break existing functionality.
Designing or developing an automated test is yet another way you can help get a bug resolved quickly.