Last modified: 2014-04-26 08:36:55 UTC
I currently run a bot (EdwardsBot) that handles global message delivery: <https://meta.wikimedia.org/wiki/Global_message_delivery>. I'm not sure how sustainable this situation is, particularly as Wikimedia staff are now relying on this system more and more to communicate to groups of wiki users. I'm filing this bug as I'd like there to be some general thought for the best way of doing something like this (in an extension, perhaps? on Wikimedia labs? or a Toolserver tool with a user interface and real logging?). And is something like this needed at other wiki farms? Perhaps an extension could provide different delivery methods (or allow users to control how they want a message delivered, ideally). Or you could have streams that users can subscribe to, maybe? There should also be some general thought about whether this is the right approach at all. Updating a bunch of wiki pages has benefits (there's an archive, there's an associated e-mail notification, etc.) but it also has detriments (decentralizing the message, slow to deliver, waste of resources, e-mail notifications don't contain the actual message, watchlist and RecentChanges flooding, etc.). Perhaps there are better tools to achieve the underlying goal (e-mail?)? Or maybe talk pages are best (and will be better with LiquidThreads). It all needs thought. And then there are general issues of who should be able to deliver to who and when consent is needed and all of that. Lots of thought needed!
It's probably best to keep it as a user talk thing for simplicity unless there's a strong argument to the contrary. An extension could maintain user lists based on geographic area, on-wiki projects, and anything else as well as an opt-out list per-sender and globally. The actual delivery could be attributed to the actual sender without flooding recent changes by simply skipping the RC feed. Maintain a log for the extension and post that log to RC, and then post the actual edits to each user talk page asynchronously without adding to the RC feed.
See also https://mingle.corp.wikimedia.org/projects/internationalization/cards/534
Possibly related links: * http://lists.wikimedia.org/pipermail/wikitech-l/2011-June/053908.html * https://www.mediawiki.org/wiki/Echo_(Notifications)
Also possibly related: bug #1066 (cross-wiki talk page notification) and bug #21377 (SiteWideMessages extension for WMF wikis).
I'm going to go ahead and assign this bug to Ryan K. for now, as he and his team have been doing Echo-related work, which seems like the closest work to the topic of this bug. I'm not sure if a global message delivery system will be built into Echo (or Flow?) or if a separate wikifarm-specific extension makes sense here. However, as I watch another targets list begin to grow (in this case, [[m:Global message delivery/Targets/Grants News]]), it occurs to me (yet again) that I simply don't want to be responsible for global message delivery indefinitely. Eventually, we're going to need a better system. Simple Python scripts are great, but they have their limits. And I've long held off on further development of EdwardsBot as I always believed this should be a built-in feature. As I understand it, Echo is currently focused on user notifications. I believe this would be a good next project for the Echo team. Respectfully submitted for consideration.
(In reply to comment #5) > As I understand it, Echo is currently focused on user notifications. I > believe > this would be a good next project for the Echo team. Respectfully submitted > for > consideration. I've added as URL a link to a proposal that might help address the issue by slightly changing the current perspective in Echo.
We definitely want to add support for something like this to Echo. There are a few hard problems to figure out though: 1. How do we make it usable to folks like MZ, but prevent it from becoming a firehose of spam? One option is to provide an opt-in mechanism for specific types of notifications, but then we end up with a list of preferences a mile long. 2. How do we manage content delivery cross-wiki? We don't have any system of cross-wiki preferences. Should content be delivered to every wiki a user is active on? Only their home wiki? Should the user be able to choose? Should we force them to subscribe separately on each wiki? Any thoughts on this are welcome.
I thought Echo was all about providing system-triggered notifications that are more "user friendly", especially for newcomers, than mucking with watchlists and revision histories. (A canonical example of system-generated notification being the old-style "you have new mail" message.) I am straining to see how this fits with EdwardsBot function, which is the delivery of bulk mailings. One possibility would be to post a message in one place, and use Echo to notify a delivery list to check it out. This could mitigate some of the problems with posting multiple copies for all the recipients. However, it would not work for folks who disable Echo notifications, and it would not leave a trail on their talk page for future reference. Note also that mass-mailing is not only useful for user talk; it can also be used, e.g., to post a notice at the Village Pump (or equivalent forum/noticeboard) on multiple wikis. (Use case: advance notice of "breaking changes" in an upcoming mediawiki release.)
You're correct. Echo isn't for watchlist type functionality. The specific case I was thinking of was that people could choose to receive a notification when a new issue of the SignPost is published, rather than having a message posted to their talk page. The notification wouldn't contain any actual content from the SignPost, just a message that it was published and a link to it. This is something of an edge case for potential Echo functionality, but it is something we have considered. I don't expect that we will support anything like this in the initial release, but if we can solve the technical and UI problems with such a feature, it would be a nice alternative to talk page posts for certain cases.
(In reply to comment #9) > This is something of an edge case ... Yes, it could be useful for some purposes, and your Signpost example is consistent with what I was thinking. However, it is not the substitute MZ is seeking for EdwardsBot's bulk mail delivery. It may have been premature to assign this general "(thoughts)" bug to the Echo component, because the functional need is broader than that edge case.
I continue to wonder if this bug is best solved by a relatively simple MediaWiki extension. Extension:Spam or something. Then you would have Special:Spam, which would be your input form. You'd have a subject line and the body text for inputs. Then you press start and the extension queues edits (perhaps in the job queue, maybe). I imagine some code could be cribbed from the GlobalUsage extension. Rather than a wiki page access list, you can use user groups/user permissions that are baked into MediaWiki. Then the only question becomes how to accept input lists. Maybe continue using the wiki page (list of links) model? An extension would allow other wikis to use the same approach. Perhaps a similar extension already exists? Does anyone know? If this approach sounds sane enough (I'm looking for feedback), I'll go ahead and make an RFC and re-purpose this bug a bit and change it back to unassigned. This solution does _not_ resolve the "Signpost"/Echo problem, really (though "The Signpost" would likely use Extension:Spam), but I'm okay with that. (There's a larger "add a subscriptions feature to Echo" bug that's needed, I think.)
(In reply to comment #11) > An extension would allow other wikis to use the same approach. Perhaps a > similar extension already exists? Does anyone know? There's TranslationNotifications, of course.
(In reply to comment #12) > There's TranslationNotifications, of course. https://www.mediawiki.org/wiki/Extension:TranslationNotifications Interesting, I was unaware of this extension. Perhaps it could be forked for this purpose? It seems like it would be fairly simple to do.
Yeah, it looks like TranslationNotifications is fairly similar to what you're asking for.
MZ: If you want to keep this assigned to me, I'm going to repurpose the bug for Echo API functionality. If you want to keep the bug more general, please unassign me. Thanks!
(In reply to comment #15) > MZ: If you want to keep this assigned to me, I'm going to repurpose the bug > for Echo API functionality. If you want to keep the bug more general, please > unassign me. Thanks! I've split out "support user subscriptions in Echo" to bug 43840. I'm un-assigning this bug from you. Sorry about the hassle, but I think, after discussion, there's a clearer direction for this bug now. Thank you (and thanks to the others) for the insightful and helpful comments above. :-)
I believe bug 52723 ("Review and deploy MassMessage extension to Wikimedia wikis") will resolve this bug.
See also the notes at https://www.mediawiki.org/wiki/Movement_broadcasting
Copying Fabrice F., Howie F., and Terry C. on this bug report. It's been suggested at bug 52723 comment 17 and bug 52723 comment 19 that you all may wish to weigh in here. If any of you have thoughts, concerns, etc. after reading through this bug report and related materials, please share. :-)
Fabrice, Howie, or Terry: any thoughts regarding the above?
I'm going to move this bug to Echo, we might not solve all the issues there, but we can get some real headway in a month. A longer explanation will follow.
https://bugzilla.wikimedia.org/show_bug.cgi?id=52723#c28
BTW, I don't echo will ever be able to close the bug itself. But reassigning it to Echo will add it to the sprint backlog. At some point infrastructure for this will be added, and then this bug will be assigned back in a form that is more manageable/achievable.
(In reply to comment #21) > I'm going to move this bug to Echo, we might not solve all the issues there, > but we can get some real headway in a month. A longer explanation will > follow. File your own bug. We already discussed this above. Ryan K., who was actively working on Echo at the time, and I (in consultation with others) decided that Echo was not the best path forward in order to resolve this bug. If you want Echo to have the ability to post to cross-wiki user talk pages, file a separate bug report that you can manage and add to whatever backlog you'd like. This bug is actually a Wikimedia bug that should hopefully be resolved/fixed by the end of this month. Re-classifying it as such.
With MassMessage now deployed to all Wikimedia wikis, this is fixed. :-) Thanks, everyone!
