auto assign external actors issues

[avifenesh]

Issue link

This Pull Request is linked to issue #2732
This pull request introduces a new GitHub Actions workflow for issue triage. The workflow is designed to automatically label issues created by non-contributors, helping to streamline the issue management process.

Key changes include:

• New Workflow Addition:
  • .github/workflows/issue-triage.yml: Added a new workflow named "Issue Triage" that triggers on newly opened issues. This workflow checks if the issue creator is a contributor and labels the issue accordingly if they are not.

---

The change can be tested just after it will be merged, hence currently is untested

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one issue.
• Commit message has a detailed description of what changed and why.
• Tests are added or updated.
• CHANGELOG.md and documentation files are updated.
• Destination branch is correct - main or release
• Create merge commit if merging release branch into main, squash otherwise.

[ikolomi]

I dont think making a distinction on what constitutes "User" issue basing on commits existence and org affiliation is an incorrect approach.

If i understand correctly, the intent is to mark issues that are potentially blocks the users as opposed to issues that are discovered by developers.

IMHO, a more straightforward and convenient way would be one of the following options:

1. Have a template for opening a "Production" or "User pain" issue - i think that "User pain" template nails the purpose exactly.

2. Note in the issue template that for blocking issue the opener should add "User pain" label

[avifenesh]

I dont think making a distinction on what constitutes "User" issue basing on commits existence and org affiliation is an incorrect approach.

If i understand correctly, the intent is to mark issues that are potentially blocks the users as opposed to issues that are discovered by developers.

IMHO, a more straightforward and convenient way would be one of the following options:

1. Have a template for opening a "Production" or "User pain" issue - i think that "User pain" template nails the purpose exactly.
2. Note in the issue template that for blocking issue the opener should add "User pain" label

@ikolomi
I didn't put user pain as the label, since, as you say correctly, I can't distinguish.

It's a "User issue".
We can think in your direction - but in this case, we should remove the "bug" and "features" templates.
And add, "bug - user pain" and "development - bug", "feature request" and "feature - development".
Users open bug issues, feature issues, and just non labeled issues, the intent is to have a way to filter internal vs external to be able to fast response.
Agree that external bug/blocker is the highest priority.
We can mix approaches - using the labeling + adding a template for "bug in production/blocker", so we can really get all the abilities.

Note that the next step, while ready, is to auto-assign on caller to those so he gets a notification directly.
In the current volume of traffic, I think we can afford to get a notification on external interaction.