coordination #69310
closed[epic] SUSE QA tools team ticket process helpers
100%
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
Updated by okurz almost 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.
Updated by okurz almost 4 years ago
- Due date set to 2020-07-24
due to changes in a related task: #69322
Updated by okurz almost 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.
Updated by szarate almost 4 years ago
- Tracker changed from action to coordination
- Status changed from Blocked to New
Updated by szarate almost 4 years ago
See for the reason of tracker change: http://mailman.suse.de/mailman/private/qa-sle/2020-October/002722.html
Updated by okurz over 3 years ago
- Status changed from New to Blocked
new specific subtask created, waiting for that
Updated by okurz over 3 years ago
- Project changed from openQA Project to QA
- Category deleted (
Organisational)
Updated by okurz about 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
Updated by okurz almost 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
Updated by okurz almost 3 years ago
- Status changed from Workable to Blocked
- Assignee set to okurz
Tracking based on currently defined subtasks
Updated by okurz over 2 years ago
- Status changed from Blocked to New
- Assignee deleted (
okurz) - Target version changed from Ready to future
Updated by okurz over 1 year 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.