DEV Community: BugIt

Severity is not priority: a practical guide for people who file bugs

BugIt — Sat, 10 Oct 2026 09:52:26 +0000

Most trackers have two fields that look like they mean the same thing: severity and priority. Teams that treat them as one end up arguing in triage about words instead of bugs. Teams that keep them apart move faster, because each field answers a different question and is owned by a different person.

The two questions

Severity: how bad is it when it happens? This is about the bug's effect on the product and its users. The person who found it is usually best placed to judge, because they saw it.

Priority: how soon should we fix it? This is a scheduling decision. It weighs severity against everything else: how many people hit it, whether a release is coming, whether a workaround exists, what else is on the board. It usually belongs to whoever runs triage.

A crash in a settings page almost nobody opens can be high severity and low priority. A typo in the checkout button is low severity and may be top priority the week before a launch. Both are correct.

A severity scale you can actually use

Four levels are enough for most teams. Write down what each means in terms of what a user loses:

Blocker: a core task cannot be done at all, with no workaround. Data loss, a crash on launch, payments failing.
Major: a core task is broken or wrong, but there is a workaround, or it affects a significant group of users.
Minor: something works incorrectly in a way that is annoying but does not stop anyone.
Cosmetic: layout, wording, alignment. Nothing is wrong except how it looks.

Give a reason

A bare "Critical" invites a debate. One sentence of reasoning ends it before it starts:

Major: annual upgrades that use a coupon are charged the full price; customers can still buy monthly.

Now the triager can agree, disagree with a specific point, or adjust priority knowing exactly what you saw.

Common mistakes

Rating by frustration. A bug that took you two hours to pin down is not more severe because it was hard to find. Rate the effect, not the effort.
Rating everything high to get attention. It works once. After that, high ratings from you get discounted.
Leaving severity to the developer. They will set it, but without your view of how it showed up to a user. Give your rating; let them change it.
Mixing in priority words. "Severity: urgent" is a priority statement. Keep the fields separate and both become more useful.

How BugIt helps with this

BugIt is a QA agent that runs inside the AI assistant you already use: GitHub Copilot Chat or Claude in VS Code, or a plain terminal. When it drafts a bug report from what you describe, it suggests a severity from the symptoms and shows its reasons. The decision is yours: keep it, change it, or overrule it. The reasoning goes into the draft, so the triager sees why.

It also fills in the rest of the report the way this guide asks for: steps, expected result and actual result, and it tells you when any of them look thin. Nothing is filed until you have read the draft and typed FILE IT.

The two minute introduction:

Try BugIt

Read the matching article on bugit.dev: Severity vs priority: a bug triage matrix.
Free bug report templates, the manual way to do what BugIt does for you: bugit.dev/templates.
Read the related article on bugit.dev: A bug report template developers will actually read.
See what BugIt does at bugit.dev, or read about it on the Taskivator website: taskivator.com/bugit.
Testers can request a free trial at bugit.dev, in exchange for honest feedback.
One short film per feature on our YouTube channel: @BugItByTaskivator.

Before you file it: how to find the duplicate a newest first list hides

BugIt — Fri, 09 Oct 2026 03:30:20 +0000

Most trackers have the same ghost: the bug that was reported eight months ago, triaged, discussed, half fixed, and then forgotten. Today someone hits it again and files a fresh ticket. Now the context lives in one place and the attention lives in another, and a developer spends an hour rediscovering what the old thread already knew.

Duplicate bugs are rarely laziness. Most testers do search first. The search just fails in predictable ways, and once you know them you can get around most of them.

Why the search misses

The words differ. You call it "checkout total wrong". The original reporter called it "price not updated after plan switch". Same bug, no shared keyword. Tracker search is mostly literal, so two honest descriptions of one problem can sail past each other.

The list is sorted for the wrong question. Search results usually come back newest first, or by the tracker's own relevance score. When you are asking "has anyone seen this before?", the answer is often the oldest matching ticket, and that is exactly the one a short result page cuts off.

The spelling is not the spelling. A product name typed in full width characters by a teammate on a Japanese keyboard, a German word with or without its umlaut, a version number written three ways. Each one splits the history in two.

Closed tickets are out of sight. Many searches default to open issues. A bug that was closed as fixed and has come back is the most useful duplicate of all, because its fix tells you where to look.

A search routine that works

Search by symptom and by area, separately. One query with the visible symptom ("total", "price", "discount"), another with the feature or screen ("billing", "annual plan"). Read both.
Include closed tickets. A regression is a duplicate with a history, and the history is the valuable part.
Sort oldest first at least once. If the bug has existed for a while, the original report is at the bottom of the default view.
Try the other spellings. Product names, error codes, version strings, and any word your team writes in more than one way.
When in doubt, link instead of filing blind. If a ticket looks related but you are not sure, file yours and link the old one. A developer can merge two linked tickets in seconds; finding an unlinked twin later takes much longer.

