> 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.
Yeah I think it makes sense to start with a manual second phase to build confidence in the automation, evaluate and then automatize it if it works as expected. If there are no objections I will draft a more concrete proposal for this automation to validate with the community. > 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… 100% agree, my intent here is not to close tickets that have been inactive in 5 years that are still relevant, but rather to have a consistent workflow to prune old tickets from the backlog that are no longer valid or relevant. The originally proposed approach was "opt-out", that is, inactive tickets not "touched" within 6 months would be auto-closed, but this is risky as we could auto-close potentially relevant tickets. How about having an "opt-in" approach instead, where tickets inactive for 5 years would be tagged with "needs-retriage" and added to a new "Needs retriage" list? This would allow volunteers to go to this list to retriage and manually close old tickets according to a well defined and documented procedure. We could have a "no-retriage-neeeded" tag to skip retriaging for "blue sky ideas" like RAMP, EPaxos, Expressive Consistency Levels. I did a quick manual dry-run of this approach on tickets older than 5 years [1] (available here [2]), and around 50% of the tickets can be closed on the sample I used. What do you think about this alternative proposal? [1] https://www.google.com/url?q=https://issues.apache.org/jira/browse/CASSANDRA-11407?jql%3Dproject%2520%253D%2520cassandra%2520AND%2520resolution%2520%253D%2520unresolved%2520AND%2520created%2520%253C%2520%25222016-03-23%2522%2520ORDER%2520BY%2520created%2520DESC&sa=D&source=editors&ust=1616550373374000&usg=AFQjCNFsDx1IkQZREC4vLjFG35np5Vqqag [2] https://docs.google.com/spreadsheets/d/1lnM4ez_w92JmoJj0VPmnxY17agG_MUFDhyLAnFFVv4M/edit?usp=sharing Em ter., 23 de mar. de 2021 às 04:41, Mick Semb Wever <m...@apache.org> escreveu: > 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. >
