Email Notification Storms - Alternatives

When pages are repeatedly edited, for example 20 times in the space of an hour, you get 20 emails all looking the same = an email storm.

As Confluence gains popularity, and people get used to using wiki's, pages will get edited more and more thus creating more of these storms. As a result, people are likely to start "unwatching" information (pages, spaces, etc) to shield themselves from the storms which is counter productive.

Having recently created an email storm myself without thinking (in the Atlassian Partners space), and also being exposed to a growing number of storms created by other people, it's become obvious that training users isn't going to solve the problem. The whole point of a wiki is to go in and make changes without any additional worries - people don't want to be thinking about anything other than the effects their changes have to a specific page.

Although the preview tab goes some way to solving the issue, it's value is only partial. It's simply more intuative to click "Save", "Edit", "Save" making incremental changes, and there are certain types of content that need to be viewed rather than previewed in order to see exactly what they look like to end-users (not almost what they look like as given with a preview).

There is also the "Minor change" checkbox, but this rarely gets used, primarily because people simply forget to use it or don't want to use it – it detracts from the simplicity of editing wiki pages.

There is also that "What did I go in to the kitchen for?" scenario - you've edited a page and made some minor changes, but then forgot the real reason you were in there. So you save the page. Then immediately remember what it was you wanted to do so re-edit. A while later, you suddenly change your mind about something and that's another edit. It quickly builds up in to a storm.

As such, myself and Dan started chatting about possible ways to resolve the email storms...

Delayed Notifications

There was a discussion recently on the conf-user list where an idea of "delayed notifications" was presented – notifications would not be sent immediately so that any subsequent notifications within a set time would be rolled up in to a single email.

While this would help reduce storms, it seems there are still some issues:

• There are cases when you need immediate notification of every single change to a page
• There are times when lots of alterations are made (regardless of the size of the alterations) over a period of hours - you'll still get a storm
• What happens if different people are making the changes - should notification "de-spamming" be grouped by person or page? (rhetorical: it depends on your requirements)

Tip: Should this feature be implemented, it will be useful to be able to set the "de-spam" time on a space by space basis (some spaces might want 0 = no de-spam, others might want 60 = 1 hour de-spam).

Which led us to discuss...

Diff Notifications

Most pages are more than just a couple of paragraphs in size. When I get an email notification regarding changes, I look at the subject ("what page was changed?") and then if I want to know what the changes were made I have to click the "View Changes" link.

What if the emails simply sent a diff – i.e. what was changed, nothing else?

This would have two major advantages:

• You'd instantly see what was changed, and have a link to view the whole page if desired
• Emails would be smaller and more useful – even if there is a storm, at least it's a high value storm

Natural Diffs

Then we went on to discuss "Natural Diffs" – rather than the type shown in the page version history, these would show wiki rendered text, but use the deleted and inserted wiki markup around specific changes. Much more user friendly, althouh the wiki notation for has now been stolen for use with underlined text in the RTE (a really bad choice IMHO - there's no markup for annotating deletions in legal or controlled documents any more! See: CONF-5437).

A natural diff could come in two flavours - either the whole page with insertions and deletions marked, or just the snippet that's been changed rendered properly rather than raw wiki text.

Automation

Dan raised the idea that the type of email could change depending on how much content (as a percentage) has been altered. For example... If you only change a few lines, then just send a short diff of those lines. If you've changed over 50% of the content, sent the whole page.

Comment Storms

Similar storms can be created during "comment tag matches" - where one person adds a comment, then others reply, eventually cascading in to a storm not only in your email client, but also on the "Recently Updated" lists. I've placed some ideas for how to deal with such issues in to the Confluence as a Forum#Update - 3rd March 2006 page.

Clearing Down Old Versions

It's not just your email inbox that get's clogged, it's the page version history. While vital in some circumstaces, there are other times when you really do wish all old versions of a page (with possible exception of the last couple of versions) could be cleared down for either a specific page, a space or all spaces. Can this feature be implemented (would also be useful for attachments and news)?

Feel free to discuss / add ideas, etc...

In addition, it will be interesting to hear any personal experiences of email storms (ie. did it stop you watching a space just to calm the storm?) or any views about the usefulness of the preview tab and the "Minor change" check box (do you use either of them, and if not, why not?).