ci(workflows): send new issue notifications to app maintainers by app label

[edward-ly]

Summary

Whenever a new issue for a particular app in this repository is created, this new workflow will send a GitHub notification to the appropriate app maintainer(s) by posting a comment in the issue mentioning them.

The current list of eligible apps only includes those for which a corresponding label already exists, but I am open to suggestions regarding what the final list should contain.

cc @DaphneMuller @janepie

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[provokateurin]

1. Why do we do this?
2. The app labels are not used enough to be reliable
3. Why are not all apps listed there?

[edward-ly]

1. Why do we do this?
2. The app labels are not used enough to be reliable
3. Why are not all apps listed there?

1. Because each app has separate maintainers (some of whom are not in the files team), this addresses a concern where server issues related to a particular app could not be seen by the app's maintainers in a timely manner. Turning on notifications for the entire server repository is not feasible because that would introduce too much noise from all the other apps. Sorry I forgot to include that earlier.
2. Then maybe we should enforce some kind of system that makes labels more reliable? Or at least something that helps send the right issues to the right people.
3. I'm open to feedback on which apps should be included or not. I also considered adding labels for apps that don't already have one created for them, but I'm not sure who exactly has the authority to do that.

[edward-ly]

Another potential alternative I just thought of would be to move each app out to separate repositories and re-add them as submodules instead, although I'm not sure yet if that'll affect other parts of the server in any way.

[DaphneMuller]

fyi @miaulalala
fyi @AndyScherzinger this is what we discussed a few months ago that people who maintain certain apps in the server repository struggle with getting notified of incoming issues & the solution Edward proposed that you approved

[miaulalala]

Makes sense to me, we should give it a trial run if it helps.

[susnux]

But experts are not app maintainers. For example look at the files app, they both will drown in notifications.

That is the reason why we have github-teams for pull requests which assign people from the respective team in round-robin. While this might work for any other repository I highly doubt this will work for server.
I fear it just creates more noise so that notifications are even more ignored.

Please note that we already have a triaging

We already triage the server issues: 🧑‍🤝‍🧑 Community triage (view)
The triage list is quite empty to the process is working.

If your point is that you think some app owners should be pinged about their apps then, we can add this to the process and let them handle them their issues. But at least for the server team thats not how work is split.

[provokateurin]

I fear it just creates more noise so that notifications are even more ignored.

If your point is that you think some app owners should be pinged about their apps then, we can add this to the process and let them handle them their issues. But at least for the server team thats not how work is split.

Fully agree with these two points.

[DaphneMuller]

The use case is that there are some server apps that are maintained by people in other teams. For example the comments app (maintained by Edward) and webhook listeners (maintained by Jana). So they need to get informed when there is a new issue for them. This must be a problem for many app maintainers that are not part of the files team. It's fine by me if this can be resolved by adjusting the triage process