This question about Missing functionality: Answered
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?
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
. 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?
- 13 Aug 2010
Why does he do that?
He claims that this is because of two things
- 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
- 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.
might be a good choice if/when a
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
that's a nice one to know about. Thanks.)
- 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:
- Individual changes (checkins) mailed individually; no roll-up into single mails.
- 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
, it uses the
interface which doesn't support passing back the unified diff. However examination of
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.
- 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.
- 14 Aug 2010