Those all seem like good suggestions to me
> On 11 Aug 2022, at 08:44, Claude Warren, Jr via dev > <dev@cassandra.apache.org> wrote: > > > My original goal was to reduce the number of pull requests in the backlog as > it appears, from the outside, that the project does not really care for > outside contributions when there are over 200 pull requests pending and many > of them multiple years old. I guess that is an optics issue. Upon looking > at the older backlog, there were a few that I felt could be closed because > they didn't have tickets, or were trivial (i.e. typo correction), or for > which the original repository no longer exists. However, from the > conversation here, it seems like the older pull requests are being used as a > long term storage for ideas that have not come to fruition and for which the > original developer may no longer be active. > > Looking through the pull request backlog there are a number of requests that > are not associated with a ticket. Perhaps we should add pull request > template to github to request the associated ticket number when the pull > request is made. The template can also request any other information we this > appropriate to speeding acceptance of the request. I would add a "This is a > trivial change" checkbox for things like typo changes. Is there any > documentation on the pull request process? I think I saw something that said > patches were requested, but I can't find it now. We could add a link to any > such documentation in the template as well. > > Is there an objection to accepting "typo" corrections without a ticket? > > > > Claude > >> On Wed, Aug 10, 2022 at 5:08 PM Josh McKenzie <jmcken...@apache.org> wrote: >> 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: >>>> >>>> We accept simple typo corrections without a ticket. >>>> Add a "Propose Close" label >>>> We "Propose Close" any pull request for which the originating repository >>>> has been deleted. >>>> We "Propose Close" any ticket, other than simple typo corrections, that >>>> has been labeled missing-ticket for more than 30 days. >>>> 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 >>>> >>
