Before opening a thread about a crash, a broken package, or a graphics glitch, it helps to assemble the same information a maintainer would ask for anyway. A report with exact versions, a minimal reproduction, and clean logs gets looked at faster than a description of symptoms alone.
Start with exact release and kernel
Run cat /etc/os-release and uname -a. Paste both outputs verbatim rather than paraphrasing (“ROME”, “Rolling”, or a specific point release all behave differently, and kernel point releases matter for driver regressions). If the system has been rebooted since an update, note whether the running kernel matches the installed one — a stale session can make a fixed bug look unresolved.
Capture package and repository state
rpm -qa | sort gives a full package list; for a shorter report, dnf repolist plus dnf list installed <package> for the component in question is usually enough. Include which repositories are enabled, since third-party or testing repos change behavior in ways that are easy to overlook. If the issue appeared after an update, dnf history and then dnf history info <id> on the relevant transaction shows exactly what changed and when — this single step often replaces several paragraphs of guesswork.
Note the desktop session and graphics driver
Wayland and X11 sessions can behave differently for the same bug, so state which one was active (echo $XDG_SESSION_TYPE). For graphics, lspci -k | grep -A 3 VGA shows the card and the kernel driver in use, and glxinfo | grep "OpenGL renderer" (or the Wayland equivalent) confirms whether the expected driver actually loaded. Mesa or proprietary driver version mismatches are a common source of reports that can’t be reproduced elsewhere.
Write down the minimal steps
Try to strip the reproduction to the smallest number of actions that trigger the problem — ideally starting from a fresh session rather than one with several other applications already open. A ten-step description with unrelated background noise is harder to follow than three steps that isolate the failure.
Attach journal output as text, not a photo
journalctl -b -1 (for the previous boot, if the machine was rebooted after a crash) or journalctl --since "10 minutes ago" captures relevant log lines. Paste this as text inside code fences rather than a screenshot of a terminal — it stays searchable, copyable, and doesn’t lose lines to window size.
Show before and after
When reporting a regression, a short comparison of the working state versus the broken one is more useful than either alone: the same command, the same window, ideally the same session type, run before and after the change that seems responsible.
Redacting screenshots without faking evidence
Screenshots sometimes include usernames, hostnames, file paths, or window titles that shouldn’t go into a public thread. Blurring or covering that information on a copy of the image — never on the original evidence — keeps the report shareable without exposing personal details. For this kind of annotation or redaction work, an image editor can be used and should never be used to alter or simulate actual terminal output or interface screenshots, since that would misrepresent the bug itself.
Limitations to keep in mind
None of this guarantees a fix, and some bugs are timing-dependent or hardware-specific enough that even a complete report won’t reproduce on a different machine. Logs can also be large; trimming to the relevant time window before pasting keeps a thread readable. Package and kernel version details go stale quickly, so a report should reflect the state at the time of testing rather than being reused across unrelated updates.
A report built this way — exact versions, transaction history, a minimal reproduction, plain-text logs, and redacted rather than fabricated screenshots — gives anyone reading it enough to either reproduce the problem directly or rule out an environmental cause quickly.
