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