Judging "is this the same bug?"

A matching title is not enough. Compare three things:

The trigger. Same steps, same condition? "After switching plans" and "after applying a coupon" may be two different bugs with the same symptom.
The environment. A bug reported on last year's build in one browser may not be yours.
The evidence. The same error message or the same stack frame is the strongest signal you will get.

If two of the three match, treat it as a likely duplicate and say why in your comment. That sentence saves the triager from repeating your comparison.

How BugIt helps with this

This is one of the checks we built into BugIt, a QA agent that runs inside the AI assistant you already use: GitHub Copilot Chat or Claude in VS Code, or a plain terminal.

Before you see a draft ticket, BugIt searches your tracker for tickets like yours and ranks them by how likely each one is the same bug, rather than trusting the tracker's own result order. In our own tests the true duplicate was the oldest matching ticket, exactly the one a newest first list cuts off. It searches your title the way you typed it, including full width and half width characters, and it gives you a number for each candidate so you can see how close it thinks the match is.

You make the call. If one of them is your bug, you comment there instead of filing. If none of them is, you carry on, and nothing is filed until you have read the draft and typed FILE IT.

The search goes from your machine straight to your tracker, with your own credentials. Here is the short film on it:

Try BugIt

Read the related article on bugit.dev: Catch duplicate bugs before you file them.
See what BugIt does at bugit.dev, or read about it on the Taskivator website: taskivator.com/bugit.
Testers can request a free trial at bugit.dev, in exchange for honest feedback.
One short film per feature on our YouTube channel: @BugItByTaskivator.

What to paste from a crash log (and what to leave out)

BugIt — Fri, 09 Oct 2026 03:29:42 +0000

"Logs attached." Two words that appear in a great many bug reports, followed by a file of several thousand lines that nobody opens. The log was supposed to be the strongest evidence in the ticket. Instead it became homework.

A developer does not need the whole log. They need the few lines that explain what went wrong, and enough around them to trust those lines. Here is how to find them.

Start from the end, then walk back

Most crashes announce themselves near the bottom. Look for the last exception or error line: the type (NullReferenceException, TypeError, SIGSEGV) and its message. That pair is the headline of your report.

Then read upward until the noise starts. You are looking for:

The exception type and message, exactly as written.
The top stack frames: the first five to ten lines of the trace, which name the function and the file where it failed.
The line it came from in your own code, as opposed to the framework or the runtime.
One or two lines before it: the request, the action or the state change that led there.

That is usually fifteen to thirty lines. Paste those into the ticket as text, inside a code block, and attach the full log as well for anyone who wants to dig.

What to leave out

Repeated warnings that also appear on a healthy run. If the log says it on a healthy run too, it is probably not your bug.
Unrelated subsystems. Heartbeats, cache hits, analytics pings.
Anything private. Logs are where email addresses, session tokens, API keys and customer details collect. Read the lines you paste and remove them first. A bug tracker is often readable by the whole company, and many trackers cannot truly delete an issue.

Say what the log does not show

If the log is truncated, rotated or missing the moment of the crash, say so in the ticket. "The log starts after the crash; the app restarted itself" is useful evidence. A silent gap invites a developer to assume the lines you pasted are the whole story.

Also say where the log came from: which device, which build, which time zone. A timestamp with no zone sends people to the wrong minute.

A small template for the evidence section

Evidence
  Exception: TypeError: Cannot read properties of undefined (reading 'total')
  Top frames:
    at applyDiscount (src/billing/discount.ts:88)
    at recalcCart (src/billing/cart.ts:142)
    at onPlanChange (src/billing/plan.ts:57)
  Before it: user switched plan from monthly to annual with coupon SAVE20
  Full log: attached (app-2026-10-07.log, 4,102 lines; crash at line 3,977)
  Not in the log: the restart that followed

How BugIt helps with this

BugIt is a QA agent that runs inside the AI assistant you already use: GitHub Copilot Chat or Claude in VS Code, or a plain terminal. Paste a crash log into the conversation and BugIt keeps the exception, the message and the top stack frames for the draft ticket, instead of dumping the whole file into it. If a log is too large to scan, it says the log was truncated rather than cutting it silently.

Before filing, it also redacts email addresses, tokens, API keys and similar data from the ticket text. That redaction is pattern based, so read the draft before you approve it. Nothing is filed until you have read the draft and typed FILE IT.

The 30 second film:

Try BugIt

Read the related article on bugit.dev: Reproduce a bug from a log file: a detective's guide.
See what BugIt does at bugit.dev, or read about it on the Taskivator website: taskivator.com/bugit.
Testers can request a free trial at bugit.dev, in exchange for honest feedback.
One short film per feature on our YouTube channel: @BugItByTaskivator.