I think of this from a discoverability and workflow perspective at least on the JIRA side, though many of the same traits apply to PR's. Some questions that come to mind:
1. Are people grepping through the backlog of open items for things to work on they'd otherwise miss if they were closed out? 2. Are people grepping via specific text phrases in the summary, with or without "resolution = unresolved", to try and find things on a particular topic to work on? 3. Relying on labels? Components? Something else? My .02: folks that are new to the project probably need more guidance on what to look for to get engaged with which is served by the LHF + unresolved + status emails + @cassandra_mentors. Mid to long-timers are probably more likely to search for specific topics, but may search for open tickets with patches attached or Patch Available things (seems unlikely as most of us have areas we're focused on but is possible?) The status quo today (leave things open if work has been done on it and/or it's an idea that clearly still has some relevance) seems to satisfy the most use-cases and retain the most flexibility, so I'd advocate for us not making a change just to make a change. While we could add a tag or resolution that indicates something closed out due to it being stale, my intuition is that people will just tack on "resolution = unresolved OR labels = closed_stale" in the JIRA case or sift through all things not merged in the PR case to effectively end up with the same body of results they're getting today. Given the ability of JQL to sort and slice based on updated times as well, it's relatively trivial to exclude stale tickets in your queries if you're familiar with things. We could also add a quick filter to our kanban to do this rather than changing the labeling across the entire project and introducing a new concept to the organizational primitives of tickets. We should also certainly provide more guidance for people on the project in terms of documentation / etc on discoverability of things to work on, ticket flow, etc on the contributing guide page: https://cassandra.apache.org/_/development/index.html#:~:text=Writing%20a%20new%20feature%20is,completed%20is%20just%20as%20important. ~Josh On Wed, Aug 10, 2022, at 11:27 AM, Paulo Motta wrote: > I recently came across a github automation in the docker project that I > found interesting: > https://github.com/docker/for-win/issues/7905#issuecomment-787212626 > "Issues go stale after 90 days of inactivity. > > Mark the issue as fresh with `/remove-lifecycle stale` comment. > Stale issues will be closed after an additional 30 days of inactivity. > > Prevent issues from auto-closing with an `/lifecycle frozen` comment. > > If this issue is safe to close now please do so. > > /lifecycle stale" > > This gives the ability of the PR owner to keep the PR open if it wishes so, > while auto-closing stale/abandoned PRs. > I think it would be nice to adopt a similar automation to improve our github > PR hygiene, perhaps with different staleness periods (ie. 180 days instead of > 90 days of inactivity). > > One can always re-open or re-create PRs that are auto-closed but are still > relevant, but I think it looks bad for the project to have a large amount of > stale unacted PRs. > > > Em qua., 10 de ago. de 2022 às 11:08, C. Scott Andreas <sc...@paradoxica.net> > escreveu: >> Claude, can you say more about the goal or purpose that closing tickets >> advances? >> >> There are quite a lot of tickets with patches attached that the project has >> either not been able to act on at the time; or which the original >> contributor started but was unable to complete. We’ve picked up many of >> these after a couple years and carried them to completion. Byte-comparable >> types come to mind. There are many, many more. >> >> Closing these tickets would be a very terminal action. If the goal is to >> distinguish what’s active from tickets that have gone quiet, adding a >> “dormant” label might work. >> >> - Scott >> >>> On Aug 10, 2022, at 1:00 AM, Claude Warren, Jr via dev >>> <dev@cassandra.apache.org> wrote: >>> >>> At the moment we have 222 open pull requests. Some dating back 4 years. >>> For some the repository from which they were pulled from has been deleted. >>> For many there are branch conflicts. >>> >>> Now, I am new here so please excuse any misstatements and attribute to >>> ignorance not malice any offence. >>> >>> I would like to propose the following: >>> >>> 1. We accept simple typo corrections without a ticket. >>> 2. Add a "Propose Close" label >>> 3. We "Propose Close" any pull request for which the originating >>> repository has been deleted. >>> 4. We "Propose Close" any ticket, other than simple typo corrections, that >>> has been labeled missing-ticket for more than 30 days. >>> 5. We Close any pull request that has been in the "Propose Close" state >>> for more than 30 days. >>> I don't have access to make any of these changes. If granted access I >>> would be willing to manage the process. >>> >>> Claude >>>
