Hi, does anyone know about the (non-working) e-mail notification and the missing "updated" markers (for watched pages which have new contents since your last visit). The functionality is totally broken on http://test.leuksman.com which is a pity.
If you want me to assist in fixing this problem, please let me know. For those who want to use a working MediaWiki with e-mail notification for changed and new pages, it can be downloaded from http://meta.wikipedia.org/wiki/Enotif .
It could be easily extended to send notification to Sysops, when new users register. Pls. contact me, if you need this. Wikinaut Tom
Thomas Gries wrote:
Hi, does anyone know about the (non-working) e-mail notification and the missing "updated" markers (for watched pages which have new contents since your last visit). The functionality is totally broken on http://test.leuksman.com which is a pity.
It's disabled, not broken. That doesn't mean it will be disabled on Wikipedia, when it goes live.
If you want me to assist in fixing this problem, please let me know. For those who want to use a working MediaWiki with e-mail notification for changed and new pages, it can be downloaded from http://meta.wikipedia.org/wiki/Enotif .
Since it works much better in HEAD than it did in any of your patches, I wouldn't recommend anyone downloading them. There's still plenty of work to do though, as I discovered looking at it just now.
It could be easily extended to send notification to Sysops, when new users register. Pls. contact me, if you need this.
Why don't you find something else to do for a change? It's not like you're an email expert, I don't know why you're so keen on writing email features. Why not fix some bugs listed in bugzilla? There's hundreds to choose from.
-- Tim Starling
The functionality is totally broken on http://test.leuksman.com which is a pity.
Tim answered:
It's disabled, not broken.
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.
Since it works much better in HEAD than it did in any of your patches,
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 .
Tim Starling wrote:
Why don't you find something else to do for a change?
If I remember correctly, you are the one who has the nerve to refuse to move even a single finger for any project that you deem inappropriate (such as the Klingon Wikipedia), and if I also remember correctly, you were the one who most vocally told *me* not to tell other people what to do when I was new.
I *very strongly* suggest you not tell other people what to do.
Comments like the one above can very easily shatter all motivation someone may have to work on something voluntarily in their free time. I would hate to see that happen to Thomas, with all his great and hard work on Enotif going to waste. A lot of people are looking forward to this feature.
You may have your own opinions about things; you may think that everyone here is a really crap programmer and you could do it all much better if you had the time. You might think Enotif is a piece of shit just like you do with my Recent Changes Patrol feature and flexbisonparse. But, man, you gotta learn to keep it to yourself.
Timwi
"Timwi" == Timwi timwi@gmx.net writes:
You may have your own opinions about things; you may think that everyone here is a really crap programmer and you could do it all much better if you had the time. You might think Enotif is a piece of shit just like you do with my Recent Changes Patrol feature and flexbisonparse. But, man, you gotta learn to keep it to yourself.
Have you actually seen the Enotif code? If not, then I suggest that you take a look at the latter half of UserMailer.php
"Anders" == Anders Wegge Jakobsen wegge@wegge.dk writes:
"Timwi" == Timwi timwi@gmx.net writes:
You may have your own opinions about things; you may think that everyone here is a really crap programmer and you could do it all much better if you had the time. You might think Enotif is a piece of shit just like you do with my Recent Changes Patrol feature and flexbisonparse. But, man, you gotta learn to keep it to yourself.
Have you actually seen the Enotif code? If not, then I suggest that you take a look at the latter half of UserMailer.php
After reading the above message, it strikes me as unneccesarily short and terse. I did not mean to imply the lack of coding proficiency on Tom Gries's part, but rather that the enotif extension at this point has been engineered and reengineered so many times that it could benefit greatly from third-party refactoring.
Timwi wrote:
Tim Starling wrote:
Why don't you find something else to do for a change?
If I remember correctly, you are the one who has the nerve to refuse to move even a single finger for any project that you deem inappropriate (such as the Klingon Wikipedia), and if I also remember correctly, you were the one who most vocally told *me* not to tell other people what to do when I was new.
I *very strongly* suggest you not tell other people what to do.
Comments like the one above can very easily shatter all motivation someone may have to work on something voluntarily in their free time. I would hate to see that happen to Thomas, with all his great and hard work on Enotif going to waste. A lot of people are looking forward to this feature.
You may have your own opinions about things; you may think that everyone here is a really crap programmer and you could do it all much better if you had the time. You might think Enotif is a piece of shit just like you do with my Recent Changes Patrol feature and flexbisonparse. But, man, you gotta learn to keep it to yourself.
Timwi
"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
Tim Starling wrote:
I see you've taken the opportunity to list all the wrongs I've done against you in the past. [...]
In hindsight, maybe I shouldn't have done that. I apologise. If at all, I probably should have sent the mail privately, so you wouldn't have needed to defend yourself in front of the public community. But the urge was strong.
I don't know what it is that makes me over-react whenever you use terms or phrases that I see as potentially offensive. I tried to find the e-mail where you commented on the patrol feature, but I can't find it. There was another e-mail where you described a negative comment of mine as "whinging". In hindsight, it's a small thing, and I probably *was* whinging, but I think all of these small things add up to make it a bigger thing.
- I honestly thought refusing to contribute to the Klingon Wikipedia was
a fair compromise.
It is perfectly in your right to do or not do what you like. I personally don't like this behaviour of yours, but I will not complain about it because I am not in a position where I am entitled to do so.
However, I guess what actually irritates me is the combination of that *and* the fact that there are very few other people with the relevant access => the brickwall effect. I have often moaned that too few people have access to do the things smaller projects need to have done (this applies to pretty much all projects, not just tlh), and unfortunately it has often been misinterpreted to mean that I am insisting on receiving access myself. I just think that if you are going to refuse to do something that is in your power to do, then you should at least empower someone else to do it instead.
Thanks, anyway, for clarifying everything. I feel better now.
Timwi
Timwi wrote:
However, I guess what actually irritates me is the combination of that *and* the fact that there are very few other people with the relevant access => the brickwall effect. I have often moaned that too few people have access to do the things smaller projects need to have done (this applies to pretty much all projects, not just tlh), and unfortunately it has often been misinterpreted to mean that I am insisting on receiving access myself. I just think that if you are going to refuse to do something that is in your power to do, then you should at least empower someone else to do it instead.
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
Tim Starling wrote:
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.
My mind could be changed about this, if there was consensus that it is a good way to move forward. Certainly this rationale makes a lot of sense to me, and it was a rationale that I never really understood before.
The one major downside I see to splitting the cluster comes if we have a divergence of management practices across different clusters. It's pretty efficient to have a single cluster managed by a single team. In practice I'm hoping that as we add more datacenters they will be accessible to developers in a nearly transparent way -- it doesn't make sense to me that some people are responsible for managing one cluster and some people for another, if it means a lot of duplication of effort in things like writing scripts, etc.
There are obviously some upsides as well. If different projects are on different hardware, then a crash doesn't take everything out simultaneously. If different projects are on different hardware, we can relax *a little bit* about who has shell access, since we could in theory have people who have access only to their own specialty.
I can't be certain, but I can be almost certain, that we are in uncharted territory here. I don't think there is any other web serving organization pushing this many web pages out of this much hardware with volunteers self-organizing in the crazy wiki way that we do things.
So we're pretty much on our own in figuring out the social and technical ways to keep scaling... we can't really look to any other organization for the answers.
--Jimbo
wikitech-l@lists.wikimedia.org