Here's one problem I don't have a strategy yet: I find an important bug in an open source project, contact a mailing list requesting the maintainers to fix it and after a triage, I get no response.
What could I do to maximize the chances of getting the bug fixed? So far I usually resort to nagging, but this seems to rarely work out well.
Ultimately, if the developers are working on the project as a labor of love, they're going to work on what they want to work on. You can't expect them to prioritize your issue just because you asked them to. Instead, you can try to add incentives to make it more likely that your issue is one that they do want to work on.
I can think of a few options, depending on the particular circumstances:
Patch it yourself: In the event that you have the technical know-how to fix the bug yourself, you can submit a patch. Be sure to follow the project's style guide, and ensure that your patch includes tests if the project maintainers typically expect them. Of course also make sure it doesn't cause any new problems in any other parts of the project (so, don't cause any existing tests to fail, for starters). Submit your patch for integration into the project.
Supply more information: Even if you can't completely fix the problem yourself, try investigating the issue further. See if you can find any relevant parts of the code that cause the problem, or see if you can produce any other test cases that reveal more information or are more succinct than whatever you've already given. If you do a good job here, you can simultaneously draw renewed attention to the issue while potentially making it easier for the developer(s) to solve.
Get other people involved: If you know that lots of other people have this issue, draw their attention to your issue in the project's issue tracker and have them star/comment, depending on the features of the tracker. If it becomes obvious that the issue affects a lot of people, it will probably get higher prioritization. Obviously, if you do this all the time, or in an obnoxious way, you might just be delegating your unsuccessful "nagging" approach out to other people, so use this option thoughtfully.
Money talks: If it's really important to you to see this issue fixed immediately, pay the developers to fix it. If lots of people have this issue, see if you can collect money from multiple sources via a crowdfunding platform like Indiegogo. If the developers aren't interested in your money (e.g., they simply don't have the time, and money won't change that), you can pay someone else to fix the issue, since you have the source code already. See Nikolas Raoul's answer for step-by-step look at the process involved in contracting a patch.
Apsillers' answer is perfect, I will just add a case study about the last paragraph ("Money talks").
My open source project (1.5 million users) has had users pay third-party companies for features. I wrote the guidelines below, they are general enough to be applicable to most projects:
In case you are willing to pay money for a feature or fix to be implemented, here is how you can do it:
Find the issue in the issue tracker, or create a new issue if it does not exist yet.
Add as many details as you can, describe how it could work, draw a prototype on paper, etc.
Post a comment asking "If I provide a good quality patch for this feature, will it be merged?" and wait for our answer.
Choose someone to do the job. Use any crowdsourcing platform you trust (for example bountysource), or a developer friend, or a software company. Make sure they know Android and Git.
Reach an agreement with the developer:
Agree with the developer on the conditions, defining exactly what they must implement.
Insist that produced source code must be released as Open Source (not doing so would be a breach of the GNU-GPLv3 license). A common error would be to ask only for the binary (which will quickly get out-of-date and incompatible)
If possible, make it a condition that produced source code must be merged by us before total payment. Or make it half/half. If the issue is classified as "critical" in our issue tracker, then the developer can be assured that we will merge it fast, if the code is good enough.
Propose to become a tester if they need. Giving your feedback early could help. Be sure to test on different devices and in different scenarios.
Summary of the workflow:
You must also consider that what you consider an important bug might be very low priority for the developers (for whatever reason). Yes, there have been cases where blatant security problems were dismissed as "irrelevant". In the end, you'll have to make your own call.
Added later: If it is commonly packaged in distributions (in particular, it is in yours, as mentioned in a comment), perhaps the best bet is to report it locally. Your distribution's packagers are often active upstream too, or at least have more direct access to upstream developers. A bug report by the maintainer of the package in a major distribution will certainly carry more weight than one by an unknown user on foot.
