Add ability to move bugs to sprints via bugzilla whiteboard. #95
Conversation
| slug=newsprint, | ||
| start_date=sprintdate, | ||
| end_date=sprintdate + timedelta(days=14), | ||
| ) |
There was a problem hiding this comment.
I'm not sure about this. As I read this, this will create new sprints for s= that don't already exist. Part of me thinks it should just go in the backlog. Otherwise every s= typo will create a new sprint and since anyone can fiddle with the s= column in bugzilla, that seems like the worst of the two possibilities (lost in backlog vs. lots of extra sprints).
There was a problem hiding this comment.
Yeah. I could take that out. I thought it'd be cool if and only if the s= value was a valid ISO date. My worry is that if the sprint isn't yet created, then this code will mostly only add it to the ready backlog, and when the sprint is created, it won't automatically flow into it unless the bug is updated again. I could write some post save logic on Sprints that would search for bugs with the slug in their whiteboard and collect them I guess.
I'm just trying to make this thing as useful as possible for the most people. MDN isn't organized enough to use the sprint planning features yet, so they'd rather still be able to manipulate things from bugzilla. I did think about adding a boolean onto Project that you'd have to switch to enable this. Perhaps that would be better?
There was a problem hiding this comment.
FWIW, I think we (MDN, or just me) would be fine if s= didn't auto-create sprints, and was just ignored until/unless a corresponding sprint was created by an admin. Then, once the corresponding sprint is created (eg. s=2012-10-30), start paying attention to them.
One of the things I sorted out in my thinking yesterday is that we've often used tagging bugs for the next sprint as a way to collaboratively pre-load the next planning meeting (or even the one after next, like a GTD "tickler" file). So, if the sprint was created by an admin PM just before that meeting, and then picked up the tagged bugs, we'd be good.
(Seems like rather than being heavily top-down organized, we have a lot of inputs - from writers (ie. sheppy), readers, translators, devs, PM, etc. Helps to capture all those "oh yeah, next sprint we should..." moments with a quick whiteboard tweak by anyone who happens to be in IRC and can update a bug.)
I had also insisted that collaboratively adding bugs to a sprint after it started was important. I still think that, since MDN devs tend to do a few things every sprint that weren't originally planned, and we'd like the end-state of the sprint to reflect what we really did. But, it's less important than the pre-loading notion. (ie. If it's easier to just import sprint-tagged bugs once at sprint creation, I won't cry)
But, if you're doing it for MDN, I don't think either of those two things (pre-loading, post-loading) from whiteboard data really demands sprint auto-creation.
There was a problem hiding this comment.
Ok. That sounds good. So when there's an 's=' tag in the whiteboard, but the sprint doesn't yet exist, the bug will go into the "Ready backlog", so it will be in the short list for planning the next sprint.
There was a problem hiding this comment.
Oh. And if you open the sprint story management page and know there there are some in the ready backlog that have the sprint marked in the WB, you can just shift refresh and they'll move in via magic 💥
Fix issue #89.
@lmorchard r?