It never fails, software fails
So true and when it does, often times I get an email that lacks enough information to resolve the problem the first time around.
Normally on these articles that I want to share, I’d write a summary and then have you link off to the original. However, Scott’s writing is pretty concise and his message is true to my troubleshooter’s heart.
How to write a great bug report
We know you don’t like bugs. We don’t like them either. But as they’re an unavoidable part of software, it’d be good for us to share how best to report issues to us to speed things along.
In short, here’s a great rule: If we can’t reproduce the bug, we can’t fix the bug.
When you report a bug to us, here’s what happens:
- We read the bug report
- One of us tries to reproduce the bug
- If we can reproduce it, we investigate what’s broken and fix it.
- But if we can’t reproduce the bug…
Often bug reports don’t include enough information. Meaning we have go back and ask for details so we can investigate. If you want to increase the odds we fix an issue, and fix it fast, help us out.
A great bug report include the following:
- What were you trying to do?
- What did you click on or do last?
- What happened / what did you see?
- What browser are you using?
- What version of WordPress?
- What hosting provider? (And if you know, what version of PHP do they use?)
You don’t need to be verbose. A sentence for each is often just fine. And bug reports that show screenshots for #3 are incredibly useful, as we can see exactly what you saw.
We work hard to have you deal with as few issues as possible, but if you want to improve the odds we can fix your issue fast, please take a extra minute to write a bug report that’s easier for us to use. Thanks.
Make it Better?
Scott’s done a fantastic job here, but I’d like to point out that sometimes, knowing the operating system or version of TYPO3 is helpful as well.
Next time software fails, please write a better bug report
You know how now.