I feel very strongly against automated closing of _issues_. There is nothing I find more infuriating and demoralising when dealing with an open source project (and big ones like Kubernetes are the worst offenders at this) where I find a bug or feature request is closed simply due to lack of traction.
I might be okay with a very long time (such as stale after 1 year and close another year after that.) Ash On 12 February 2023 02:00:00 GMT, Pankaj Singh <[email protected]> wrote: >Hi Elad, > >Thanks for bringing this topic. > >I also feel we should have some automation to close the stale issue. > >Few questions I have >- We have currently more than 700 issues and many of them have had no >activity since a year. What will we do with those issues? >- Why close only stale issues not stale PR's? > > >On Sun, Feb 12, 2023 at 1:23 AM Elad Kalif <[email protected]> wrote: > >> Hi everyone, >> >> It's been a while since we talked about the issue triage process. >> Currently our process involves a lot of manual work of pinging >> issue authors and I'm looking to automate some of it. >> >> Here are my suggestions: >> >> 1. add a new bot automation to detect core bug issues (kind:bug, >> area:code) that are over 1 year old *without any activity*. The bot will >> add a comment asking the user to check the issue against the latest Airflow >> version and assign a "pending-response" label. If the user will not >> respond the issue will be marked stale and will be closed by our current >> stale bot automation. I suggest 1 year here because in 1 year we >> usually have 3 feature releases + many bug fixes which contain a lot of >> fixes. We don't normally go back to check bugs on older versions unless >> reporting as reproducible on the latest version. There can be 2 outcomes of >> this: >> >> - The author will comment and say it is reproducible in that case we >> will assign the updated affected_version label and the issue will be >> bumped >> up. >> - The author will not comment. In that case we can assume the problem >> is fixed/not relevant and the issue will be closed. >> >> 2. similar to (1) for providers with labels (kind:bug, area:provider) and >> with a shortened time period of 6 months as providers release frequently. >> >> 3. similar to (1) for airflow-client-python >> <https://github.com/apache/airflow-client-python/issues> and >> airflow-client-go <https://github.com/apache/airflow-client-go> with no >> labels and period of 6 months as well. >> >> 4. On another front, we sometimes miss the triage of new issues. My >> suggestion is that any new issue opened will automatically have a >> needs-triage label (this is practice several other projects use) That way >> we can easily filter the list of issues that need first review. When >> triaging the issue we will remove the label and assign proper ones (good >> first issue, area, kind, etc..) >> >> What do others think? >> >> Elad >> >> >>
