Project

General

Profile

Actions

coordination #69310

closed

[epic] SUSE QA tools team ticket process helpers

Added by livdywan over 4 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
2020-07-24
Due date:
% Done:

100%

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 7 (0 open7 closed)

action #69322: Automatic check for SUSE QA tools WIP-Limit based on ticketsResolvedokurz2020-07-24

Actions
action #73468: SUSE QA tools team ticket process helpers: Set due date on tickets in redmine based on SLOsResolvedilausuch2020-10-17

Actions
action #81106: test out chat service notifications, e.g. matrix, from github actions size:MRejectedokurz2020-12-16

Actions
action #90441: Only set due date on tickets in progressResolvedokurz2020-10-17

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

Actions
openQA Project - action #95536: Due dates on blocked tickets should be reset automaticallyRejectedokurz2021-07-15

Actions
openQA Project - action #97580: Automatic check for qa-tools backlog limits in Github ActionsResolvedVANASTASIADIS2021-08-27

Actions
Actions #1

Updated by okurz over 4 years 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.

Actions #2

Updated by okurz over 4 years ago

  • Due date set to 2020-07-24

due to changes in a related task: #69322

Actions #3

Updated by okurz over 4 years 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.

Actions #4

Updated by okurz about 4 years 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

Actions #5

Updated by szarate about 4 years ago

  • Tracker changed from action to coordination
  • Status changed from Blocked to New
Actions #7

Updated by okurz about 4 years ago

  • Status changed from New to Blocked

new specific subtask created, waiting for that

Actions #8

Updated by okurz almost 4 years ago

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

Updated by okurz over 3 years 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

Actions #10

Updated by okurz over 3 years ago

  • Description updated (diff)
Actions #11

Updated by okurz over 3 years 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

Actions #12

Updated by okurz about 3 years ago

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

Tracking based on currently defined subtasks

Actions #13

Updated by okurz almost 3 years ago

  • Status changed from Blocked to New
  • Assignee deleted (okurz)
  • Target version changed from Ready to future
Actions #14

Updated by okurz almost 2 years ago

  • Status changed from New to Resolved
  • Assignee set to okurz
  • Target version changed from future to Ready

Not sure about the last change I did about one year ago. All subtasks have been closed meanwhile and I am fine with the current state regardless of the state of the two still open ideas.

Actions

Also available in: Atom PDF