Thanks for contributing to the discussion Mick. I like the idea of having handy lists for "Triage", "Open", "Patch Available", "Reviewed Once" to give more visibility and transparency to the ticket triaging/review process, but can't we make list maintenance via JIRA Automation [1] instead of requiring manual maintenance?
For example: * "In Progress" (is it still? or should be returned to Open, or closed out) * Ticket has been in progress for more than 6 months? Add tag "stale-in-progress" and a message saying that the ticket will be set to open in 1 month if tag is not removed. * Ticket has tag "stale-in-progress" for more than 1 month? Set state to Open. * "In Review" (should they be returned to 'in progress', or has the reviewer gone MIA and it needs to go back to 'Patch Available') * Ticket has been in review for more than 3 months ? Add tag "stale-in-review" and message saying that the ticket will be set to "patch available" in 1 month if tag is not removed. * Ticket has tag "stale-in-review" for more than 1 month? Set state to Patch Available. In the same spirit, we could have a similar workflow for getting rid of abandoned tasks from the backlog: * Ticket without update for more than 4 years (debatable duration)? Add tag "to-be-abandoned" and message: * "Hey buddy, do you think this task is still important? If so, please remove the tag 'to-be-abadoned', otherwise I will close this ticket in 6 months". * Ticket has "to-be-abandoned" tag for more than 6 months? Close with "Abandoned" state A task that hasn't been updated on for 4-5 years will likely never be worked again, so why should they remain open polluting the backlog? We will give people a grace period of 6 months to "touch" the issue if they want to renew the TTL for 4 more years, which should be sufficient to "save" relevant tickets from the guillotine. And even after they're abandoned they can always be "reopened" if necessary. Does this auto-closing strategy make you less uncomfortable? If not, do you mind elaborating why? I'd also love to hear others opinions on this. +1 to the Github workflow suggestions. [1] - https://www.atlassian.com/software/jira/features/automation Em seg., 22 de mar. de 2021 às 12:33, Mick Semb Wever <m...@apache.org> escreveu: > Throwing my thoughts out there on this. > > > > > A much harder > > objective is to ensure that all "Patch Available" tickets are reviewed > in a > > timely manner. However the current backlog of abandoned PA tickets is > also > > large and we need to clean it to "start fresh" so the auto-close proposal > > would also help here. > > > > > We have this list: > https://cwiki.apache.org/confluence/display/CASSANDRA/Patch+Available > > Post 4.0 it would help with a way to incentivise reviews (by anyone) and a > committer's involvement. > > The list is helpful for jumping in and helping out, but some things missing > that would greatly help the flow of things is… > > - when has the existing reviewer(s) gone MIA and the ticket stale, > - when has one non-committer reviewed it and it is only waiting on a > committer to jump in, > - when it is in action, or intentionally parked, and not needing anyone new > involved, > - when has communication gone stale, or the ticket been left in the wrong > state. > > That is, to have lists like this for > - "Triage" (Needs to be triaged) > - "Open" (Needs to be implemented) > - "Patch Available" (Needs to be reviewed) > - "Reviewed Once" (Needs a second reviewer) > > will help a lot, making it easier for folk to jump in when they have a few > free hours… > > But for each list we also need some project documentation on "list > maintenance". The process for maintaining these lists should be as simple > and standard and repeatable as possible, by anyone (including > non-committers). List maintenance is not about triaging, implementing, or > reviewing, but solely about tackling ticket hygiene. Having it documented > so it's not tribal knowledge and anyone can step in and do it with > confidence would open up the process for more people. Do we have any takers > for creating a skeleton of such documentation? > > I imagine that list maintenance would also include the following lists: > - "In Progress" (is it still? or should be returned to Open, or closed > out) > - "In Review" (should they be returned to 'in progress', or has the > reviewer gone MIA and it needs to go back to 'Patch Available') > > > I agree that auto-closing tickets by itself will not fix the larger issue > > mentioned before, but it's just an initial step to "clean the past" so we > > have an actionable backlog after the 4.0 ticket freeze is over. > > > > I'm not comfortable with automatically closing tickets, or the idea we can > just "start with a clean slate". > But I think we may find automatic reminders/comments on tickets helps make > list maintenance quick and simple. > > While GitHub issues are currently completely disabled from our > repositories, GitHub PRs on the Cassandra repository should be closed if > they don't reference a jira ticket, or if they reference a closed ticket. > > The use of PRs on builds, dtests, and the website, without a corresponding > jira ticket is worth a discussion. I'm in favour of small changes on these > repositories being tackled with just PRs. >
