Automatic Backlog Population for bugs flagged as blocking & tracking

[mikeizworkin]

Populating the backlog is currently manual and requires adding u,c, or p tags to the whiteboard field of each bug.

Automatically adding bugs flagged as blocking or tracking to the backlog (i.e. blocking-b2g: tef+ or tracking-b2g18:+) would be really helpful because

• Important bugs will always make it into the backlog and be seen by relevant teams.
• Teams transitioning to scrumbugs will find it easier since their bugs will already be there.
• Less email traffic will be caused by manually setting whiteboards for backlog entry.
• Non-flagged bugs can still be manually tagged if needed.

[pmclanahan]

I'd agree except you need to have those tags (u=, c=, and p=) in order to get any use from scrumbugs' charts, and from scrum itself. They need to have points, and have the user and component of the scrum story. We went with the whiteboard tags because it was going to be necessary regardless. If you don't want or need those pie charts or the burndown, then I'd suggest you may not need scrumbugs at all.

[mikeizworkin]

@pmclanahan, I think you're misunderstanding my goal.

I'm not asking to remove the u, c, and p tags. I see their value and use c= and p= to group and estimate work respectively.

I'm asking you to improve the backlog population process by automatically setting a c= whiteboard value for bugs flagged as blocking or tracking (i.e. blocking-b2g: tef+ or tracking-b2g18:+) since those bugs have been identified as important to fix for a specific time-frame and should definitely be available for sprint planning.

Is there a reason why we can't make this happen?

[pmclanahan]

I know you're not asking for them to be removed. I just don't see the point in adding bugs to the backlog that don't have the tags. You'll have to find and tag them anyway, and a search in bugzilla is a much better place to do that as you can't edit bugs from scrumbugz.

There's no technical reason this can't happen. The main issue is time. I can possibly review a PR that would do this, but it'll be a tough fix because we'll probably want to make this configurable per project so that you could add arbitrary flags to look for. The whole system is based around expecting scrum data in the whiteboard, so if it's not there then I'd expect some strange behavior even if we did get these bugs into the backlog.