Notice this issue, and its tags.   It is listed as a blocking defect that needs to be resolved before Prawn 1.0.

Here is an example of a helpful comment against this issue:

And here is how I responded to it:

On the whole, this is what a good interchange on a bug tracker should look like.  If the ticket already exists, a commenter might provide some additional information worth investigating, and the maintainers of the project ought to provide prompt feedback about that information, so that more actions can be taken.  These are the sorts of comments that move our projects forward.

But there is a whole other type of comment that we get, as well.   Here's an example of one that does NOT move the project forward:

And here is how I responded to it:

I'll be the first to admit, some projects handle these relations better than I do.   But I also want to help solve the root problem, so that project maintainers no longer need to deal with these problems.   I propose these few simple rules when discussing open source. 

RULE 1: If the issue is unknown, come up with a minimal example that reproduces it that can easily be run by others, and then post that issue to wherever project defects are tracked.  Then if you need a solution, work on a fix yourself, asking for help as needed.  You can also wait for someone else to fix it, but unless you've paid someone to look into it, don't expect a particular timeline.  In some cases, your issue will never be fixed.

The above may not seem like a great deal for the end user who is reporting a bug, but there are three good reasons why filing a proper bug report is a good idea:

• IT MIGHT BE USER ERROR:  Often times, it is discovered that given a defect doesn't actually exist, and instead, involves some misuse of a library.  When this is the case, maintainers will get back to you letting you know how to avoid your problem, which is a bit like getting an immediate fix.
• IT MIGHT GET FIXED: If you write up your bug report in a helpful way with sufficient detail, there is a good chance someone will fix it, even if you don't have the time or domain knowledge to do it.
• IT WILL HELP ADVANCE THE PROJECT:  If you take the time to fix your defect, it'll almost certainly cost you less time than it did for the maintainers of the project to give you the free tool you're using.  While most free software producers don't set expectations on their users to contribute back, it does help balance things out a little.  That said, a well written reproduction of a defect is a contribution in itself, so don't underestimate how much it helps producers of OSS when you create one.

But suppose you're looking at an existing issue, and you don't have anything valuable to add...

RULE 2: If the issue is known, and you don't have any new information to help with its resolution, and you can't/won't fix it yourself, and you can't/won't pay for someone else to fix it, you only have one reasonable course of action:  SHUT THE FUCK UP AND BE PATIENT.

We've all been in the situation where we curse the name of some project or person because of a bug that got in our way.  In private, I think this is the natural release of frustration about a problem that we don't have an immediate solution to.   In public, it becomes something else entirely, and directly affects real people who work hard to put something out there for free and then get constantly criticized.

So please, if you can't be part of the solution, we'll understand.  But don't be part of the problem.