Re‐prioritizing issues

Capturing discussion from sprint meeting. More to come one day.

[MD] I would like to make a change to our triage and rescheduling process for issues. If you want to bump an issue to a future phase, I would like you to write a rationale in a comment on the issue and tag product owner. Something like:

I would like to bump this to 18.0. When investigating, I found that the doochonky was not attached to the frumchurker, and trying to link them pulled in a dependency on blabburky. This seems high risk to me. @mcdurdin

Or:

I would like to bump this to next release. I have 273 issues assigned to me for this sprint and while I relish the challenge, I am also aware of my human limitations and expect to only complete 272 of them, so this issue was chosen by its peers to be kicked off the island. @mcdurdin

Reasoning: I have been working through some backlogged issues recently and finding some issues that I considered important were bumped to a future release without understanding why. It's possible that the conversation happened in slack or even in the lunch room at NPIC, but that's not healthy for tracking. So I'd like to make that process clearer.

I understand that this may be a bit more time consuming than just selecting 'Future' but I think it is important. I will also try to do better on documenting my rationales when I triage issues too.

Note: if we are just rescheduling work within the current phase, this is less important. I would consider it worth adding a note if bumping work by more than a month or two, just so when we re-triage we understand the factors impacting our choices. The more we document, the less we have to remember...