Editing Issues — Severity, Status, and Priority
The issue detail page is your central hub for everything about a specific bug or problem. This page explains how to update each field and what they mean.
Opening an issue
You can open an issue from:
- Issues list — click the issue title
- Sprint board — click an issue card
- Kanban board — click an issue card
- My Tasks view — if the issue is assigned to you
Issue status
Status tracks where the issue is in the resolution process.
| Status | What it means |
|---|---|
| Open | Filed, not yet being worked on |
| In Progress | Someone is actively investigating or fixing it |
| In Review | Fix submitted, awaiting code review or QA sign-off |
| Resolved | Fix has been applied and verified |
| Won't Fix | Team has decided not to fix it (add a reason in comments) |
| Closed | Fully resolved and confirmed. No further action needed. |
Changing status
- Open the issue.
- Click the Status badge at the top of the detail panel.
- Select the new status from the dropdown.
Status changes are reflected immediately on the Kanban board. When you move an issue to In Progress, it also records the actual start date automatically.
Severity
Severity describes how serious the impact of the bug is on the system or users.
| Severity | Definition |
|---|---|
| Critical | System is down, data loss, security vulnerability — affects all users |
| High | Major feature broken, significant impact, no workaround |
| Medium | Feature partially broken or impaired, workaround exists |
| Low | Minor issue, cosmetic, minimal user impact |
To change severity:
- Open the issue.
- Click the Severity field.
- Select the appropriate level.
Priority
Priority reflects how urgently the issue should be addressed, which may differ from its severity.
| Priority | When to use |
|---|---|
| Critical | Must be fixed immediately, blocking a release or key workflow |
| High | Fix in the current or next sprint |
| Medium | Fix soon, but not blocking |
| Low | Fix when there is time, or backlog |
Description
The description field supports rich text. A good description includes:
- Steps to reproduce the bug
- Expected behavior — what should happen
- Actual behavior — what happens instead
- Environment details — browser, OS, version number
- Screenshots or attachments — add these in the Attachments section
To update the description:
- Click in the Description area.
- Edit the content.
- Changes save automatically.
Assignee
To assign or reassign the issue:
- Click the Assignee field.
- Select a team member.
The new assignee receives an in-app notification.
Unassigned issues appear in a dedicated "Unassigned" section on the Kanban board. Make sure all active sprint issues have an assignee so nothing falls through the cracks.
Planned dates
Planned start and end dates indicate when the fix is scheduled.
- Click Planned start → pick a date.
- Click Planned end → pick a date.
These dates appear on the Gantt chart if the issue is in a sprint.
Tags
Tags let you label and filter issues. Common examples: regression, performance, ui, api, security.
- Click the Tags field.
- Type a tag and press Enter, or select from existing tags.
- Remove a tag by clicking the × next to it.
Linking to an epic
If this issue belongs to a larger theme or feature area:
- Click the Epic field.
- Search for and select an epic.
Comments and activity
Comments work the same way on issues as on tasks. Use the Comments section to discuss the bug, share findings, or coordinate the fix.
The Activity tab shows a full history of all changes — who changed what, and when.
Attachments
You can attach screenshots, log files, videos, or any supporting files to an issue.
See Attachments — the same system is used for both tasks and issues.
Closing vs resolving
- Resolved means the fix has been applied. Use this when a developer has pushed a fix.
- Closed means the fix has been verified and the issue is confirmed fixed. Use this after QA has validated the resolution.
This two-step process ensures issues are not marked closed without verification.