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