Raising bugs is a skill. It can be done poorly or effectively. To illustrate this, let's consider two issues on GitHub. Each of them raise the same issue but do so in drastically different ways. This is the first variant:

This is the second variant:

As a maintainer of this code base, which bug report would you prefer to receive? Obviously the second. Yet we see, time and time again, thousands of bug reports and raised issues on open source projects that not only fail to accurately relay the issue at hand but are impatiently worded and disrespectful of the time and efforts of the project owner.

Generally, when raising a bug it is best to include, at minimum, the following information:

• Problem summary: You should briefly summarize the problem being experienced in regular prose so that the issue can be quickly understood and triaged (possibly by someone who is not adept at diagnosing or fixing the exact issue).
• Steps taken: You should show the exact code that could be used to reproduce the actual behavior that you receive. The reader of your bug should be able to take your shared code or input parameters and reproduce the behavior themselves.
• Expected behavior: You should demonstrate what you would expect the behavior or output to be, given the input. 
• Actual behavior: You should demonstrate the incorrect output or behavior that you observed.

Here's an example of such a bug report for a fictional sum() function:

• Problem summary: sum() does not behave intuitively when given null inputs
• Steps taken: Called sum(null, null)
• Expected behavior: sum(null,  null) should return NaN
• Actual behavior: sum(null, null) returns 0

It may also be useful to include information about the environment in which the code is running, including hardware and software (for example, MacBook 2013 Retina, Chrome version 43.01). The entire purpose of raising a bug is to communicate an unexpected or incorrect behavior with a level of accuracy and detail that'll allow a swift resolution. If we limit the amount of information we provide, or are outright rude, we drastically decrease the probability of our issue being resolved.

Apart from the specific steps we should take when raising issues, there is also a wider question around how we should drive and inspire systemic change in a piece of software or a culture. We'll be exploring this next.