# 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. Don’t 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 it’s easy to follow.
> 2. This is your chance to be comprehensive and (reasonably) verbose. Don’t 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 you’re 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. Don’t 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, they’ll 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 browser’s 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 computer’s 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/
