quality/blockerbugs
7
0
Fork 0
Code Issues 32 Pull requests 2 Projects 1 Releases Activity Actions

Fix proposed bugs link reuse #305

Merged
jgroman merged 1 commit from fix/304-proposed-bug-one-link-two-milestones into develop 2026-05-14 07:51:40 +00:00
Conversation 8 Commits 1 Files changed 2 +114 -12
jgroman commented 2026-05-12 11:19:11 +00:00
Owner
Copy link
  • Fix problem with proposed bugs with different milestones of the same release creating two different tickets
  • Add tests covering this usecase

Fixes #304

Assisted-By: Claude Code

- Fix problem with proposed bugs with different milestones of the same release creating two different tickets - Add tests covering this usecase Fixes #304 Assisted-By: Claude Code
jgroman self-assigned this 2026-05-12 11:19:11 +00:00
Fix proposed bugs link reuse
Some checks failed
Run tests and linters / test (pull_request) Successful in 2m47s
Details
Run tests and linters / lint (pull_request) Failing after 2s
Details
AI Code Review / ai-review (pull_request_target) Successful in 24s
Details
e0361d76da 
- Fix problem with proposed bugs with different milestones of the same release creating two different tickets
- Add tests covering this usecase

Fixes #304

Assisted-By: Claude Code
jgroman changed title from WIP: Fix proposed bugs link reuse to Fix proposed bugs link reuse 2026-05-12 11:32:58 +00:00
forgejo-actions commented 2026-05-12 11:33:33 +00:00
Copy link

AI Code Review

📋 MR Summary

Fixes an issue where duplicate discussion tickets were created for the same proposed bug across different milestones within the same release.

  • Key Changes:
    • Added logic to create_discussions_links to check for existing discussion links for the same bugs in other milestones of the same release.
    • Populates the links_to_reuse dictionary with existing links to prevent duplicate ticket creation.
    • Added unit tests to verify that discussion links are reused when a bug is proposed for a second milestone.
  • Impact: blockerbugs/util/discussion_sync.py, testing/test_discussion_sync.py
  • Risk Level: 🟢 Low - The changes only affect metadata synchronization with Forgejo and include proper test coverage. The primary risk is a potential performance bottleneck if processing large batches of bugs.

Detailed Code Review

The implementation correctly solves the duplicate discussion ticket issue by looking up pre-existing links for the same bug ID in the release. The logic is sound and the included test coverage is excellent, verifying the fix accurately. However, the database query introduced in the loop creates an N+1 query pattern, which could cause performance degradation when processing many bugs at once.

📂 File Reviews

📄 `blockerbugs/util/discussion_sync.py` - Updated logic to query the database for existing discussion links if a pre-built cache is not provided.
  • Major [Performance]: The current implementation performs a separate database query for each bug in the bugs list, leading to an N+1 query problem. When processing a large batch of bugs, this will significantly impact database performance. The query should be refactored to fetch all existing links in a single batch query.
    • Suggestion: Extract the bug IDs and use in_() to perform a single query.
        links_to_reuse = {}
        bug_ids = [bug.bugid for bug in bugs]
        current_ids = [bug.id for bug in bugs if bug.id is not None]
        
        if bug_ids:
            existing_bugs = Bug.query.filter(
                Bug.bugid.in_(bug_ids),
                Bug.discussion_link.isnot(None),
                Bug.id.notin_(current_ids) if current_ids else True,
                Bug.milestone.has(release_id=milestone.release_id)
            ).all()
            
            for existing in existing_bugs:
                links_to_reuse[_link_key(milestone, existing)] = existing.discussion_link

✅ Summary

  • Overall Assessment: The logic is correct and the bug is successfully resolved, but a performance issue related to database queries needs to be addressed before merging.
  • Priority Issues:
    • Resolve the N+1 query issue in create_discussions_links to prevent performance degradation during batch processing.

🤖 AI Code Review | Generated with ai-code-review | Model: gemini-3.1-pro-preview

