Documentation / How to Write a Good Bug Report
How to Write a Good Bug Report
TL;DR - Please create a reproducible bug report!
- We love a new bug report
- Explain how to reproduce your issue
- What else you can do
- How we prioritise bugs
- How to make sure we try fix the bug as soon as possible
We love a new bug report #
We love when you create a new issue for sitespeed.io! We really do. New issues helps us getting the project better and it will help other users. In other words, we love issues.
Sometimes we get a really detailed issue: You describe exactly how you do when you get the problem, you share the log, you write down what you have tested, share screenshots, share videos. You even tries to understand why you get this bug. When we get an issue like that, it always jump to my number one prioritization. If you put down all the time and effort to really describe the issue, we want to put all our effort to fix it.
It also happens (quite often) that we get issues that misses important information, so we need to ask you again and again about the problem (like how to reproduce the issue). Sometimes we need to do that two/three/four times within that issue. Issues that misses vital information takes longer time to fix/close and that makes us spend more time asking questions instead of fixing actual bugs or creating new functionality.
We use a issue template with a comment of what we need write but it seems that is not the best way so let us instead show you what we need!
Before you start creating a issue, you should make sure you have read through our F.A.Q and Best Practice.
Explain how to reproduce your issue #
The best way to make sure we can fix your issue, is to make sure we can reproduce the problem you have. If we can reproduce the problem, we can verify that we actually have fixed it with our code change.
Exactly what do we mean by making it reproducible? We should be able to copy/paste your example CLI parameters and try on our local machine and then get the same problem that you have.
To help us reproduce your problem there are a couple of things we need:
- Show us exactly how you run your tests (all parameters, all configuration). Mask out any passwords. But please do not leave out things from the configuration!
- Include the URL that causes the problem. If the URL isn’t public, please try to reproduce the problem on another URL that we can test. If the URL is super secret, you can share that to us in an email (write it in the issue and you can get the address). But we prefer public URLs so others also can reproduce the problem.
- Include the log output from your run. Please do not take a screenshot of the log, instead share the log as text either in the issue or in a gist.
- Give us the exact version of sitespeed.io you are using (so we know we use the same version when we try to reproduce it).
- Tell us what OS you are using and if you are using Docker (you should!) give us the base OS where you run your container.
- If you don’t use Docker: Include the browser version you are using.
- If you have problems with headers/cookie/auth you can use https://httpbin.org to reproduce your issue.
If you make your issue reproducible, the issue is the cream of the crop and will get the tag reproducible! And if your bug report has that tag, it will get our attention.
What else you can do #
Best case you can fix the issue and send us a PR with a fix. We love PR for bugs :) But of course that is only best case scenario.
Search current GitHub issues. Is this bug reported before? Does it lack info? Please add your own comment to that issue if it is open. If you aren’t sure that your bug is the same as the other bug, please create another issue. Do not hijack issues. Do not comment on closed issue, please create a new issue instead and add a reference to the old issue.
Is there a problem with the video? Then make sure to enable the full original video so you can share that with us, do that by adding
--browsertime.videoParams.keepOriginalVideoto your run (or if you use Browsertime:
Is your problem related to that you are behind a proxy? Then we kindly recommend that you run your tests without a proxy. Run the tests on a network where you don’t need to use a proxy.
How we prioritise bugs #
When we groom issues we will add a tag with the prioritization. We have three prio tags: prio:1, prio:3 and prio:5.
If a issue is bug that breaks functionality for many users or is a feature request that will help many users and its somnething we can implement, we gonna give it prio:1. If the issue is a bug that we plan to fix, it will have prio:3. If your bug/issue gets prio:5 we maybe will fix it sometimes in the future. Also scripting issues releated to how you use scripting on your site always gets prio:5 but we will try to help you the best we can.
If you do not agree with our prioritization you can:
- Explain the issue better and make sure we can reproduce your issue
- Do the PR yourself. We can help you test and verify it.
- Support us at Open Collective. We can not promise we will fix your issue but it will increase the chance of getting it fixed.
How to make sure we try fix the bug as soon as possible #
Here’s dos and don’ts if you want your bug fixed:
- Provide a reproducible test case.
- If you don’t get a response in a couple of days, write a message in the general channel in Slack.
- Contact us on direct messages on Slack about the bug.
- Contact us on Twitter about the bug.
- Contact us on email about the bug.
If we ask you to contact us, then it is perfectly fine to do so :)