A useful report identifies a repeatable action, expected behavior, actual behavior, and the exact Windows and Open-Shell versions. Search existing issues first and remove private data before sharing configuration or logs.
What to do
- Search the project issue tracker for the symptom and Windows build. Read whether an existing report is open, fixed, or specific to a preview.
- Reproduce with a supplied style and record enabled components and other shell customizations. Explain when the issue does not occur as well as when it does.
- Write numbered steps using a harmless local folder or test shortcut. Add a cropped screenshot only when it explains the mismatch better than text.
- Include logs or an XML configuration only after reviewing paths, commands, user names, and network addresses. State any relevant recent Windows or Open-Shell update.
Check the result
Ask whether another person could follow the report without guessing your setup. Include the exact error message and distinguish a verified observation from your theory about the cause.
Limits & precautions
The public tracker is maintained by the project, not this website. Filing an issue does not guarantee a response or a fix, and credentials must never be included.
Questions & answers
Should I open several issues for the same symptom?
No. Search first and add relevant evidence to an existing matching report when appropriate.
Is “does not work” enough detail?
No. Include the triggering action, result, versions, and minimal reproduction steps.
Sources & scope
Documentation checked October 30, 2026. These instructions are documentation-led, not a claim of hands-on testing on your Windows build.