The functionality is totally broken on http://test.leuksman.com which is a pity. Tim answered: Tim, thank you for your answers. When Enotif is disabled by sysops as you are telling me, then my original patch suppresses usually showing the options in user preferences! However, currently in testwiki, the options _are_shown_ and users can check or unchkeck the options ( in MISC ) w/o having influence on the feature. This is, what has puzzled me. It looks as if you have removed other code parts of Enotif patch in SpecialPreferences.php. Can you let me see the current LocalSettings.php and current DefaultSettings.php for testwiki please ? I suggest, that the functionaliy is please be restored: when sysops have disabled Enotif options (for any page changes, for user-talk page changes), then the correspoinding options should not be visible to the users in their user preferences. Cf. my EnotifWiki http://www.wikinaut.de/mw/rel15alpha1+enec326_CVS.tgz code. This does work as described. What you are saying, is.... ridiculous and I must cleary insist on revoking this statement because your are disseminating a misleading information. My patches work since August 2004 and the most recent one, based on MediaWiki1.5alpha1 CVS HEAD 06.05.2005 is perfect. It uses Brion's EConfirm and works very smoothly.It makes apparent, that you never have tested the version http://meta.wikimedia.org/wiki/Enotif#Download. The Enotif implementation in CVS HEAD was broken when Dammit introduced partially wrong wfTimestamp() function calls - when he tried to make it database independent, which was a good idea of course. This is now repaired in the following bugzilla 2014, which also removed an admittedly weird abuse of this field for the purpose of a delayed action. To summarise: the bugziall 2014 supplies you developers with the basic instructions, who to repair all things with enotif. I strongly recommend to apply this patch to the CVS HEAD version. It also finally drops the ugly UserTalkUpdate.php module (yes, this will become fully obsolete. It also reintroduces the memchache efficient method to store newtalk flag - we talk about this about six months ago. Please have a look to the code - I also fully removed Enotif calls in Article.php and shifted them all to RecentChange.php, where they better fit it (all hooks together now). The bugzilla has a concise description what is patched and why. http://bugzilla.wikipedia.org/show_bug.cgi?id=2014 (patchlet #1) Another patchlet #2 adds e-mail notification for new pages http://bugzilla.wikipedia.org/show_bug.cgi?id=2066 and can be applied optionally because it is short. The newpage-notifs can be sysop-configured, so that only powerusers (developers, sysops, bureaucrats) get notifs when a new page is created. (Any user sees a personal option "enotif for new pages" so that he can opt-in or opt-out at his discretion and noone should feel bothered by it. Kindest regards, Tom P.S. Users, who want to test a complete MediaWiki with all email functions working - notification on any page change - notification on user and user-talk page changes - notification on new pages are invited to download http://www.wikinaut.de/mw/rel15alpha1+enec326_CVS.tgz (from EnotifWiki from http://meta.wikimedia.org/wiki/Enotif#Download with the documentation) and to compare this version with the official http://prdownloads.sf.net/wikipedia/mediawiki-1.5alpha1.tar.gz?download .

"Timwi" == Timwi &lt;timwi(a)gmx.net&gt; writes: Have you actually seen the Enotif code? If not, then I suggest that you take a look at the latter half of UserMailer.php -- /Wegge Min holdning til Usenet - <http://wiki.wegge.dk/Usenet> Min weblog - <http://blog.wegge.dk/>

Timwi wrote: "Work on something else for a change" was exactly what I told Mark Ryan after he said on what is now [[Talk:Perth, Western Australia]]: "Aaaargh! somebody give me some feedback!!!! Somebody tell me what they think of the Perth page now, what it still needs etc etc... I can't do this alone." Strangely enough he didn't take offence. What I said to Tom just then was meant in the same way. Sometimes people can get emotionally involved in a single pet project. The project becomes everything, they worry constantly about what other people think of it, hang on every word of criticism or praise and try to do everything they think will make everyone repect their work. This applies equally to Tom now and to Mark then, as well as many other situations. Unfortunately Mark didn't see my advice until much later, he lost interest in Wikipedia in the same week and didn't come back for 18 months. Sometimes obsessive people forget that there is more than one way to earn the respect of others. Email notification is good, but even if it was perfect, it wouldn't be respected to the same degree that a continuing, diverse contribution to the community might be. Working on a range of things is a great way to avoid stress -- if you put all your eggs in one basket, you're in trouble if the basket fails. We're working on including email notification in 1.5, there's nothing more that Tom has to do for this to occur. I'm committed to this, it won't be removed. That's why my advice to him is to stop assuming the worst every time it's disabled on a wiki somewhere, to stop posting to wikitech-l every week accusing us of some injustice against it, and to find something else to do which will earn him the appreciation he sorely needs. I see you've taken the opportunity to list all the wrongs I've done against you in the past. I'll say a few words about each of them. * I honestly thought refusing to contribute to the Klingon Wikipedia was a fair compromise. Several people argued vociferously against it, I could have easily joined them, and done whatever I could to prevent the wiki from being created. Would you have preferred that? Instead I decided to live and let live. * The "don't tell other people what to do" thing shattered my confidence in my ability to communicate with other people. I tried to be honest and explain the situation, but you wouldn't believe me when I told you I had nothing against you, and you took offence at everything I said. It was an unpleasant experience. Unable to explain myself without making matters worse, I resigned myself to hoping that perhaps you would forgive and forget with the passage of time. I guess you haven't. * I don't think anyone here is a crap programmer, least of all you. Your skills are among the best on the team. I admit I was disappointed with the recent changes patrol feature from a design/usability perspective, but if I recall correctly, you agreed with me that its design was provisional rather than ideal. * Flexbisonparse is in a class of its own, I think it's amazing. Writing something like that is far beyond my capabilities. I can't imagine myself saying that there's something wrong with it. I may have said that I want to see benchmarks of the speed, and I may have said that it's not much use without HTML output, but both statements were intended to be encourage development towards a drop-in replacement, not to put you down. -- Tim Starling

Timwi wrote: Yes, I agree with you. The problem is that to have shell access requires a consensus of trust from several people. That's probably an appropriate requirement considering anyone with shell access can destroy the last week or two of edits to the site, or access private user data. I can't in good conscience give it to anyone who wants to do something that I don't want to do. And to search for something that I don't want to do and then offer to do it in exchange for shell access is just bribery. My suggestion for dealing with this problem was to split the cluster, to dedicate small amount of hardware to the smaller projects, and then have a more liberal access policy for that dedicated hardware. However Jimbo was strongly against it. -- Tim Starling