Page MenuHomePhabricator

RfC: Need to merge Notifications and Watchlist or lack thereof
Open, MediumPublic

Description

Summary

Proposal to merge Notifications and Watchlist into one

  • Show items pertaining to both public events (edits) and personal events (thanks).
  • Have a settings pane, similar to what Notifications currently has, except
    • a 'watchlist' column would be added to indicate whether I'd like to get these events piped to my watchlist, and
    • a 'watchlist edits' row would be added so that they could be mailed or "nagged on the web" for me.

Some benefits:

  • Filtering Watchlist like people can filter a Recent Changes list when it's got too many items;
  • Adding and removing pages to watchlist;
  • Filtering a watchlist by namespace;
  • General simplification of our infrastructure

Details

See https://www.mediawiki.org/wiki/Requests_for_comment/Need_to_merge_Notifications_and_Watchlist_or_lack_thereof

Event Timeline

Legoktm created this task.Feb 29 2016, 7:26 AM
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptFeb 29 2016, 7:26 AM
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald Transcript

@Legoktm - thanks for filing this! I'd like to alter the description field of this ticket in a similar way to what I did for T128351: RfC: Notifications in core, but won't have time right now.

@Legoktm - what is the relationship between this RFC and T128351: RfC: Notifications in core?

I'm assuming @Legoktm wants to look into the general concept, not this specific implementation.

This RFC itself has many inaccuracies and out-of-date statements.

"For instance, Notifications was designed to know of things instantly, while nothing on-wiki needs an urgent reaction. Such lack of problem to address is worrying."

There is no "lack of problem". There are plenty of things where an urgent notification is useful (e.g. mentions, user talk page post, etc.), and Echo has received a very positive response due to such notifications.

"Notifications makes the problem worse by showing the number of new Notifications items in an icon."

There are already two icons, and in a little while this will be sorted specifically by urgent/non-urgent (part of what this talks about).

"Due to the above, Notifications drags people back into communicating and editing activities."

Engaging people on the site is a bad thing?

"It's not possible to get web-nagging-echo-style-notifications or email notifications about Watchlist items."

Email notifications for watchlist changes are already available. True, it does not use the same mechanism as Echo.

There is no realistic proposal here. All it essentially says is /merge them together on one page/ and /let people get web notifications and emails about watchlist changes/ (the latter is already possible, the first is not an RFC since there is no realistic proposal).

The biggest problem is that putting them together will drown the Echo notifications for power users. Even if you don't get notifications for watchlist changes (you only see them when you go to Special:NewStuff), Special:NewStuff would still be drowned by watchlist changes, hiding notifications.

Then, there is a proposal to also have web notifications for watchlist changes. I don't think anyone (except maybe the very newest users) wants *every* new edit pushed to them as a notification. To be useful, it should have have intelligent (automatic or explicit) ways to determine what watchlist edit should be pushed, and what should just wait until you explicitly check Special:Watchlist or Special:NewStuff.

This needs much more drafting before meeting about it.

In T128352#2077856, @Mattflaschen wrote:

I'm assuming @Legoktm wants to look into the general concept, not this specific implementation.

Yes, this. I think there is some overlap between the two features that need reconciliation. The main reason I brought it up in T128351: RfC: Notifications in core is because I thought having duplicate/overlapping features would be reason against moving Notifications into core. But as I said in the RfC, I think the benefits outweigh the downsides of having kind-of-duplicate features.

Is the RfC process a good fit for product ideas like this? How do design and research get involved? @jmatazzoni @Pginer-WMF

In T128352#2077856, @Mattflaschen wrote:

I'm assuming @Legoktm wants to look into the general concept, not this specific implementation.

Yes, this. I think there is some overlap between the two features that need reconciliation. The main reason I brought it up in T128351: RfC: Notifications in core is because I thought having duplicate/overlapping features would be reason against moving Notifications into core. But as I said in the RfC, I think the benefits outweigh the downsides of having kind-of-duplicate features.

