Instant notification of checkin changes

A co-worker is grumbling because the thing he wants to do is possible with Mediawiki but not TWiki. We'll be moving to Foswiki rsn so I'll post his question here.

Can anyone tell me if what he wants is possible now using any combination of existing plugins? If not, would this be a potentially interesting feature request?

Coworker's lament

this is a workflow that works for me:

I participate in some projects that use code.google.com, which offers an svn repository and a wiki that stores its files in the svn repository. the wiki is very basic, it doesn't have many features, but it works pretty well for collaboration.

whenever someone edits a wiki page from the web interface, the change gets committed to the svn repository. it's a normal svn checkin, and it sends out the normal svn checkin notification email.

so for every edit to the wiki, I get email notification of what page got changed, and a context diff of the change.

the important features of this system:

- I get notification for every change, even if I'm away for a few weeks. when I come back from vacation, I can go through all the changes in my email inbox whenever I have time.

- most changes are not interesting, and I can skim them quickly. changes that require more consideration, I can hold the email, refile it in a todo folder, forward it to someone else, etc.

- I can do very small units of work at a time. whenever I have a spare minute or two, I can read/delete some change notifications using normal email handling. I don't have to set bookmarks or remember my place in a list or anything.

so far, you haven't described anything in TWiki that will support a workflow like that.

when I tried using TWiki's WebNotify, I ended up deleting the email all the time without reading any of it.

in contrast, I skim/read every email I get from google code, even the changes that have nothing to do with me, because it's very easy.

---

13 Aug 2010 - 15:25:55 - VickiBrown

Foswiki and TWiki use WebNotify to notify users of changes via email. That's the basic core means to do that. There are additional plugins to ease and enhance this process like SubscribePlugin or ImmediateNotifyPlugin. You describe that your coworker says "I end up deleting the email all the time without reading any of it". Why does he do that?

-- MichaelDaum - 13 Aug 2010

Why does he do that?

He claims that this is because of two things

1. there's too much in the email (he's not sure which topics are "interesting" to subscribe to, so he subscribes to all of them
2. but then there's not enough detail in the email (he wants a diff not just a list of changed topics; feature proposal filed)

So he looks at a long page of links with no context and gives up.

ImmediateNotifyPlugin might be a good choice if/when a diff mode is supported on MailerContrib... presuming ImmediateNotifyPlugin works with MailerContrib. (it doesn't actualy say that it does) and if it didn't impact Performance. I'll suggest we look into that. (Even without diff that's a nice one to know about. Thanks.)

-- VickiBrown - 14 Aug 2010

We use Subversion in the project, including notification of checkins. Each checkin is a diff. This doesn't transmit less information than WebNotify, it transmits hugely more, which isn't for everyone. I suspect that ordinary folks using Mediawiki must be screaming and tearing their hair out at the number and volume of changes mails they receive.

Having said that, what is described is a vast simplification of how the Foswiki mailer works. Here's what is different:

1. Individual changes (checkins) mailed individually; no roll-up into single mails.
2. Changes transmitted in the form of a unified diff (unreadable for most humans, though coding apes manage quite well)

I suspect that addressing (2) would happify this particular user.

So, how might this work? The simplest way to do it would be to support a new formatting token in the mail template - say, %DIFF_TEXT% - that works like %HTML_TEXT% and %PLAIN_TEXT% but generates a verbatim unified diff. As can be seen from Foswiki::Plugins::MailerContrib::Change::expandHTML, it uses the Foswiki::Func::summariseChange interface which doesn't support passing back the unified diff. However examination of Foswiki::Func::summariseChange shows that it generates the unified diff during the summarisation process, so adding a mode to return it would not be difficult.

A more elegant solution would allow the user to set an option for how they want to receive mails. Since the code doesn't currently read user options, this would be significantly trickier, but still not too difficult. Another possibility, easier to implement but less elegant, would be to add a switch to the subscription.

Now, all you have to do is persuade someone to do all this.

-- CrawfordCurrie - 14 Aug 2010

On large wikis it is basically not a good idea to subscribe to all topic changes that might ever happen. In most cases only a few documents are of interest to one specific person. Best is to be rather selective which ones to put on the watch list.

E.g. you are the main author or responsible person for a set of document describing standard operating procedures of certain kinds. You'd then definitely want to be alerted on every change that happens to these documents.

So best advice for your coworker would be: if you don't know which documents are worth being put on a watch list, most probably none are. Finding out which documents are worth watching is not really solvable by either slimming down email notifications or adding diff content.

While a diff feature for MailerContrib is probably a missing feature, I would not recommend enabling it. Most normal people are alienated by diffs like svn diffs more than reading them thouroughly to understand the change.

-- MichaelDaum - 14 Aug 2010