Another revive, ;)
I took a long thought and considered (most of) the remarks made then discussed
with Vishesh.
we decided on these parameters for the action:
days-before-stale: 120
days-before-close: 120
exempt-issue-labels: 'gsoc,good-first-issue,long-term-plan'
exempt-pr-labels: 'status:ready-for-merge,status:needs-testing’
In this way we can leave things untouched that we think are valid but will lay
around a while, and also be lenient to people having $dayjob be in the way.
please review https://github.com/apache/cloudstack/pull/8667 again. It has
enough votes to merge now but I want to give it at least a weekend and a
$dayjob day to think about it. I will merge it next week sometime, on no
further (new) reservations.
thanks,
On 2024/08/28 14:34:07 Daan Hoogland wrote:
> thanks for reviving @João Jandre Paraquetti , I agree in principle but
> my original reservation still stands. A year is too long but for some
> technical debt we might accept it. Would there be a way to label or
> otherwise mark tickets for not closing marking?
>
> On Wed, Aug 28, 2024 at 4:04 PM João Jandre Paraquetti
> <[email protected]> wrote:
> >
> > Hi all,
> >
> > I would like to revive this discussion again, as I believe that
> > Vishesh's initiative is great for the projects maintenance.
> > Although the original proposal of marking as stale in 90 days and
> > closing after another 30 days is somewhat aggressive, I think that
> > awaiting 1+years to close a stale issue/PR is too much. I also think
> > that we should approach PRs and issues separately, as many times issues
> > are created for a feature request or bug that might take long to fix,
> > and PRs are generally supposed to be always updated by the author. Thus,
> > here's what I propose:
> >
> > For issues:
> >
> > - After 180 days, label as stale.
> >
> > - After 90 days as stale, close it.
> >
> > For issues which are long term goals or which naturally take a long time
> > to work on, we should label them with a 'long-term' label, and these
> > should not be labeled as stale by the bot.
> >
> > For PRs:
> >
> > - After 90 days, label as stale.
> >
> > - After 60 days, close it.
> >
> > Best regards,
> >
> > João Jandre.
> >
> > On 5/2/24 05:35, Rohit Yadav wrote:
> > > I like the general idea but at the same time want to weight in that we
> > > also do the right thing in handle issues and PRs. Sometimes there are
> > > genuine issues and PRs, however, we make no progress on them for one
> > > reason or another.
> > >
> > > As of last week, I've triaged all the outstanding Github issues that took
> > > some effort, and have tagged issues with the 1yr+ and 2yr+ tags and stale
> > > tags on all issues that are several years old now. I hope to not have
> > > incited negative reactions where I had to close about 50 odd issues which
> > > were really old, or already fixed, or moved a few of them to discussions.
> > > I see the value in having an automation to something around time based
> > > manner, esp for old issues and PRs that nobody cares about. Other
> > > opensource projects such as Kubernetes has similar automation.
> > >
> > > Many issues are (a) user queries or questions about their deployment or
> > > environment, and not necessarily issues or problems in CloudStack which
> > > can be moved to Github discussions (which are connected to our users@ ML)
> > > and (b) many issues are user feature requests or suggestions which nobody
> > > has cared to address. For (a) I've proposed a PR to drive users by
> > > default to Github Discussions first via the CloudStack UI and we can
> > > triage and move such user discussions which are not really CloudStack
> > > issues from Github issues to discussions.
> > >
> > > I think 2yrs+ is a reasonable time to close old/stale/inactive issues and
> > > PRs. And of course, anybody should be free to re-open or request to
> > > re-open and retain interesting issues and PRs on case by case basis.
> > >
> > > It's also worth encouraging and reminding everyone that CloudStack is an
> > > opensource project where all stakeholders including the users can pitch
> > > in, help with engaging in the discussions, sharing steps to reproduce a
> > > problem, or effort/steps to help test a change/pull-request, to improve
> > > the website and documentation, as well as to review/test pull requests.
> > > This means, as much as the development activity we get, we can also
> > > benefit from users in helping to address their own problems (if not
> > > including code but also) including documentation, website etc. "What's in
> > > it for you?" - you care, because you benefit from the project and you
> > > want to keep benefiting from the project.
> > >
> > >
> > > Regards.
> > >
> > >
> > >
> > >
> > > ________________________________
> > > From: Daan Hoogland<[email protected]>
> > > Sent: Tuesday, April 30, 2024 18:05
> > > To: dev<[email protected]>; users<[email protected]>
> > > Subject: [REVIVE][DISCUSS] Closing issues & PR after a certain time
> > >
> > > People,
> > > I want to revive this discussion and bring Vishesh' PR under your
> > > attention again.
> > > The discussion there is mostly about the length of the period before
> > > closing.
> > > So here I am going to state 1year - first warning, 1.5years second
> > > warning, 2 years closing. What do you all think?
> > >
> > > There are also issues that we might consider interesting but not
> > > functionally complete or clear, we can convert those to github
> > > discussions, and I would like to encourage all of you to do that as
> > > sometimes issues will lead to issues and not to PRs and those are
> > > basically discussions to be had.
> > >
> > > please respond with your comments or put them in
> > > https://github.com/apache/cloudstack/pull/8667
> > >
> > > regards,
> > >
> > > On 2024/02/16 09:17:02 Vishesh Jindal wrote:
> > >> I have created a PR with the changes
> > >> here:https://github.com/apache/cloudstack/pull/8667
> > >>
> > >> I propose that we enable it. As Daan suggested, we can always remove the
> > >> action if it doesn't work out. And if a PR/issue gets closed, we can
> > >> always reopen it.
> > >>
> > >>
> > >>
> > >> ________________________________
> > >> From: Daan Hoogland<[email protected]>
> > >> Sent: Wednesday, February 14, 2024 2:17 PM
> > >> To:[email protected] <[email protected]>
> > >> Subject: Re: [DISCUSS] Closing issues & PR after a certain time
> > >>
> > >> i'm a bit -0 on this. I agree that a lot of stale issues deserve
> > >> closing, but others are really long term goals. I do not want to block
> > >> this great idea but am just a bit worried about other great ideas
> > >> getting lost. So I would propose to tag anything we close or not
> > >> remove the stale tag, so these can be easily found. I am not worried
> > >> too much about PRs, just issues.
> > >>
> > >> On the other hand, we can always remove the gha again, so maybe we
> > >> should install it and see if it works for us.
> > >>
> > >> On Wed, Feb 14, 2024 at 4:49 AM Kiran Chavala
> > >> <[email protected]> wrote:
> > >>> Good idea Vishesh
> > >>>
> > >>> +1 for using Githubactions
> > >>>
> > >>> Regards
> > >>> Kiran
> > >>>
> > >>> From: Vishesh Jindal<[email protected]>
> > >>> Date: Tuesday, 13 February 2024 at 6:33 PM
> > >>> To:[email protected] <[email protected]>
> > >>> Subject: [DISCUSS] Closing issues & PR after a certain time
> > >>> Hi everyone,
> > >>>
> > >>> I was going through the issues and PRs, and I noticed that a lot of
> > >>> them are really old and some of them are waiting for the original
> > >>> author to reply.
> > >>>
> > >>> I wanted to discuss if we should add a github action
> > >>> (https://github.com/marketplace/actions/close-stale-issues) for auto
> > >>> closing the issues and PRs after a certain time.
> > >>>
> > >>> From the github actions' documentation, this is how it works:
> > >>>
> > >>> * Add a label "Stale" on issues and pull requests after 60 days of
> > >>> inactivity and comment on them
> > >>> * Close the stale issues and pull requests after 7 days of
> > >>> inactivity
> > >>> * If an update/comment occur on stale issues or pull requests, the
> > >>> stale label will be removed and the timer will restart
> > >>>
> > >>> Instead of using the defaults, I would like to:
> > >>>
> > >>> *
> > >>> mark the issue/PR stale after 90 days
> > >>> *
> > >>> close the stale issue/PR after 30 days
> > >>>
> > >>> Let me know if this sounds good. I will create the PR to set this up.
> > >>>
> > >>> Regards,
> > >>> Vishesh
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >> --
> > >> Daan
> > >>
>
>
>
> --
> Daan
>
