diff --git a/.gitlab/issue_templates/default.md b/.gitlab/issue_templates/default.md
new file mode 100644
index 0000000..1becc6d
--- /dev/null
+++ b/.gitlab/issue_templates/default.md
@@ -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. 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/