Last modified: 2009-11-19 18:34:59 UTC
Lqt in it's default state spams our users to death. Each reply triggers an update by e-mail, and on busy pages this causes a lot of e-mail traffic. Not funny. I think this is a (very) high priority issue. I would like it to work as I think the current enotif works - because I don't get that many e-mail through that system: don't send e-mails too often, or at least do not send more than 'n' e-mails between visits.
Created attachment 6764 [details] Screen shot with recent LiquidThreads e-mails Adding a screenshot with an overview of the 21 Lqt e-mail notifications I got in the past 6 hours.
r58850 disables lqtnotifytalk by default. Doesn't fix the issue, but mitigates it, I guess. Setting severity back to normal.
I'm confused as to what your proposed fix is. Do you suggest emailing only on the first unread new message? Only for the first per page? Something else?
(In reply to comment #3) > Do you suggest emailing only on the first unread new message? Only for the > first per page? Something else? Well, I mainly propose to change the current enotif, because it will drive users crazy. What it should be, I haven't found out yet. Does this sound like something: "only e-mail once between visits"?
> "only e-mail once between visits"? Trap: what is the minimum interval between visits? I could imagine that I view a pages every minute, and get a mail every minute. Should that maybe have a sensible default, like "if it is known that you were here in the last 10 minutes, I will not e-mail you"?
Really this bug is serious and has caused some users to suddenly receive hundreds of emails (without any limitation) from MediaWiki sites even though they DID NOT "opt in" to receive these emails (even a single email is bad if it is sent automatically and is not a private person-to-person communication). It appears that activating the option by default in Lqt has caused MediaWiki sites to be considered as a source of SPAM (which it really was) and being signaled as such (so Mediawiki sites were blacklisted). Because this forced activation was FULLY EQUIVALENT to force subscribing users to a new mailing list without their consent (assuming that they could "opt out" easily something that this functionality DID NOT even properly implemented: this required users to look by themselves from where all these emails came from and search for the new option that appeared in their preferences to disable it, sometimes in a language or script that they had not even been able to set in order to make the preferences tab usable). As long as there will be no simple way to have global preferences to make sure that no wiki will use some new functionality implemented locally), NEVER redo that in the future. Otherwise we will vote for blocking and excluding the authors of these extensions for severe abuse of user rights, and we'll want to have them removed from the list of users with commit rights in MediaWiki SVN.
There's also no obvious way to stop receiving the doggamed things.
Note: even "once per visit" is still not enough. This is still causing users to receive undesired emails from a mailing list that they have not opted in actively. MediaWiki should not use the "opt out" procedure (and anyway your fix still does not even implement the "opt out" procedure correctly, ad the emails do not even include any "unsubscribe" link). As the new feature is still not mandatory (coming from a community decision), there's absolutely no reason for allowing it to be enabled by default (instead consider informing users about the new functionality, using Global Site Notices that will first link to a page explaining to users how they can enable/disable it and what will be the impact). So change it immediately so that users will use active "opt in" rather than a bogous "opt out" which was explained nowhere.
Note: when I sunddely started receiving emails because of the activation of Lqt and its default behavior, I have received, in just three days, several thousands of emails ! although I do understand that this was caused by a bug, I did not read all of them (in fact I have just read one to see from where they came, and then I deleted them all). But other users will not have had the same "patience" and will have jsut signaled these emails as spam (which they really were), causing MediaWiki sites to be blacklisted in various places across the net. Don't blame those that have blacklisted Wikimedia sites or caused these sites to be blacklisted (due to user complains). Only Wikimedia is fully responsible of this effect. Wikimedia sites are now so large on the net that such bug cannot have them being considered minor. This is really a very critical issue to solve immediately (even if this means that Lqt must be disabled completely on all WMF sites, until is is fixed properly). The WMF should have noticed by itself that this activation had considerably increased the number of emails sent from its servers, and should have pressed the "Emergency Red button" to block ALL emails tentatively sent by the Lqt extension (and if there's still no such "Red button", consider implementing it and implementing also a live statistics monitoring for the volume of emails sent by WMF servers ; in addition, if any extension is autorized to send emails, these emails MUST be traced internally, with specific authorization keys, one for each extension on each wiki, so that they can be blocked/filtered selectively, if any bug occurs in one of the extensions using this capability).
The notifications will be opt-in as soon as the strategy wiki and other wikis with LiquidThreads enabled have received code updates, at which point I will consider this bug resolved. Please do not comment further unless you have something to add to technical discussion of the bug (for example, if the behaviour is not resolved once the updates have been deployed). Random rants about the impact of the bug are thoroughly unhelpful, and result in *my* email inbox being spammed by your unhelpful rants.
This is not "random rants". But clear statements about the negative impact of the bug, and what it has effectively caused. And don't say that I am spamming your mailbox, because you have opted in to receive all comments, and becaause I am not writing to you only, Andrew Garrett. You are not the single recipient, and others may still need to have the opinions of others than just you, before posting similar opinions. As long as the bug is open, other comments will come, confirming it, or proposing other solutions, or evaluating the proposed solutions (and even if YOU consider it closed because you think it was supposed resolved by you, others will still have to evaluate your solution). I have also not insulted anyone (not like the words you just used that are really unfriendly). The concept of the "Emergency Red button" on the WMF mail server(s), as well as its active monitoring, was still not discussed here, and is also part of the solution (to also help prevent future similar bugs), that's why I consider it "helpful" (both technically and as a policy) and clearly not "ranting".
(In reply to comment #11) > This is not "random rants". But clear statements about the negative impact of > the bug, and what it has effectively caused. At the point where we know something is a bug, we don't need another half dozen complaints about how bad it really is, we just care about fixing it. This is why comments on Bugzilla should be technical in nature, either suggesting a solution or pointing out a new incarnation of the bug. You've just been enumerating why one thing (sending people lots of e-mails) is bad, while we all agreed it was a bad thing before you started doing that; hence, these comments are useless. > I have also not insulted anyone (not like the words you just used that are > really unfriendly). Oh really? How about your threat in comment #6 (a totally unrealistic one I might add) to have developers who make a mistake blocked, excluded and stripped of their commit access? (For clarity: the community has no authority over commit access, so any developers potentially scared by this threat need not worry; I expect most know better, though.) Please evaluate whether your comments add something new to the technical discussion, and are not useless like illustrated above, before posting them to Bugzilla. I will now stop responding to any comments that only contain rants or threats, and I suggest others don't take them seriously either (whether to respond is up to them, of course).
Commit access is cannot be reliably given without taking the community into consideration (this is the community that gives them the power to continue their work, and notably those developers that are paid by the Foundation through the donations made by the community, or those that are nominated under the control of the bureau members elected by the community). If they feel that what was made was damaging, they will reject the change and will want the change to be reverted. And even if it is not reverted in the SVN repository, wiki admins will still be able to revert the changes that their local community don't want (and SVN developers will have absolutely no right to force the change on wikis they do not control). And yes, saying that is not an insult, and it is not personnal as this is a matter of policy applicable to anyone. A policy is not a threat.
Commit access is not related to Wiki(p|m)edia Community. If WMF decides to hire Andrew to make LiquidThreads work, you can object to it. But really, you're making too much noise for nothing. There was a bug, it was fixed. Please, go on. He has done much more good for liquidthreads than bad. PS: if you're so email sensitive, you can disable being sent emails...
This is a bug tracker. The bug is clear, and as stated in comment 12, we only expect tech related follow-ups. Failure to comply may result in having your commenting rights in this bug tracker revoked, and previous off topic comments removed. Thank you for your cooperation.
This bug has now been resolved on all Wikimedia sites.
#14: "if you're so email sensitive, you can disable being sent emails..." This is what was configured in all wikis. Until LiquidThread was added that forced the subscription without asking me. Yes I have removed the FORCED subscriptions from the wikis that have sent me tons of emails through LQT. I just hope that this won't occur in other wikis that I have visited in the past for some very active pages, when they will adopt LQT with the "default on" subscription option, despite ALL other email options were already disabled there (including for messages sent on my talk page on almost all wikis, except only ONE that I regularly visit, because my user page explicitly says where to post comments and how to contact me). For me it's much enough that all people can contact me via the talk page of my main wiki that I have publicized (and the admins of the wikis can still write to my email address in case of emergency): the talk page on my main wiki is still a perfect contact address for almost all people, and a valid substitute to an email address that I don't want to be polluted by messages coming from possibly hundreds of sources, and I better trust the admins on my main wiki than the few "non-working" admins of small wikis which are regularly spammed without much active control.