There's some conceptual overlap (but they're certainly not the same thing). That's already true, though, despite Echo not being in core. I don't see this as a blocker to migrating Echo to core.

Having them in the same repo will make it easier to trim some of the redundancy and unnecessary difference (first, simpler things like a single way of formatting and sending emails, later, maybe a conceptual overhaul).

RobLa-WMF moved this task from Inbox to (unused) on the TechCom-RFC board.Mar 2 2016, 9:36 PM
RobLa-WMF mentioned this in Unknown Object (Event).Apr 13 2016, 6:54 PM
GWicke added a subscriber: GWicke.EditedApr 14 2016, 12:14 AM

I like the general idea of unifying event representations and -listings. A similar approach might also be useful in the context of page histories.

@Legoktm, do you think prioritizing this discussion now would be useful, and if so, who else should be involved?

RobLa-WMF mentioned this in Unknown Object (Event).Apr 20 2016, 6:43 AM

I think this is an important idea. I agree that there is overlap and the potential for confusion between Watchlist and Notifications. It's logical to want to bridge the gulf between the two systems. There are however, many problems that would need to be solved in the course of working this out.

One is that the notifications system is not designed for the type of volume that even a moderately active watchlist could generate. Without implementing a series of controls, we could easily create a system that overwhelms users. So, that means we'd need make each watchlist entry controllable via settings, teach users to manage the settings, implement the ability to mute Notifications on a per-page and probably per-notification-type basis, etc. etc. All of which is possible, but the design, implementation, testing, etc. of which is far from trivial.

TechCom spoke about this briefly at E223, noting the lack of assigned priority (and lack of a shepherd). We also talked about how this was something that is broader than just an TechCom task (due to the product and usability concerns). So, I followed up with a brief impromptu conversation with @aripstra and @DannyH to figure out next steps.

There's certainly a fear of going too far with merging everything together. It might be useful to figure out a proposed roadmap for this. @Gryllida, is this an RFC you are still interested in? @Legoktm, how about you?

There's certainly a fear of going too far with merging everything together. It might be useful to figure out a proposed roadmap for this.

Please keep the Collaboration team (including our PM, @jmatazzoni), in the loop as well when this is discussed, since we develop Echo.

There is strong overlap between some of these ideas, and the ideas in T3492: Multiple watchlists / T1352: RFC: Support for user-specific page lists in core.
Specifically, the idea of "a 'watchlist edits' row would be added so that they could be mailed or "nagged on the web" for me."

IIUC, we're currently working towards a way for watchlists to have an additional database column that contains a 'name', which can thus be used for things like Multiple Watchlists, and hence for things like assigning different priorities&effects to each.
(Postulating tangent: E.g. My hypothetical "ultra important page list" could be configured to send me an email for every edit; and my "interesting but noisy page list" of village pumps and noticeboards could have a grey font-color in my watchlist (via user.css or something) so that I can ignore them more easily.)
I made a napkin sketch of one possible UI direction, at M179, a year or 2 ago.

Multiple watchlists, and T5525: Cross-wiki watchlists, and the various enhancements that can be made based on those 2 upgrades, should all be being planned together.

I do like the sound of a watchlist that is similar to recentchanges, with all my interests/info/feeds in one place, but where filters can be applied to selectively show/hide any sub-sets thereof. :-)

RobLa-WMF triaged this task as Medium priority.Jul 27 2016, 8:14 PM

Priority set in E236

Krinkle moved this task from (unused) to Under discussion on the TechCom-RFC board.
Krinkle updated the task description. (Show Details)Jan 10 2018, 5:37 PM
kchapman moved this task from Under discussion to Backlog on the TechCom-RFC board.Mar 9 2018, 9:01 PM
kchapman added a subscriber: kchapman.

Needs resourcing and then the conversation can continue on the "how" of the RFC. Going to TechCom-RFC backlog for now.

Untagging TechCom as remains more of a product decision and not a RFC

Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 22 2019, 5:00 PM
JTannerWMF added a subscriber: JTannerWMF.

The Growth-Team is focused on GrowthExperiments at this time.