Project

General

Profile

coordination #69310

[epic] SUSE QA tools team ticket process helpers

Added by cdywan about 1 year ago. Updated 1 day ago.

Status:
Blocked
Priority:
Low
Assignee:
Target version:
Start date:
2020-07-24
Due date:
% Done:

71%

Estimated time:
(Total: 0.00 h)

Description

Motivation

We want to follow the https://progress.opensuse.org/projects/openqav3/wiki#ticket-workflow including https://progress.opensuse.org/projects/qa/wiki#How-we-work-on-our-backlog which define some SLOs for ourselves which are hard and tedious to track as humans but bots would be happy to do that job.

Ideas

  • DONE: Query Redmine via GitLab CI bot to update due date: On GitHub we have bots checking that certain parameters are met, such as stale PRs or conflicts. It would be great to update the Due Date automatically according to tickets that need updates, taking priority into account, which then allow Redmine to send out notifications. As an alternative write comments directly.
  • Remove due-date on resolved tickets again to prevent reminders on still open parents when resolved subtasks have due-dates in the past but all open tasks do not yet have due-dates
  • Have a GHA CI job that fails whenever any target number or SLO is not met, e.g. one check for each query in https://progress.opensuse.org/projects/qa/wiki#Target-numbers-or-guideline-should-be-in-priorities

Subtasks

action #69322: Automatic check for SUSE QA tools WIP-Limit based on ticketsResolvedokurz

action #73468: SUSE QA tools team ticket process helpers: Set due date on tickets in redmine based on SLOsResolvedilausuch

action #81106: test out chat service notifications, e.g. matrix, from github actions size:MFeedbackVANASTASIADIS

action #90441: Only set due date on tickets in progressResolvedokurz

action #90443: Reset due date on tickets when it doesn't apply / only apply due-date when assignee actually works on ticketsRejectedokurz

openQA Project - action #95536: Due dates on blocked tickets should be reset automaticallyNew

openQA Project - action #97580: Automatic check for qa-tools backlog limits in Github ActionsResolvedVANASTASIADIS

History

#1 Updated by okurz about 1 year ago

  • Subject changed from Query Redmine via GitLab CI bot to update due date to [epic] SUSE QA tools team ticket process helpers
  • Description updated (diff)
  • Category set to Organisational
  • Target version set to Ready

thanks for the reminder. For anyone else reading this: This ticket is based on a discussion that cdywan and me had this morning about how to help ourselves better in our workflows.

#2 Updated by okurz about 1 year ago

  • Due date set to 2020-07-24

due to changes in a related task: #69322

#3 Updated by okurz about 1 year ago

  • Status changed from New to Blocked

I have created one specific example in a subtask #69322 that should be easy enough to be implemented and can provide us feedback if this is way we should follow for further work in this direction.

#4 Updated by okurz about 1 year ago

  • Description updated (diff)

The team's WIP-limit is checked based on #69322 . This seems to work out fine so far. Additional checks could be added

#5 Updated by szarate about 1 year ago

  • Tracker changed from action to coordination
  • Status changed from Blocked to New

#7 Updated by okurz 12 months ago

  • Status changed from New to Blocked

new specific subtask created, waiting for that

#8 Updated by okurz 10 months ago

  • Project changed from openQA Project to QA
  • Category deleted (Organisational)

#9 Updated by okurz 5 months ago

  • Status changed from Blocked to New
  • Assignee deleted (okurz)

the one current existing subtask seems to not gain much interest from the time at the current time but I consider the epic in general very important so I am setting back to "New" so that we can refine it and create new, different subtasks

#10 Updated by okurz 3 months ago

  • Description updated (diff)

#11 Updated by okurz 3 months ago

  • Status changed from New to Workable

In the weekly estimation meeting we decided that for an epic it's actually "Workable" because we don't need to estimate the epic itself and the next task is simply to refine and create subtasks

#12 Updated by okurz 1 day ago

  • Status changed from Workable to Blocked
  • Assignee set to okurz

Tracking based on currently defined subtasks

Also available in: Atom PDF