feat: add a perfect bug report template

This commit is contained in:
Ploc 2025-04-09 22:31:08 +02:00
parent 19c4a0b6ed
commit 6b9e3a6e96

View file

@ -0,0 +1,97 @@
# title
Short and specific: **a clear summary of the bug**.
It should also be **searchable**, so developers can find it in a pinch.
> Tips on writing great titles:
>
> 1. Keep it simple, but descriptive.
> 2. Dont abbreviate.
> 3. Make it searchable.
> 4. Focus on the technical problem.
> 5. Highlight the specific feature/component you have issues with.
## description
Small text to describe the bug with human words.
## steps to reproduce
**Describe how you found the bug**, so the developer can try to reproduce it.
> Tips on writing reproducible steps:
>
> 1. Use a numbered list so its easy to follow.
> 2. This is your chance to be comprehensive and (reasonably) verbose. Dont leave out any details!
## expected vs. actual results
Take some time to explain what **should** happen vs. what **actually** happened.
If you just describe the bug, some people might think youre describing the expected behavior.
### expected results
### actual results
> Tips for writing expected vs. actual results:
>
> 1. Use a direct comparison format. For example, "*The button should turn green*" vs. "*The button is turning blue*".
> 2. Be precise. Simply stating "*it went wrong*" instead of *"the page loads indefinitely*" means you are leaving out very valuable information!
## visual proof/screenshot
Screenshots and annotations help developers **visualize the bug**, and pinpoint its location on the page.
> Tips on taking great screenshots:
>
> 1. Annotations go a long way towards driving your point across.
> 2. Highlight the problematic element. Dont be ambiguous.
> 3. Use big fonts, different colors, etc. - the bug needs to be even more obvious here than in your summary.
> 4. For complicated issues, record a short video! This adds a ton of helpful context when trying to reproduce bugs.
## priority
The urgency and **potential impact of the bug**. Determines how quickly it needs to be fixed.
> How to determine priority/severity:
>
> 1. Critical: blocking bugs that **directly prevent business**. Example: a checkout page not loading.
> 2. High: affects **major features**, but non-breaking. E.g.: the search bar on an e-commerce website.
> 3. Medium: noticeable bugs that **disrupt normal use**. E.g.: broken link, long loading times.
> 4. Low: **small issues** and enhancements: typos, missing images...
## environment
For developers to reproduce and fix your bug, theyll need to know your **browser version**, **screen size**, **operating system**...
Some bugs only occur within specific environments.
- source url:
- operating system:
- browser:
- viewport:
> How to find your environment info:
>
> 1. **Browser and version**: look for a “Help” or “About” option in your browsers menu.
> 2. **Operating system**: on PC, press the Windows key + Pause/break. On a Mac, click the Apple logo and choose “About this Mac”.
> 3. **Screen size**: look in your computers display settings, or search online for “screen resolution” along with your device model.
## console logs
This is where your web browser **shows errors or warnings**.
Console logs can help developers figure out what went wrong.
```log
console log
```
> How to access your console logs:
>
> 1. Right-click the page, select “Inspect” or “Inspect Element”, then click on the “Console” tab.
> 2. Try to make the bug happen again and see if any messages pop up there.
## credits https://www.perfectbugreport.io/