Project

General

Profile

Actions

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.

Status:
Rejected
Priority:
Normal
Assignee:
Target version:
Start date:
2020-10-17
Due date:
% Done:

0%

Estimated time:

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"

Related issues 1 (0 open1 closed)

Copied from QA - action #90441: Only set due date on tickets in progressResolvedokurz2020-10-17

Actions
Actions #1

Updated by livdywan over 3 years ago

  • Copied from action #90441: Only set due date on tickets in progress added
Actions #2

Updated by okurz over 3 years ago

  • 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.

Actions #3

Updated by livdywan over 3 years ago

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" 🤔️

Actions #4

Updated by okurz over 3 years ago

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 :)

Actions #5

Updated by livdywan over 3 years ago

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!

Actions #6

Updated by livdywan over 3 years ago

  • Status changed from Feedback to Rejected
Actions #7

Updated by okurz over 3 years ago

  • 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
Actions #8

Updated by livdywan over 3 years ago

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.

Actions #9

Updated by okurz over 3 years ago

  • 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" ;)

Actions

Also available in: Atom PDF