Last modified: 2014-02-27 06:54:01 UTC
There's no way to remove an item from Special:Notifications, e.g. by marking it read/trashed/spam. This is particularly troubling given the false positives rate of the notifications, but would be a bug in any case. The X icon that appears on hover is not a way to remove the item (as I expected) but rather to change preferences on that kind of item; it's not offered for things that can't be disabled, like talk page notifications.
Special:Notifications is a log of all the notifications you receive. It's not designed to be curatable. (The designers strongly opposed an in-box type model for this.) Most of your interactions with the notifications should theoretically be taking place in the flyout from the red badge icon. That's where it might make more sense to have some remove functionality. Personally, I was thinking that it might be best for the flyout to just show all of your unread notifications (rather than X most recent) and automatically remove them all from the flyout after you close it. There's going to be another meeting on Wednesday to discuss this so let me know if you have any ideas.
I don't see why a user would need a log in a special page. Can't you use Special:Log for that?
I think the idea was to make it more friendly than Special:Log. Plus notifications are private and Special:Log is for public logs.
I've already asked this in the past and heard no clear response: why should notifications be private? I see no reason for it. I'm not saying to kill Special:Notifications, I just think that the read/unread feature you want for the flyout should be mirrored on the special page in the very same way for user experience consistency. The user needing to see the full log of notifications including spam and vandalism is an edge case: logs belong to logs and "replace Special:Log" is an extremely bad requirement for the special page. No logging system duplication should be pursued, or the decision will probably have horrible and catastrophic consequences in the future, see the example of the AFT logs and other superstructures.
Anti-abuse measures are required for any feature of this nature. Not only the ability to remove notifications (or mark them as spam), but also the ability to block or ignore notifications from particular sources. If Echo does not have anti-abuse functionality built-in already, it's a blocker to further deployment.
Sorry, from comment 3 on we're going on a tangent; I moved/clarified my comment at <https://www.mediawiki.org/wiki/Talk:Echo_%28Notifications%29/Feature_requirements#Bad_requirements:_reinventing_logs_and_private_notifications>, we should probably continue there (assuming there's something useful worth discussing in it, of course).
Left some comments at Talk:Echo_(Notifications)/Feature_requirements. Anyway, let's get this bug discussion back on track. What sort of dismiss functionality would you like to see. There are lots of options: 1. No dismiss functionality 2. Dismiss individual notification 3. Dismiss individual notification and present option for dismissing category 4. Present option for dismissing category or individual notification 5. Dismiss category 6. Present option for dismissing category There's also the possibility of dismissing notifications from particular users or regarding particular pages, but we decided that would overly complicate things since we would need to keep track of a lot of 'unsubscription' data for every user and give them preferences for changing all of those decisions (which would create a lot of complicated UX). Also, should there be categories of notifications that are not unsubscribable? Right now there are two: 'System' notifications ("Welcome to Wikipedia", "You've been blocked", "You are now an administrator", etc.) and Talk Page Post notifications. For Talk Page Notifications we allow unsubscribing from email, but not from the web notifications. The thought here is that (1) we wanted to mirror the existing talk page notification system (2) we were worried about people accidentally turning off talk page notifications (3) is there ever a legitimate reason to turn off talk page notifications?
I'm pretty sure this request is about dismissing individual notifications, and I agree that a "dismiss" or "archive" button would be useful. This would make notifs have three states - unread, read and archived. This is already probably known to users (e.g. GMail does this in their interface) and hardly a very complicated concept. Special:Notifications could then have a filter by the state for when one decides they want to see the old notifs one more time.
There are 2 related requests at https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/FAQ#Removing_notifications which I'd summarize as "Dismissing/removing notifications - a way to remove items from the list". It's difficult to tell whether people are requesting these features for just the flyout, and/or the Special:Notifications page. Regarding Bartosz's comment about filters, possibly bug 47093 is related.
Prioritization and scheduling of this bug is tracked on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/199
