Closed BillWagner closed 2 months ago
I like this idea! I have questions:
- How hard would it be to implement?
It feels like about a day or so. 2nd day might be installing the new yml into multiple repos.
- When you say it would "cleanup all open issues", what exactly would it do?
- What would happen to the linked issues in DevOps?
- Do you update their state at all, if so how exactly?
It would do the same update logic SeQuester does now: compare the GH Issue properties with the AzueDevOps settings, then push any changes from GH to SeQuester. In practice, that would likely mean updating the current iteration in AzureDevOps. (Those changes in GH don't trigger a status update on the issue).
- What would happen to the existing DevOps issue link in the GitHub issue? It would still be there. That DevOps issue would be updated.
- What happens to the issues project, or is that left as is?
- Do things get automatically moved to the "Slipped" column?
Nothing changes here. We still manually move "slipped" items in GH. SeQuester looks at which sprint project an issue is a member of, and updates DevOps based on the most recent linked sprint project.
Sounds great, thanks!
I want to combine this change with an update to only move issues into the "slipped" column after the 5th of the month. This month sprint end is the "worst case" scenario for slipping on items that are "in review": Saturday is the 1st, and it's a Monday holiday.
The 5th gives us until Thursday to complete review / merge activities.
This change would address the problem of "slipped" issues at the end of a sprint. Moving an issues to the "slipped" column doesn't update the "last modified" status on an issue. SeQuester doesn't pick up those changes, and slipped issues that aren't rescheduled don't get updated in Azure DevOps.
A related problem is that an item "in review", when updated, gets moved out of the closed sprint into the "future" bucket.
Proposal:
Add a mode to SeQuester that runs on all open issues with the "sequestered" label. That would catch any issues that haven't been updated in a long time, and need to be cleaned up in Azure DevOps. Configure a second job in each repo that runs once a month, around the 7th of the month, to cleanup all open issues.
By only checking open issues, the list of issues to check isn't that long. There's only 64 in the
dotnet/docs
repo now. The bulk job that runs every night looks at both open and closed issues, which numbers more than 1100. That would be expensive.To summarize, after this change:
Associated WorkItem - 304042