action #90443
closed
coordination #69310: [epic] SUSE QA tools team ticket process helpers
Reset due date on tickets when it doesn't apply / only apply due-date when assignee actually works on tickets
Added by livdywan over 3 years ago.
Updated over 3 years ago.
Description
Motivation¶
One of the reasons I need to reset due dates is that the due date is set automatically but because of for example #90441 it's not very useful. In general I'd like to avoid undoing any automatic due dates. If a script knows it can set the due date, we can also conclude when it can reset the due date.
Acceptance criteria¶
- AC1: due dates in progress tickets are reset when conditions don't apply e.g. set to blocked, unassigned
Suggestions¶
- Get familiar with backlog-set-due-date
- Add another code path to reset due dates when conditions don't apply
- Maybe add a message why the date was reset, like a human would, like "Resetting the due date because nobody actively works on it"
- Copied from action #90441: Only set due date on tickets in progress added
- Status changed from New to Feedback
- Assignee set to okurz
- Target version set to Ready
I would prefer to make "removing due-date" the exception and an explicit decision. The general expectation should be that whenever anyone from the team picks a ticket up for actual development (at least "Workable") then we expect the ticket to be resolved within our usual cycle time, everything else should be seen as exception and if possible avoided in the future.
okurz wrote:
I would prefer to make "removing due-date" the exception and an explicit decision. The general expectation should be that whenever anyone from the team picks a ticket up for actual development (at least "Workable") then we expect the ticket to be resolved within our usual cycle time, everything else should be seen as exception and if possible avoided in the future.
So what does it mean to you in practice when a ticket is assigned, Workable and two weeks passed? To me it usually means there was no "actual development" 🤔️
oops, sorry. Missed your message.
So what does it mean to you in practice when a ticket is assigned, Workable and two weeks passed? To me it usually means there was no "actual development" 🤔️
That means that we as a time failed to detect that issue way before the due date has passed. I suggest the following as best practice for an agile team: As soon as we decide we work on tickets, i.e. when any member of the team picks up a ticket, we as a team should ensure that the ticket is solved within the due-date, e.g. assignee tells about the progress on every daily, that's 10x (14 days - weekend). And when that assignee does not tell about the status then the SM becomes suspicious and asks :) And if all of that fails when the due-date has passed we handle that in a weekly as "escalation", e.g. unassign, a different person picks up, we solve it in a mob in a day :)
okurz wrote:
That means that we as a time failed to detect that issue way before the due date has passed. I suggest the following as best practice for an agile team: As soon as we decide we work on tickets, i.e. when any member of the team picks up a ticket, we as a team should ensure that the ticket is solved within the due-date, e.g. assignee tells about the progress on every daily, that's 10x (14 days - weekend). And when that assignee does not tell about the status then the SM becomes suspicious and asks :) And if all of that fails when the due-date has passed we handle that in a weekly as "escalation", e.g. unassign, a different person picks up, we solve it in a mob in a day :)
I suppose you regard the assignment as a firm commitment to do the work. And equivalent to taking a ticket and working on it right away, in terms of cycle time.
Let's try that then. Thank you for clarifying!
- Status changed from Feedback to Rejected
- Subject changed from Reset due date on tickets when it doesn't apply to Reset due date on tickets when it doesn't apply / only apply due-date when assignee actually works on tickets
- Status changed from Rejected to Feedback
hm, one idea comes to mind: So far we seem to treat "assigned+Workable" same as "assigned+In Progress". Maybe the above could exactly be the distinction which we could also handle accordingly in https://github.com/os-autoinst/scripts/blob/master/backlog-set-due-date#L22 . I still think in case a due date has been set we should not remove it but how about the following:
- "assigned": person commits to ensuring that the ticket will be resolved (commitment on time-based SLOs but as work has not started not cycle time, only reaction time and overall lead-time)
- "In Progress": team commits to finish within cycle time -> bot applies due date for cycle time limit
okurz wrote:
hm, one idea comes to mind: So far we seem to treat "assigned+Workable" same as "assigned+In Progress". Maybe the above could exactly be the distinction which we could also handle accordingly in https://github.com/os-autoinst/scripts/blob/master/backlog-set-due-date#L22 . I still think in case a due date has been set we should not remove it but how about the following:
- "assigned": person commits to ensuring that the ticket will be resolved (commitment on time-based SLOs but as work has not started not cycle time, only reaction time and overall lead-time)
- "In Progress": team commits to finish within cycle time -> bot applies due date for cycle time limit
Well that's what #90441 is about. This ticket is explicitly about undoing a due date that no longer applies.
- Status changed from Feedback to Rejected
cdywan wrote:
okurz wrote:
hm, one idea comes to mind: So far we seem to treat "assigned+Workable" same as "assigned+In Progress". Maybe the above could exactly be the distinction which we could also handle accordingly in https://github.com/os-autoinst/scripts/blob/master/backlog-set-due-date#L22 . I still think in case a due date has been set we should not remove it but how about the following:
- "assigned": person commits to ensuring that the ticket will be resolved (commitment on time-based SLOs but as work has not started not cycle time, only reaction time and overall lead-time)
- "In Progress": team commits to finish within cycle time -> bot applies due date for cycle time limit
Well that's what #90441 is about. This ticket is explicitly about undoing a due date that no longer applies.
oh, I was not aware of that ticket. Then we are actually done here, right. The reason why I did not see #90441 anymore is because for triaging we only look at "openQA" and subprojects. Maybe we should extend to "QA and subprojects but not suseqa and not openqa tests" ;)
Also available in: Atom
PDF