Bundling and expiry

Jump to: navigation, search

I think we ought to consider notification expiry as an optional attribute for notifications as well. This would certainly be helpful for notifications about things which are likely to become irrelevant soon. The primary use case here would be any kind of "system messages" (the types of things we might use CentralNotice for). But it might also be an alternative to bundling for high-frequency notifications about watchlist updates, talk page responses, etc. I'm not sure how useful a bundled "There are 345434 edits to 3433 pages on your watchlist" notification is.

Eloquence07:10, 13 January 2012

I agree on the principle, although not everything should expire. For instance, the page gives reverted edits as an example: even after months, when they're no longer in the RC table and in the watchlist, if I've not reviewed the revert, I should be able to know about it. On the other hand, notifications about years-old discussions are probably useless because they're no longer relevant.

With regard to your example, though, I don't understand: is it random, or is this notification system (in the new special page) supposed to replace the watchlist? If this is the case, I suppose it's also meant to serve as a global watchlist?

Nemo17:50, 15 April 2012

Serving as a "global watchlist" isn't the effective purpose of the design but it ends up being a side-effect.

Jorm (WMF) (talk)18:09, 15 April 2012
 

Notification expiry times would be of great assistance to some experiments we're thinking of running in E3. Many potential asks about task recommendations or similar stuff are simply not relevant after very long.

Steven Walling (WMF) • talk23:28, 16 April 2012
 
Personal tools
Namespaces

Variants
Actions
Navigation
Support
Download
Development
Communication
Toolbox