⚠️ AI-generated suggestions may be incorrect. Verify before applying. Not a replacement for human review.

## AI Code Review ### 📋 MR Summary Fixes an issue where duplicate discussion tickets were created for the same proposed bug across different milestones within the same release. - **Key Changes:** - Added logic to `create_discussions_links` to check for existing discussion links for the same bugs in other milestones of the same release. - Populates the `links_to_reuse` dictionary with existing links to prevent duplicate ticket creation. - Added unit tests to verify that discussion links are reused when a bug is proposed for a second milestone. - **Impact:** blockerbugs/util/discussion_sync.py, testing/test_discussion_sync.py - **Risk Level:** 🟢 Low - The changes only affect metadata synchronization with Forgejo and include proper test coverage. The primary risk is a potential performance bottleneck if processing large batches of bugs. ### Detailed Code Review The implementation correctly solves the duplicate discussion ticket issue by looking up pre-existing links for the same bug ID in the release. The logic is sound and the included test coverage is excellent, verifying the fix accurately. However, the database query introduced in the loop creates an N+1 query pattern, which could cause performance degradation when processing many bugs at once. #### 📂 File Reviews <details> <summary><strong>📄 `blockerbugs/util/discussion_sync.py`</strong> - Updated logic to query the database for existing discussion links if a pre-built cache is not provided.</summary> - **Major** [Performance]: The current implementation performs a separate database query for each bug in the `bugs` list, leading to an N+1 query problem. When processing a large batch of bugs, this will significantly impact database performance. The query should be refactored to fetch all existing links in a single batch query. - *Suggestion:* Extract the bug IDs and use `in_()` to perform a single query. ```` links_to_reuse = {} bug_ids = [bug.bugid for bug in bugs] current_ids = [bug.id for bug in bugs if bug.id is not None] if bug_ids: existing_bugs = Bug.query.filter( Bug.bugid.in_(bug_ids), Bug.discussion_link.isnot(None), Bug.id.notin_(current_ids) if current_ids else True, Bug.milestone.has(release_id=milestone.release_id) ).all() for existing in existing_bugs: links_to_reuse[_link_key(milestone, existing)] = existing.discussion_link ```` </details> ### ✅ Summary - **Overall Assessment:** The logic is correct and the bug is successfully resolved, but a performance issue related to database queries needs to be addressed before merging. - **Priority Issues:** - Resolve the N+1 query issue in `create_discussions_links` to prevent performance degradation during batch processing. --- 🤖 **AI Code Review** | Generated with [ai-code-review](https://gitlab.com/redhat/edge/ci-cd/ai-code-review) | **Model:** `gemini-3.1-pro-preview` ⚠️ *AI-generated suggestions may be incorrect. Verify before applying. Not a replacement for human review.*
jgroman changed title from Fix proposed bugs link reuse to WIP: Fix proposed bugs link reuse 2026-05-12 11:38:48 +00:00
Use batch bug query
Some checks failed
Run tests and linters / test (pull_request) Successful in 2m42s
Details
Run tests and linters / lint (pull_request) Failing after 2s
Details
AI Code Review / ai-review (pull_request_target) Successful in 31s
Details
8afe1f78f6
jgroman changed title from WIP: Fix proposed bugs link reuse to Fix proposed bugs link reuse 2026-05-12 11:57:09 +00:00
forgejo-actions commented 2026-05-12 11:57:47 +00:00
Copy link

AI Code Review

📋 MR Summary

Fixes an issue where duplicate Forgejo discussion tickets were created for the same bug when proposed across different milestones within the same release.

  • Key Changes:
    • Added logic to create_discussions_links to query the database for existing discussion links for the given bugs within the same release.
    • Ensured existing ticket URLs are populated in the cache so subsequent logic reuses them rather than calling the Forgejo API.
    • Added a comprehensive test suite TestProposalReusesDiscussionLink to verify discussion ticket reuse across milestones.
  • Impact: blockerbugs/util/discussion_sync.py, testing/test_discussion_sync.py
  • Risk Level: 🟢 Low - The changes only modify internal link-caching behavior before creating Forgejo tickets. The database queries use batching to avoid N+1 issues and securely use parameterized ORM queries.

