On Tue, Apr 4, 2023 at 3:03 PM Joshua C. Colp <jc...@sangoma.com> wrote:
> On Tue, Apr 4, 2023 at 5:27 PM George Joseph <gjos...@sangoma.com> wrote: > >> >> >> On Tue, Apr 4, 2023 at 1:16 PM <aster...@phreaknet.org> wrote: >> >>> On 4/4/2023 2:53 PM, George Joseph wrote: >>> > <snip> >>> > >>> > Speaking of workflows... If you want to see the workflows and >>> > actions we've written so far, check out the asterisk/asterisk-gh-test >>> (the >>> > .github/workflows directory) and asterisk/asterisk-ci-actions repos. >>> If >>> > you're experienced with GitHub workflows, feedback is appreciated. >>> Thanks, George, et al, for all this amazing work. I admit Gerrit has >>> grown on me a little over the years, but other developers I've discussed >>> with do prefer GitHub and I'm eager to give this a try when it's all >>> ready. >>> >>> One question from looking through some of the workflows that are up now: >>> >>> https://github.com/asterisk/asterisk-gh-test/blob/master/.github/workflows/CloseStaleIssues.yml >>> >>> I'm a bit curious about the auto-closing functionality: >>> >> >>> * Do you think 14-21 days is a sufficient threshold for most issues? >>> It seems potentially a bit low to me. For example, once an issue is >>> triaged and opened, will it just be closed automatically 3 weeks >>> later if it hasn't been resolved by then? Or are issues in the >>> 'open' state exempt from this, this is purely for triage to weed out >>> junk issues? >>> >> * Case in point: one vendor I deal with frequently has this annoying >>> auto-close functionality in their system which triggers after about >>> 2 weeks or so. Often more time is required on one of our ends just >>> to follow up on the last thing, so there is a lot of inevitable >>> "commenting to avoid auto closure" and this just adds a lot of noise >>> into the tickets. >>> * Is there any connection with reviews/PRs in progress? Suppose an >>> issue is open and maybe on the verge of being stale, but someone has >>> submitted a PR against. Changes can often take much longer than 3 >>> weeks to merge, so it wouldn't make sense for an issue to close >>> itself in that case. So I'm concerned perhaps that might not be >>> sufficient time. >>> >> >> We're still thinking about the issues process but... >> >> The action allows you to specify labels that make an issue exempt from >> auto-closure. I was thinking that when a PR gets submitted, we'd look for >> the "Resolves: #issuenum" tag in the commit message, then add an >> "InProgress" label to the issue to prevent it from being auto closed. The >> issue would then get closed when the PR is closed. >> >> I'm also thinking it would only close issues that have been inactive and >> assigned to the submitter. Like the "Waiting for Feedback" status in Jira. >> >> Does that make sense? >> > > I think issues should only be closed if we are waiting for feedback from > the reporter during the triage process. Once accepted the issue should > remain open until either automatically closed through PR, or someone else > closes it. Same as now. > > Ack. > -- > Joshua C. Colp > Asterisk Project Lead > Sangoma Technologies > Check us out at www.sangoma.com and www.asterisk.org > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev