Got it, yes that makes sense to me!
On 12 February 2023 09:36:44 GMT, Elad Kalif <elad...@apache.org> wrote: >Thanks for the comments my replies are in blue for all points raised. > >> 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? > >Half of the open issues are feature requests thus will not be impacted. The >thing I'm trying to resolve here is to know if the old issue is still >reproducible on main/latest version. If so the issue will be tagged >appropriately and will be kept open if the author does not respond. We can >assume the issue is no longer relevant and close it. > >> Why close only stale issues not stale PR's? > >We already have that. Stale bot works for PR (excluding ones with pinned >label) > >> 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 understand and share your concerns. First, this suggestion is just about >bugs not about features. The automation calls for action from the author to >recheck the issue. >This is something I'm doing today manually by going issue by issue and >commenting the exact same thing "Is this issue happens in latest airflow >version?" The auto close part is something that happens today when we add >the pending-response label. My goal is to make sure that the list of open >bugs we have is relevant. I'm not against larger intervals should we decide >for it. To clarify I'm not suggesting to close bug reports because lack of >attraction I'm suggesting to close reports that are not on recent versions >of Airflow. In practice I don't see people trying to reproduce bugs >reported on 2.0 in latest main - this simply doesn't happen so by having >this process we are asking the author to recheck his report. If the issue >is still reproducible then by letting us know that and by having the proper >labels it might get more attraction to it. > > >On Sun, Feb 12, 2023 at 10:15 AM Ash Berlin-Taylor <a...@apache.org> wrote: > >> 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 <ags.pankaj1...@gmail.com> >> 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 <elad...@apache.org> 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 >>>> >>>> >>>>
