When I just started working in Automattic, I always terrified of bug reporting. Mostly because I feel like I’m not in a good position to report anything, and even if I did, I’m scared of the prospect of other folks in the company — the more experienced ones — looking at me while asking, “what do you know?”
And I can’t be more wrong than that. On the last year’s Grand Meetup, I sat with folks from different divisions and teams during breakfast, lunch, and dinner. Whenever I mentioned that I’m a Happiness Engineer (Support), they always exclaimed, “you are from Happiness! Can you share with me what are the things that we can improve? Do you happen to see some stuck issues that you want to be fixed immediately?”
Soon, I learned on how to report bugs on GitHub. I have so many help and encouragements from developers and friends from different divisions. They shared some tips and insights on how to report bug properly so the developers or folks in charge would know what to do next.
I omitted the “Who” because that’s not the focus on bug reporting. The “who” would be pretty obvious: The one who reported the bug.
The What. What is it? What’s happening? Something is not working, something is broken. Something needs to be fixed.
The Where. Where did it happen? Is there any specific area where you found the bug? Is it on the editor, is it on your live site?
The When. Is it intermittent? Is it constant? When did it started? Has it been long?
The Why. As silly as this sounds, you can share more on why you report the issue. Maybe you feel this is actually enhancement that can improve the process, maybe you feel some flows can be reduced for effieciency. And most of times, this is a bug that needs to be addressed ASAP because it’s destructive.
The How. The most important question: How to replicate the issue? You can share the steps as detailed as possible. For example, first step, click this link. Second step, click that button. Third step, add this element. Fourth step, see everything burn in flames.
Set the goal
Once you can determine the 4W1H, set the goal. What you expected and the reality/what actually happened.
”So! I clicked this button and that button. I expected a pop-up will appear. However, in reality, nothing appearing, and I even see an error message!”
It gives clear goal and expectation of what should happened so we can narrow down on what went wrong/the cause.
We trust you, we are trying to replicate the issue
I noticed a behavior where some folks discussing an issue with Support team and they usually mentioned, “I might sound super silly right now, but I swear before I saw this error message,” “I really hope you don’t take me as a rambling mess, but I definitely had a trouble before,” or, “I’m so sorry for wasting your time, but I did saw an error on my page earlier today.”
No, you are not wasting Support’s time. Even after so many questions from us and the error suddenly disappeared, please rest assured, we appreciate you reaching out to Support. That great relief when you see the problem disappear? Yeah, we feel it too. Even when we literally go, “… 😀?” in front of our laptop because, ”I swear to everything holy in this world, I haven’t done anything! So, uh… Yay?“
Sometimes folks might feel bit overwhelmed when Support asks questions and some might forgot the details or they might afraid to overshare (“is this relevant? Should I mention about this weird blinking text on my site? I’m curious about this weird letters on my site, should I mention about it too?”) That’s completely okay! Any details are appreciated. Even when you feel like you are missing something, that’s okay. Support is there to check for the gaps and fill in the details. Once Support has the general picture, we can narrow down the issue and assist you faster.