Detailed Code Review

The implementation cleanly addresses the duplicate ticket issue while maintaining excellent performance via batch querying. By pre-filling the links_to_reuse dictionary dynamically using the Bug.bugid.in_() clause, you successfully prevented redundant API calls to Forgejo and maintained proper synchronization across milestones. The addition of targeted test coverage using mocks correctly simulates and proves the expected behavior.

✅ Summary

  • Overall Assessment: The code changes are well-implemented, performant, and correctly tested. No bugs or security risks were identified.

🤖 AI Code Review | Generated with ai-code-review | Model: gemini-3.1-pro-preview

⚠️ AI-generated suggestions may be incorrect. Verify before applying. Not a replacement for human review.

## AI Code Review ### 📋 MR Summary Fixes an issue where duplicate Forgejo discussion tickets were created for the same bug when proposed across different milestones within the same release. - **Key Changes:** - Added logic to `create_discussions_links` to query the database for existing discussion links for the given bugs within the same release. - Ensured existing ticket URLs are populated in the cache so subsequent logic reuses them rather than calling the Forgejo API. - Added a comprehensive test suite `TestProposalReusesDiscussionLink` to verify discussion ticket reuse across milestones. - **Impact:** blockerbugs/util/discussion_sync.py, testing/test_discussion_sync.py - **Risk Level:** 🟢 Low - The changes only modify internal link-caching behavior before creating Forgejo tickets. The database queries use batching to avoid N+1 issues and securely use parameterized ORM queries. ### Detailed Code Review The implementation cleanly addresses the duplicate ticket issue while maintaining excellent performance via batch querying. By pre-filling the `links_to_reuse` dictionary dynamically using the `Bug.bugid.in_()` clause, you successfully prevented redundant API calls to Forgejo and maintained proper synchronization across milestones. The addition of targeted test coverage using mocks correctly simulates and proves the expected behavior. ### ✅ Summary - **Overall Assessment:** The code changes are well-implemented, performant, and correctly tested. No bugs or security risks were identified. --- 🤖 **AI Code Review** | Generated with [ai-code-review](https://gitlab.com/redhat/edge/ci-cd/ai-code-review) | **Model:** `gemini-3.1-pro-preview` ⚠️ *AI-generated suggestions may be incorrect. Verify before applying. Not a replacement for human review.*
jgroman changed title from Fix proposed bugs link reuse to WIP: Fix proposed bugs link reuse 2026-05-12 12:00:44 +00:00
adamwill commented 2026-05-12 16:19:37 +00:00
Owner
Copy link

I'm not sure this is quite the right approach.

We have three paths that call create_discussions_links. As I read it, the main, original one is sync_discussions(), which passes in a correct links_to_reuse cache. The other two were, I think, added later.

The one we're trying to "fix" here is bugzilla_sync_proposal in main.py. This was added in 38ac5941a3 (then reverted in d56e8bbdf7 because it caused another duplication issue, then reapplied in f699d81f5f with the duplication issue fixed in 06bfb4e060) to make it so proposals through the app took effect immediately rather than waiting for the next sync. The bug here is in that specific path; we don't build a links_to_reuse cache on that path, so we don't spot if there's an existing discussion and reuse it.

This would "fix" that by always creating a cache in create_discussions_links, but...I think that would break the third path, which is in recreate_discussion in discussion_sync.py. That function is specifically intended to recreate discussions, per the name. It does not want to reuse existing ones. So it doesn't pass in a links_to_reuse cache on purpose.

I guess there's two ways we can deal with this: we can either change approach to just building a links_to_reuse cache in bugzilla_sync_proposal, or we can make it so that if you pass links_to_reuse=False (instead of None) then we won't build the cache in create_discussions_links.

