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: >>> >>> >>> 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 >>> >>> >>>
