Perhaps we just restrict “trivial” patches to trunk? If it requires several PRs/branches then a Jira is perhaps warranted, and perhaps if it is trivial and unimportant it’s better not to waste the project’s time managing the overhead.
This would also be simplified with a modified merge strategy, as it would be fine to simply open separate “trivial” PRs that could independently be closed in the UX with low overhead by maintainers. > On 11 Aug 2022, at 11:10, Claude Warren, Jr via dev > <dev@cassandra.apache.org> wrote: > > I agree the amount of work is somewhat overwhelming for the proposed change, > but I was referring to the lack of a Jira ticket blocking the pull request. > At least that is how it looks to the new observer. Perhaps we should add a > "trivial change" label for requests that do not have a ticket and are > trivial. > > How many branches do the changes currently need to be applied to? I assume > this goes up by 1 after the next release. > > On Thu, Aug 11, 2022 at 9:36 AM Benjamin Lerer <ble...@apache.org> wrote: >>> Is there an objection to accepting "typo" corrections without a ticket? >> >> One problem to be aware of is that those pull requests need to be converted >> in patches and merged manually up to trunk if they were done on older >> branches. So it might not look like it at first but it can be quite time >> consuming. >> >> Le jeu. 11 août 2022 à 10:07, Benedict <bened...@apache.org> a écrit : >>> 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