I'm not sure this is quite the right approach. We have three paths that call `create_discussions_links`. As I read it, the main, original one is `sync_discussions()`, which passes in a correct `links_to_reuse` cache. The other two were, I think, added later. The one we're trying to "fix" here is `bugzilla_sync_proposal` in `main.py`. This was added in 38ac5941a3a35cda86d83db59dbe4d197126f4f9 (then reverted in d56e8bbdf7b6b773295d0ccc5da7a1b4e83766e2 because it caused another duplication issue, then reapplied in f699d81f5f3c1e50314c7016087de55fc7ef0e34 with the duplication issue fixed in 06bfb4e060ca7196a836c85ce52900bf2560c468) to make it so proposals through the app took effect immediately rather than waiting for the next sync. The bug here is in that specific path; we don't build a `links_to_reuse` cache on that path, so we don't spot if there's an existing discussion and reuse it. This would "fix" that by always creating a cache in `create_discussions_links`, but...I think that would *break* the *third* path, which is in `recreate_discussion` in `discussion_sync.py`. That function is specifically intended to *re*create discussions, per the name. It does not *want* to reuse existing ones. So it doesn't pass in a `links_to_reuse` cache *on purpose*. I guess there's two ways we can deal with this: we can either change approach to just building a `links_to_reuse` cache in `bugzilla_sync_proposal`, or we can make it so that if you pass `links_to_reuse=False` (instead of `None`) then we won't build the cache in `create_discussions_links`.
adamwill requested changes 2026-05-12 16:27:36 +00:00
blockerbugs/util/discussion_sync.py Outdated
@ -77,0 +80,4 @@
# discussion ticket across the whole release (e.g. Beta + Final).
links_to_reuse = {}
bug_ids = [bug.bugid for bug in bugs]
current_ids = [bug.id for bug in bugs if bug.id is not None]
adamwill commented 2026-05-12 16:04:02 +00:00
Owner
Copy link

the naming here makes it very hard to understand what's going on, plus it just feels weird. How would bug.id ever be None? I don't think it can be, per its definition:

    id: db.Mapped[int] = db.mapped_column(primary_key=True)

So...I think this should maybe be something like:

our_bugzilla_ids = [bug.bugid for bug in bugs]
our_db_ids = [bug.id for bug in bugs]

I don't love the our_db_ids, but, you know...something that clearly distinguishes between the two "id" concepts going on here, and makes it more obvious that what we're doing here is just excluding the Bug instances that we're explicitly operating on from the query results.

the naming here makes it very hard to understand what's going on, plus it just feels weird. How would `bug.id` ever be `None`? I don't think it can be, per its definition: ``` id: db.Mapped[int] = db.mapped_column(primary_key=True) ``` So...I think this should maybe be something like: ``` our_bugzilla_ids = [bug.bugid for bug in bugs] our_db_ids = [bug.id for bug in bugs] ``` I don't love the `our_db_ids`, but, you know...something that clearly distinguishes between the two "id" concepts going on here, and makes it more obvious that what we're doing here is just excluding the `Bug` instances that we're explicitly operating on from the query results.
jgroman marked this conversation as resolved
blockerbugs/util/discussion_sync.py Outdated
@ -77,0 +82,4 @@
bug_ids = [bug.bugid for bug in bugs]
current_ids = [bug.id for bug in bugs if bug.id is not None]
if bug_ids:
adamwill commented 2026-05-12 16:10:05 +00:00
Owner
Copy link

we could probably avoid this and the if current_ids: later by just adding an early bail-out if the bugs list is empty?

