Skip to main content
A useful report lets another person reproduce the problem or identify the missing evidence. A screenshot alone often shows the symptom without showing its trigger. Start with the smallest example that still fails.

​
A report template

Name one primary problem. “The mobile menu covers the submit button at 390px width” is easier to investigate than “the site is broken.” If the problem is intermittent, give the approximate time and timezone and explain what changed between successful and failing attempts.

​
Remove unrelated details

Try a fresh non-sensitive example. Reduce an API request to the parameters needed to reproduce the behavior. Describe whether extensions, a VPN, or a particular network affect the result without assuming they caused it. Do not erase the original error by repeatedly changing settings before recording it.

​
Protect private information

Redact cookies, authorization headers, API keys, confirmation links, personal email addresses, and private administration URLs. Browser network exports can include credentials and request bodies; review them carefully instead of attaching an unfiltered archive. If the issue is a security vulnerability, follow the project’s private reporting instructions rather than posting an exploit with sensitive evidence publicly.

​
After reporting

Answer requests for missing details and update the report if you discover a reliable workaround. Keep hypotheses separate from observations. A suspected root cause is useful context, but a reproducible example is stronger evidence. For this personal website, use contact for ordinary issues and the security guidance for sensitive reports. For external projects, follow their issue templates and contribution policy. Read GitHub’s contribution guide for general etiquette.