On 06.02.23 21:34, Neil C Smith wrote:
On Sat, 4 Feb 2023 at 00:51, Michael Bien <mbie...@gmail.com> wrote:
yeah it seems like nobody is using the triage label the way it was
originally intended.
We could probably just remove that label (or don't let gh set it by
default at the very least). If something is missing labels it is
probably not triaged.
I'd prefer to keep a label. Possibly even more likely to accumulate
unanswered issues without?
One of the original intentions was to allow us to use GH actions for
some automation. We could remove the label automatically if a
committer replies?
in theory yes. In practice:
- the workflow might need write permission for that, current workflows
are intentionally kept without that permission (this is also the apache
default last time i checked)
- the workflow would have to check who is an apache committer
Could even email a report of older issues without
a response on a regular basis?
please no :) Not to me at least.
gh CLI can probably generate that list. I used it from scripts for
another project before.
gh issue list --label "needs:triage" --search "sort:created-asc"
second entry point is via the search (has filters for comment count etc):
gh search issues [<query>] [flags]
(don't run more than 5k queries per hour)
and probably more. Should we prefix all issue specific labels with
'issue:'? So that they are easier to find in the search? Mentioning
'issue' in the label description would have a similar effect.
Possibly would help. Need to check whether they're used, and make
sure we don't rename any with special meaning though.
yeah. Ideally they shouldn't show up in main.yml and release.yml... and
doesn't hurt to check the rest too.
Adding a label description should be always safe.
Incidentally, also need to handle the fact that GH changed the forms
so that required dropdowns are being populated - I think that's why
we've had more offers of PRs! :-)
we should interpret this as commitment and let a github action ask the
user once per week where the PR is :)
-mbien
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
