Notifications: Provide confirmation for sending emails

[jnurthen]

Every time an email is going to be sent to the group the tool should provide a confirmation.
Currently it is unclear when emails get sent and when they don't. The author should have to actively confirm that an email should go to the list.

[plehegar]

in the meantime:

[[
Announcements are only sent out for 'Tentative' and 'Confirmed' events and when important changes are made (dates, status, recurrence rule, invitees, joining instructions, location)
]]
https://www.w3.org/Guide/meetings/organize.html#calendars

[anssiko]

I think this is another perspective into this same issue:

We found out by experimentation that calendar invites that have their Status set as "Confirmed" are not updated if other than "important changes" are made.

In this specific case, we had a meeting split across multiple days https://www.w3.org/groups/wg/das/calendar and we flipped the agendas of two days, but that did not result in an update to the calendar entries. @xfq @reillyeon

I worked around this by forcing an "Event Changed" mail by flipping Status: Confirmed > Tentative > Confirmed, but this of course triggered two "Event Changed" mails instead of one.

Maybe the UI could provide a "force push" checkbox(?) that if checked when hitting "Update" would trigger an update to the calendar invites also when other than "important changes" are made.

Related, it was not currently obvious looking at the tool, what are "important changes" that trigger an update to the calendar invites.

[jean-gui]

@jnurthen @anssiko What do you think of @vivienlacourba's proposal at #14 (comment) for indicating when notifications will be sent?

The "force push" feature can certainly be added as well

[anssiko]

My use case asks for an ability to selectively force push updates to invites even if other than important info changes. IIUC that’s not addressed by #14 (comment)

I personally like an UI that is explicit and has no magic i.e. doesn’t do things without me knowing. Thus I like the force push checkbox idea.

[swickr]

I personally like an UI that is explicit and has no magic i.e. doesn’t do things without me knowing. Thus I like the force push checkbox idea.

+1 to this from @anssiko; it feels better to me to let whomever is making the change decide whether the change needs a push or not. A fixed algorithm that decides for me what's an "important change" is sure to get it wrong on occasion.

Then we can debate whether the default state of the checkbox is 'checked' or 'unchecked' :) But at least it's explicit.

[jnurthen]

@jean-gui IMO the proposal in #14 is better than the current state and it would be a reasonable quick fix until a better solution can be added.

[plehegar]

+1 for being explicit. We may want to add a throttle/cool-down to prevent the system from being abused.

[jean-gui]

I've discussed the topic of notifications with @plehegar @swickr and @vivienlacourba and this is what we propose:

• The tool will not send emails automatically. Instead, editors will see two buttons: one to save changes and send notifications, and one to save without sending notifications.
• As the editor makes changes to an event, a message will dynamically appear above the save buttons to inform them if (what appears to be) significant changes were made
• If the editor makes significant changes but decides not to send notifications, a message will appear on subsequent edits to remind them they should send notifications at some point

@anssiko @jnurthen, how does that sound?

[anssiko]

This sounds great to me, thanks!

[jean-gui]

So I've been doing more experiments, and delaying notifications is tricky.

To explain why, let's take a simple example. Let's call the editor A and the invitee B.