we could probably avoid this and the `if current_ids:` later by just adding an early bail-out if the `bugs` list is empty?
jgroman marked this conversation as resolved
blockerbugs/util/discussion_sync.py Outdated
@ -77,0 +83,4 @@
current_ids = [bug.id for bug in bugs if bug.id is not None]
if bug_ids:
query = Bug.query.filter(
adamwill commented 2026-05-12 16:27:09 +00:00
Owner
Copy link

Maybe add a comment here which just clarifies exactly what we're doing: searching for db Bugs that have the same bugzilla ID as the one(s) we were called on, but are not the one(s) we were called on.

Maybe add a comment here which just clarifies exactly what we're doing: searching for db `Bug`s that have the same bugzilla ID as the one(s) we were called on, but are *not* the one(s) we were called on.
jgroman marked this conversation as resolved
Fix linter warnings in create_discussion_links()
Some checks failed
Run tests and linters / test (pull_request) Successful in 2m48s
Details
Run tests and linters / lint (pull_request) Failing after 2s
Details
AI Code Review / ai-review (pull_request_target) Successful in 40s
Details
f922852b42
jgroman commented 2026-05-13 08:43:12 +00:00
Author
Owner
Copy link

@adamwill wrote in #305 (comment):

This would "fix" that by always creating a cache in create_discussions_links, but...I think that would break the third path, which is in recreate_discussion in discussion_sync.py. That function is specifically intended to _re_create discussions, per the name. It does not want to reuse existing ones. So it doesn't pass in a links_to_reuse cache on purpose.

I guess there's two ways we can deal with this: we can either change approach to just building a links_to_reuse cache in bugzilla_sync_proposal, or we can make it so that if you pass links_to_reuse=False (instead of None) then we won't build the cache in create_discussions_links.

Thanks! I was not aware of this. Modified create_discussions_link so that links_to_reuse=None would trigger cache rebuild and if any dict is passed instead it would be left untouched.

@adamwill wrote in https://forge.fedoraproject.org/quality/blockerbugs/pulls/305#issuecomment-710545: > This would "fix" that by always creating a cache in `create_discussions_links`, but...I think that would _break_ the _third_ path, which is in `recreate_discussion` in `discussion_sync.py`. That function is specifically intended to _re_create discussions, per the name. It does not _want_ to reuse existing ones. So it doesn't pass in a `links_to_reuse` cache _on purpose_. > > I guess there's two ways we can deal with this: we can either change approach to just building a `links_to_reuse` cache in `bugzilla_sync_proposal`, or we can make it so that if you pass `links_to_reuse=False` (instead of `None`) then we won't build the cache in `create_discussions_links`. Thanks! I was not aware of this. Modified `create_discussions_link` so that `links_to_reuse=None` would trigger cache rebuild and if any dict is passed instead it would be left untouched.
jgroman changed title from WIP: Fix proposed bugs link reuse to Fix proposed bugs link reuse 2026-05-13 08:43:20 +00:00
forgejo-actions commented 2026-05-13 08:44:06 +00:00
Copy link

AI Code Review

📋 MR Summary

Fixes duplicate Forgejo discussion ticket creation for proposed bugs spanning multiple milestones of the same release.

  • Key Changes:
    • Added automatic lookup for existing discussion links of bugs with the same Bugzilla ID in the same release.
    • Utilized a single batch query for better performance instead of N+1 individual lookups.
    • Updated recreate_discussion to pass an empty dict to skip link reuse explicitly.
    • Fixed linter warnings by converting string interpolation to comma-separated arguments in logger calls.
  • Impact: blockerbugs/util/discussion_sync.py, testing/test_discussion_sync.py
  • Risk Level: 🟢 Low - The changes introduce a non-destructive lookup to reuse URLs and explicitly preserve previous behavior for recreate_discussion. The logic is isolated and backed by newly added tests.

Detailed Code Review

The implementation correctly aligns with previous review consensus. The batch lookup strategy efficiently mitigates the duplicate ticket issue without introducing an N+1 query problem. The distinction between links_to_reuse=None (automatic lookup) and links_to_reuse={} (forced new link) safely preserves the isolated operational intent of the recreate_discussion pipeline. Linter fixes applied to standard logging inputs are also well executed.

✅ Summary

  • Overall Assessment: Code review complete. The implementation correctly addresses the duplicate ticket bug while preserving existing functionality in alternate flows. Test coverage is appropriate and effectively validates the new logic.

🤖 AI Code Review | Generated with ai-code-review | Model: gemini-3.1-pro-preview

⚠️ AI-generated suggestions may be incorrect. Verify before applying. Not a replacement for human review.

## AI Code Review ### 📋 MR Summary Fixes duplicate Forgejo discussion ticket creation for proposed bugs spanning multiple milestones of the same release. - **Key Changes:** - Added automatic lookup for existing discussion links of bugs with the same Bugzilla ID in the same release. - Utilized a single batch query for better performance instead of N+1 individual lookups. - Updated `recreate_discussion` to pass an empty dict to skip link reuse explicitly. - Fixed linter warnings by converting string interpolation to comma-separated arguments in logger calls. - **Impact:** blockerbugs/util/discussion_sync.py, testing/test_discussion_sync.py - **Risk Level:** 🟢 Low - The changes introduce a non-destructive lookup to reuse URLs and explicitly preserve previous behavior for `recreate_discussion`. The logic is isolated and backed by newly added tests. ### Detailed Code Review The implementation correctly aligns with previous review consensus. The batch lookup strategy efficiently mitigates the duplicate ticket issue without introducing an N+1 query problem. The distinction between `links_to_reuse=None` (automatic lookup) and `links_to_reuse={}` (forced new link) safely preserves the isolated operational intent of the `recreate_discussion` pipeline. Linter fixes applied to standard logging inputs are also well executed. ### ✅ Summary - **Overall Assessment:** Code review complete. The implementation correctly addresses the duplicate ticket bug while preserving existing functionality in alternate flows. Test coverage is appropriate and effectively validates the new logic. --- 🤖 **AI Code Review** | Generated with [ai-code-review](https://gitlab.com/redhat/edge/ci-cd/ai-code-review) | **Model:** `gemini-3.1-pro-preview` ⚠️ *AI-generated suggestions may be incorrect. Verify before applying. Not a replacement for human review.*
jgroman changed title from Fix proposed bugs link reuse to WIP: Fix proposed bugs link reuse 2026-05-13 08:44:31 +00:00
jgroman changed title from WIP: Fix proposed bugs link reuse to Fix proposed bugs link reuse 2026-05-13 13:34:50 +00:00
adamwill commented 2026-05-13 15:40:28 +00:00
Owner
Copy link

OK, LGTM now. Thanks. Please squash appropriately and merge.

We should really do a lint cleanup next, though.

OK, LGTM now. Thanks. Please squash appropriately and merge. We should really do a lint cleanup next, though.
👍 1
jgroman commented 2026-05-14 07:12:05 +00:00
Author
Owner
Copy link

Thank you!

Created #306 to do the linter cleanup.

Thank you! Created #306 to do the linter cleanup.
jgroman force-pushed fix/304-proposed-bug-one-link-two-milestones from f922852b42
Some checks failed
Run tests and linters / test (pull_request) Successful in 2m48s
Details
Run tests and linters / lint (pull_request) Failing after 2s
Details
AI Code Review / ai-review (pull_request_target) Successful in 40s
Details
to d009979c45
Some checks failed
Run tests and linters / test (pull_request) Successful in 3m35s
Details
Run tests and linters / lint (pull_request) Failing after 2s
Details
2026-05-14 07:46:22 +00:00 Compare
jgroman merged commit d009979c45 into develop 2026-05-14 07:51:40 +00:00
jgroman deleted branch fix/304-proposed-bug-one-link-two-milestones 2026-05-14 07:51:41 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
adamwill
Labels
Clear labels   
Closed As
Duplicate
 Closed with the reason of Duplicate

  
Closed As
Fixed
 Closed with the reason of Fixed

  
Closed As
Invalid
 Closed with the reason of Invalid

  
discussions
issues related to the blocker discussion system in pagure

  
easyfix

   
enhancement
a request for or implementation of an enhancement (not a bug fix)

  
task
issue that isn't a bug fix or enhancement but some kind of admin task

  
ai-review-please
Request AI review for a pull request

  
Backlog Status
Needs Review
 Work items that have been created or updated but need review, refinement, or approval before they can be considered ready for sprint planning.

  
Backlog Status
Ready
 Work items that have been reviewed, refined, and are ready to be committed to a sprint. These items have clear requirements and can be worked on immediately when capacity is available.

  
chore
Work that needs to be done but doesn't add new functionality or fix bugs. Maintenance tasks that keep the system running smoothly and the codebase clean.

  
documentation
Work focused on creating, updating, or improving documentation for users, developers, or system administrators.

  
points
01
 A task that is simple, small, and has very little uncertainty. It should be easy enough for any team member to pick up and complete quickly, without a lot of discussion or research.

  
points
02
 This is a task that is slightly more complex or larger than a "1." It might involve two or three simple steps, but the outcome is still very clear and there's little uncertainty.

  
points
03
 Medium-sized task with some noticeable complexity. It might require a bit more thought or collaboration. The steps are well-defined, but it's not a trivial change.

  
points
05
 A significant piece of work. It has more complexity and a higher degree of uncertainty than smaller tasks. It might require some research, a design discussion, or collaboration across multiple teams.

  
points
08
 Complex task with a lot of uncertainty. It's often the largest size that a team will consider for a single sprint. It likely requires a detailed breakdown and multiple team members to complete.

  
points
13
 Any task that feels like it's a "13" or more is considered an Epic. These are too large and uncertain to be worked on in a single sprint and should be broken down.

  
pr2jira
Sync this pull request to Jira for Agility tracking. Only use for PRs without a corresponding ticket.

  
Priority
Critical
 This is for work that is urgent and of critical importance and so and must be addressed immediately with a higher priority than all other work, even if not originally planned for the current sprint.

  
Priority
High
 This is for work that is critical and needs to be addressed in the next sprint. It's often for urgent bugs, important features, or a major piece of technical debt that is blocking other work.

  
Priority
Low
 This is for work that is good to do but not urgent. It's a candidate for being worked on when there's extra time or when it rises in importance. It can stay in the backlog for a longer period.

  
Priority
Medium
 This is for important work that should be done soon, but isn't as urgent as a high-priority item. It will likely be considered for the next 1-2 sprints.

  
Sprint Status
Blocked
 Work items that cannot progress due to external dependencies, blockers, or issues that need resolution.

  
Sprint Status
Done
 Work items that have been completed, reviewed, and integrated. No further work is needed within the current sprint.

  
Sprint Status
In Progress
 Work items currently being worked on by a team member. Active development, research, or implementation is happening.

  
Sprint Status
Review
 Work items that are complete but need review, testing, or approval before being marked as done.

  
Sprint Status
To Do
 Work items that are committed to the sprint but haven't been started yet. These items are ready to be picked up by team members.

  
Technical Debt
Work that addresses shortcuts, workarounds, or suboptimal implementations that were done previously to meet deadlines. These items improve code quality, maintainability, or performance without adding new features.

  
Work Item
Bug
 Issues where the system is not working as intended or designed. Bugs represent deviations from expected behavior.

  
Work Item
Epic
 Large initiatives that are broken down into multiple smaller work items (user stories, tasks, bugs). Epics represent significant features or projects that span multiple sprints.

  
Work Item
Spike
 Time-boxed research, investigation, or proof-of-concept work to reduce uncertainty or explore solutions. Spikes help inform future development decisions.

  
Work Item
Task
 Used to break down larger user stories into smaller, manageable implementation pieces. They focus on the specific technical steps needed to deliver the user story's value.

  
Work Item
User Story
 User-facing features or functionality that can be framed from a user perspective, describing what someone wants to accomplish and why.

No labels
Closed As
Duplicate
Closed As
Fixed
Closed As
Invalid
discussions
easyfix
enhancement
task
ai-review-please
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
pr2jira
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
jgroman
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
#304 Proposing a bug for two milestones from BBA creates two separate discussion links
quality/blockerbugs
Reference
quality/blockerbugs!305
No description provided.