[asterisk-dev] GitHub: Side Note: What makes us "special"?

[George Joseph]

On Tue, Apr 4, 2023 at 3:03 PM Joshua C. Colp <jcolp at sangoma.com> wrote:

> On Tue, Apr 4, 2023 at 5:27 PM George Joseph <gjoseph at sangoma.com> wrote:
>
>>
>>
>> On Tue, Apr 4, 2023 at 1:16 PM <asterisk at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20230405/c98cdfca/attachment.html>