**Do not open feature requests.** I just do not have the time.
**Do not open issues because web pages are broken as a result of uMatrix blocking stuff because of your ruleset.** The issue is with your ruleset, not uMatrix.
**The issue tracker is for provable issues only:** You will have to make the case that the issue is really with uMatrix and not something else on your side. To make a case means to provide detailed steps so that anybody can reproduce the issue. Be sure to rule out that the issue is not caused by something specific on your side.
For **support/discussions**, there is [/r/uMatrix](https://www.reddit.com/r/uMatrix/).
Issues opened which are not actual issues with the code will be closed as _invalid_ without further comment.
### Important
1. When you file an issue, your **responsibility** is to provide **ALL** the exact steps needed for me to reproduce an issue.
1. Ideally, never should I have to _guess_ how to reproduce an issue.
- Hence this is why very detailed steps must be very carefully written down **the first time** the issue is filed.
- Never assume an important step is "obvious".
1. Every single step, in order, must be provided, with **ALL** relevant details.
1. Screenshots are nice, but use common sense: I can't cut and paste important text information from screenshots.
- Regarding screenshots: common sense. Too much of a thing can easily end up as noise.
1. Open source quality software comes from contributors carefully **crafting** code: conversely, issues must also be carefully **crafted**.
- In other words: you benefit from the carefully crafted code, return the favor by **carefully** crafting issues/bug reports.
1. If your mindset is that your time is more precious than that of my time, refrain from filing issues.
### DO NOT
- Add noise to issues by adding `:+1:` and other such pointless comments which add no substance.
Issue tracker is read-only for non-prior contributors.
Raymond Hill
7 years ago
GitHub