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.
