Not every issue is a problem. Dismissing the ones that are not is a normal part of working through a review — and how you dismiss them matters more than it first appears.
The four reasons
Every dismissal is recorded with one of:
Not applicable — the rule is real, but it does not apply to this condition or this project.
False positive — Pirros got it wrong. This is the one we most want to see, because it tells us where the review is misfiring.
Already addressed — it has been dealt with somewhere the review could not see.
Acknowledged — with notes. The finding is legitimate and you are consciously accepting it. Use the notes to say why.
Why the reason is the point
A dismissal without a reason is indistinguishable from an oversight. Six months later, when someone asks whether a condition was considered, "it was dismissed" is not an answer — "it was dismissed as not applicable, by this person, on this date, because the condition does not occur on this project" is.
This is the difference between a tool that produces findings and a review process you can stand behind. If you run QA/QC for a firm, this is the part that matters to you.
Acknowledged deserves particular care. It is the one that says a real problem was seen and accepted. Write the reasoning into the notes — that is the record someone will rely on later.
Dismissals persist
An issue you dismiss will not be raised again on later runs of the same review.
This is what makes a weekly cadence workable. Without it, every run would re-surface everything you had already ruled out, and nobody would keep using it past the second week.
The exception is a review configured to start fresh with no history — that will re-create previously dismissed issues, by design.
Dismissing repeated issues
A violation occurring in many places is one issue with an instance count, not many separate issues. Dealing with it once deals with the whole group.
Look through the instances before you dismiss, though. The same rule broken in several places is not always broken for the same reason, and occasionally one of them is genuine.
Tell us about false positives
Marking something as a false positive is useful feedback. If you are seeing a pattern of them — the same rule misfiring repeatedly — email [email protected] with an example. That is the fastest route to getting it fixed.
Frequently Asked Questions
Q: What is the difference between dismissing and resolving?
A: Resolving happens automatically when a later run finds you have fixed the problem. Dismissing is you saying it was never a problem to fix — because it doesn't apply, because it's wrong, because it was handled elsewhere, or because you have consciously accepted it.
Q: Will a dismissed issue come back on the next run?
A: No. Dismissals persist across runs of the same review — which is what makes a weekly cadence workable. The one exception is a review configured to start fresh with no history.
Q: Which reason do I use when the finding is right but we're accepting it?
A: Acknowledged, with notes explaining why. That is the one that records a real problem being seen and consciously accepted, and it is the record someone will rely on later.
Q: Does dismissing an issue dismiss all its instances?
A: Yes — a violation occurring in many places is one issue, so dealing with it once deals with the group. Look through the instances first though; occasionally one of them is genuine when the others aren't.
Q: Why does the reason matter if the issue disappears either way?
A: Because a dismissal with no reason is indistinguishable from an oversight when someone reviews the project months later. The reason is what makes the review defensible.
Q: We're getting the same false positive repeatedly. Who should know?
A: We should. Email [email protected] with an example — a rule misfiring in a pattern is the fastest kind of problem for us to fix.