but can't we make list maintenance via JIRA > Automation [1] instead of requiring manual maintenance? >
In principle i'm +1 to most of the two phase approaches you suggest. The labelling of tickets and warning of a pending close/change is a good approach. And I'm all for automating everything that can be. Though in practice, i'm wondering if the second phase should be done carefully/manually the first couple of times to make sure we're getting it right. I can think of a number of reasons where it might fail and am not confident we'll anticipate everything. And, I don't think the second phase should apply to 'Open Issue', see below. 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? OSS jira is as much a knowledge base as it is the currently active contributor's backlog. Issues like RAMP, EPaxos, Expressive Consistency Levels, shouldn't be closed just because they haven't been touched for 4+ years. Having them open is valid so long as the idea is valid on Cassandra. And folk shouldn't be having to save them twice a year when the jira automation bot runs… The Open Issues list is a way of seeing what Cassandra is potentially capable of, i.e. its possible horizon. These tickets can contain lots of valuable information, even for next-generation ideas that supersede them (which would close them out). And even trivial bugs, so long as they are still true, shouldn't be closed just because they've existed untouched for 4 years. Folk having to crawl through closed tickets to undercover valid ideas, or valid bugs, in our knowledge base doesn't sit right for me.
