Improve issue notifications

[ianhinder]

In order to keep on top of what's going on in a project, we need to have notifications of comments on issues. Currently, we have a single issues repository for which we can subscribe to notifications. However, this sends us notifications of every single change to every issue in every repository (since they are all discussed in the one repository). The email notifications, sadly, don't contain enough information to create email filter rules to filter out only those that we are interested in, which will typically be those with a given label. Reading all the notifications one after another, one cannot even tell which project a given notification is about.

The only solution I have come up with, so far, is to "unwatch" the SCRCIssueTracking repository and instead rely on the fact that Github will send me notifications anyway for issues in which I am "involved". This could be because I created the issue, have participated in it, or have explicitly subscribed to the issue. Since I created almost all the issues in CoronaBICI, this works for my case, but it wouldn't work for someone else who wanted to keep on top of the CoronaBICI issues, unless they regularly went through them all and subscribed to them.

Some options:

1. Rename all issues to be prefixed with the project name
2. Have per-project issue repositories
3. Use the issue label notifier. From the description, "This GitHub Action allows you to notify users or teams when specific labels are added to an issue. It runs every time a label is attached to an issue, and compares the label to the list of notification recipients that you specify. If a match is found, the action will add a comment to the issue and @mention the notification recipients."

I would suggest to give (3) a try.

[ianhinder]

I've implemented a test version of (3), just for my case. This could be expanded in https://github.com/ScottishCovidResponse/SCRCIssueTracking/blob/master/.github/workflows/issue-label-notifications.yml to map all the labels to the teams. This would cause all those people to get all notifications for all teams they are in; I'm not sure if they could opt out.

[richardreeve]

I suspect they couldn't, but if people actually complain then we could make child "notification" teams of the main project teams that people can remove themselves from. We should probably not start off with that though - we have enough complexity already... do you want to just go ahead and do it? You can send an email to scrc-dev at glasgow.ac.uk, which will (hopefully!) go to all of the members of all of the teams to tell people what you've done and to stop watching this repo?

[richardreeve]

@alysbrett What do you think?

[alysbrett]

Yes - let's try it. If you have time do go ahead @ianhinder or let me know if you need help.

Thanks for pursuing this - it may just help my sanity too!

[ianhinder]

I'll give it a shot!

[ianhinder]

Actually, as per the email I sent a few mins ago, another option would be to explicitly add the code owner and the RSE lead, rather than the whole team. Do we think there is value in other members getting all notifications? I could do that, send the email, and ask if anyone else wants to be added. That might make a flood of requests though, and it wouldn't scale to new members. Is everyone automatically subscribed to the whole-repo notifications, or would they have had to have done it explicitly?

[richardreeve]

Personally I would add the whole teams, send an email saying what has happened and what to do (unwatch the repo), and ask if anyone minds this setup. If no-one complains then we leave it. If they do object we can remove that team and add its members. Hopefully inertia will mean no-one complains...

[ianhinder]

OK, will do.

[richardreeve]

I've unwatched. I'm v excited! And I've marked all conversations read... I hope there wasn't anything important in there!

[ianhinder]

haha. I've got a mapping here; can you check it?

Admin & management=@SCRC-admin
Contact-Tracing-Model=@FMD-Model
CoronaBICI=@CoronaBICI
Covid_Simulation_Model=@NDCode
Covid19_EERAModel=@EERAModel
Data management=@SCRC-data
model reconstruction=@Model-reconstruction
Simple Network Sim=@Simple Network Sim
Simulation.jl=@Simulation.jl-devs @Simulation.jl-admins

I don't know how to do the Simple Network Sim one. The label name with spaces is fine (there's one in the example). But the team name with spaces is going to be ambiguous, because they use spaces as the separator between multiple recipients. Maybe the "@" is enough. There's no documentation on what to do in that case, and I can't find the source. It might be you have to use a - instead of a space, or quote with "" etc. No idea. Shall I just go ahead assuming it will work? I can ask one of them if they are getting notifications, I suppose.

[richardreeve]

We could just rename the team?

[richardreeve]

Simple-Network-Sim?

[ianhinder]

yeah - I'd do that if it doesn't work. On that subject, it would be nice if the labels and team names coincided in case, separator, and name (e.g. Contact-Tracing-Model != @FMD-Model).

[richardreeve]

Yeah, FMD-Model got restarted (it was a repo 10 days ago). I don't know what to do about that. But Simple-Network-Sim is changed.

[richardreeve]

Oh, sorry. I see you said you'd try it with spaces. Sorry - it's the end of the week!

[ianhinder]

I'll check what it is now, and make it consistent.

[richardreeve]

I believe @ianhinder has now fixed this for some of us using the github action above. I'm resubscribing to some of the issues that were tagged but I didn't subscribe to manually, so I guess we have to be careful about that (or we could manually take the label of and re-add the label to every issue!). Anyway, closing... 🎉