1. A creates a new daily event (from 2021-04-01 until 2021-04-30) and sends a notification.
2. B receives the notification and adds the event to their calendar.
3. A edits the occurrence 2021-04-15 and future ones, ending the recurrence on the 2021-04-25 but chooses not to send a notification. Behind the hood what happens is that the initial recurrence now ends on 2021-04-14 and a new daily event from 2021-04-15 until 2021-04-25 is created (Multiple notifications sent? #22 (comment) explains why we have to do that).
4. A edits the occurrence 2021-04-21 and sends a notification.
5. B receives the notification for 2021-04-21 and adds it to their calendar. B now sees a daily event from 2021-04-01 until 2021-04-30 (from the first notification), and an unrelated one-shot on 2021-04-21.

Instead of this final state, B would expect to see in their calendar a daily event from 2021-04-01 until 2021-04-14, and another one from 2021-04-15 until 2021-04-25, with its 2021-04-21 occurrence modified as per 4.

In this relatively simple example, the solution would be on step 4 to send 3 emails instead:

• one containing the ics of the original daily event but shorten to end on 2021-04-14
• one containing the ics of the secondary daily event running from 2021-04-15 until 2021-04-25
• one containing the ics of the 2021-04-21 occurrence associated to the secondary daily event

With the current automated system we already send multiple emails when editing "this and future occurrences": one for the original event that gets shorten, one for the new recurring event, and one for each occurrence that has been edited and is being re-associated with the new recurring event. AFAIK this is how some other big vendors do it. This can result in quite a few emails being sent to the invitees but this is the only way we can ensure consistency with calendaring clients.
And, with the currently implemented automated system, we send those emails as soon as needed, which helps limit the number of emails sent at once.
On the contrary, if we let A choose when to send emails the more A edits occurrences without sending notifications the more emails would be sent when they finally decide to send them. And I'm afraid recipients will get upset if they receive too many emails at once (not to mention that calendaring clients may get confused and not do the right thing; I experienced that when Thunderbird thought one of these notifications had already been processed and thus prevented me from importing it when in fact it had not).

An alternative to all those emails would be to stop attaching the ics to notifications and ask users to subscribe to their personal w3c calendar feed instead. On the plus side, by doing so we could send only one email when an event or an occurrence is changed as I tend to believe that humans are much better at understanding scheduling changes than calendaring clients. Using the example above, even though B hasn't been notified of the changes made on step 3, they would still understand what the notification sent on step 4 is about. And they could see the complete picture for the recurring event in their calendaring client if they subscribed to their W3C calendar.
On the other hand, if we stop attaching ics to notifications, people won't be able to click on the accept/deny button shown by mail/calendar clients when we start gathering participants' response. Instead they would have to click on a link in the email. I haven't looked into that feature yet, but if support for it in calendaring clients is as bad as the rest, then perhaps this would be for the best to avoid interoperability issues.

TL;DR:
ICS in notifications is a pain to handle properly. When an editor decides to send notifications, there are three alternatives I can think of:

• send all the necessary notifications to keep calendar clients consistent. Might be seen as spam and ignored
• send only a notification for the event/occurrence being edited. Less intrusive but can result in incomplete and inconsistent calendaring clients
• don't send ics attachments and rely on users subscribing to their personal w3c calendars. Not very calDav-friendly but consistent and less intrusive

Personally, I think we should avoid the second option or users will get confused when they check their calendaring clients. The third option seems better to me, as it's less confusing and less spammy ad the first one but as I'm not in any public groups I don't really have experience on how well (or bad) this would be received.

Does anyone have an opinion on the best course of action? If you have other ideas about how to send these to notifications, feel free to share them as well.

Jean-Gui

Note: it's not possible to send one notification with multiple events/occurrences attached (either with one ics per event or one ics containing all of them), support for this in calendaring clients varies from poor to none.

[swickr]

Thanks for this example, @jean-gui . What makes this especially confusing for the user is the single email that contains the transaction to shorten the initial event. Without the context in that email that says "this update is important to keep your local calendar in sync; there's another email immediately following this that will update the future occurrences; apply this one first for best results." the user might think they don't need to tell their MUA to process it.

But the alternative, requiring users to subscribe to their personal W3C calendar, would mean that a user no longer has the option to remove an occurrence from their own calendar, or perhaps to ignore a particular group's calendar events entirely if they're unable to attend meetings and are participating in some other way.

I have more granular control when I choose to process .ics attachments in emails than if I were to subscribe to the (current version of the) w3c personal calendar. I prefer that finer control.

[dwsinger]

Thanks for this example, @jean-gui . What makes this especially confusing for the user is the single email that contains the transaction to shorten the initial event. Without the context in that email that says "this update is important to keep your local calendar in sync; there's another email immediately following this that will update the future occurrences; apply this one first for best results." the user might think they don't need to tell their MUA to process it.

But the alternative, requiring users to subscribe to their personal W3C calendar, would mean that a user no longer has the option to remove an occurrence from their own calendar, or perhaps to ignore a particular group's calendar events entirely if they're unable to attend meetings and are participating in some other way.

I have more granular control when I choose to process .ics attachments in emails than if I were to subscribe to the (current version of the) w3c personal calendar. I prefer that finer control.

While that is true, manually inserting events from ics into my calendar runs a real risk that I'll miss something, or that (as noted above) I'll apply ics updates in the wrong order. I've already filed a feature request against Apple Calendar to have "events in this subscription should mark me as busy on " and now I realize that that needs to be a check-box, so I can turn if off for meetings I know I won't or can't do.

[dwsinger]

Reading @jean-gui perhaps the solution is that if you change the structure of an event – repetitions, notably – and notifications have previously been sent, then notifications are always sent. Only for "minor" changes can notification be delayed?

[jean-gui]

@dwsinger Notifications are currently automatically sent for important changes (those that may change ability for participants to attend) only. I don't think your proposal would work better as emails would still be sent automatically if a mistake is made in one of those important fields, which is the main reason for trying to find a better way.

@swickr I like your proposal of adding a message in the emails explaining what they are for, I'll see if I can add that.

So I will implement a way for chairs to send those emails only when they want to. All the notifications required to maintain consistency will be sent and if recipients think that's too much spam they can unsubscribe from them.
When editing an event that has pending notifications, chairs will also see a notification.

[jspellman]

As agenda items come up from different sources during the week, it would be very helpful to be able to note them in the agenda tab without a notification. Maybe that is how you have designed it, but I'm paranoid about spamming the lists and I'm afraid to try it. (I already sent out one obvious mistake to a list. It's too easy to increase the meeting end time by a year without noticing.)

If you have added an editor control or notice of whether a notification is going to be sent, I haven't found it yet.

[anssiko]

@jspellman, to address a similar concern to yours, my current approach is to keep the agenda in a GitHub repo and only add an agenda link to the tool. Here's an example: https://www.w3.org/events/meetings/293d050e-0261-492a-bd3c-e7889a57f75a

This way, the content of the agenda can change while the meeting is Confirmed without spamming the list when the agenda is updated (participants can watch the meeting GH repo themselves if they want to subscribe to the agenda changes).

Other benefits of this approach are change history and collaborative editing of the agenda i.e. participants can propose agenda topics via Pull Requests. A wiki would similarly.

Hope this helps.

[plehegar]

(side note: the W3C cloud is suffering from hardware failures, which is further delaying progress on this)

[plehegar]

(we're in internal testing phase before deployment)

[jean-gui]

Changes have been deployed. There are now two buttons, one that will send notifications and one that won't.
If you choose not to send them, there will be a reminder on the event and edit pages to not forget about it.