T275949: Implement topic subscription notification bundling
T275943: Add support for subsection subscriptions
T275881: Don't search for signatures in blockquote elements
T275260: Enabled people to write custom rules for what activity they are notified about
T274215#6845061: Consequences that could emerge when people are able to be more specific about the activity they are and are not made aware of.
T273342: Introduce a way to view all of the topics you are subscribed to
T276990: Ensure duplicate notifications are *not* sent for the same talk page event
Last week, we shared the first new notification feature we will be working on is a way for people to elect to be notified when another person adds a new comment in a specific talk page topic (read: section).
The question we have for you all is: What do you think is important for us to consider as we begin designing and implementing this feature?
Note: you can see more of the details of how we are thinking about implementing this feature in this ticket on Phabricator: T263820.
The idea of being able to more precisely follow particular talk page sections has come up many times over the years.1234
Accordingly, I'm going to tag *some* of the people who have participated in those conversations who we think will have valuable insight to share as the Editing Team begins designing and implementing this functionality:
@Sdkb, @Vriullop, @Mihia, @Another Believer, @Enterprisey, @Xneb20, @Jack who built the house, @Rjclaudio, @Timeshifter, @Drcrazy102, and @Pokéfan95.
---
1. https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2016/Categories/Watchlists#CW2016-R043
2. https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2015/Watchlists#Section_watchlists
3. https://en.wikipedia.org/wiki/User:Enterprisey/section-watchlist.js
4. https://commons.wikimedia.org/wiki/User:Jack_who_built_the_house/Convenient_Discussions
Hmm, since it seems like a pretty straightforward feature (on the user end), I'm not sure I have too many thoughts about considerations to have in mind. The main thing is just building something that works, and that doesn't malfunction in edge cases.
Something that's always good to have in mind is how a technical change might affect editorial culture. On the whole, section watchlisting will be massively convenient, which will make it easier to curate watchlists that reflect what I actually care about. But not getting notified about other discussions on a page I'm monitoring for my own thread might mean slightly less branching out, and fewer replies to threads in some areas. It could also introduce new avenues for abuse, such as someone starting a new section on the same topic because they suspect an opponent is only monitoring the original section and don't want them to notice and reply.
Talk page sections can be fluid, where sometimes they'll be created in a discussion that's already well under way, or sometimes threads on the same topic will be merged. You'll want to make sure section watchlisting can handle this.
This might be a little overly fancy, but sometimes, there are pages where I might want to pay attention only to future sections that meet or exclude particular criteria. For instance, at ITN nominations, some editors might want to only watchlist sections that are not recent deaths, so it'd be really powerful to be able to tell the software "watchlist new sections here if they don't contain |recent death = yes". Or maybe someone put together a photo collage for an article, so they'd want to watchlist new sections for that article with the word collage so they could engage with anyone making suggested changes.
On a more basic level, being able to watchlist pages but not their talk pages is something that I definitely hope gets added with this. Being able to monitor the Teahouse talk page without having my watchlist become a torrent of questions would be very nice.
Thank you for taking the time to share what comes to mind, @Sdkb. A couple of things you said prompted new thoughts and questions. I'm going to quote and reply to each below.
Before that, I wanted to clarify: as we are currently designing it, the new feature we are working on will *not* affect the way the Watchlist functions. Instead, it will introduce a new event for which people can receive notifications about via Echo. If this information brings new thoughts to mind, I'd be keen to hear them. In the meantime, I'm going to respond to the points you raised...
Something that's always good to have in mind is how a technical change might affect editorial culture....not getting notified about other discussions on a page I'm monitoring for my own thread might mean slightly less branching out, and fewer replies to threads in some areas.
Accounting for the unintended consequences increased specificity could have is a great point. I've made a note of this on Phabricator here so we can think through how we might monitor/evaluate the extent to which what you are describing above is happening: T274215#6845061.
One loose idea/metric we could use to track the move: "Of the pages on which people are subscribed to at least one section, how many of those pages do people also have on their watchlists?" <-- if other ideas strike you, please comment them.
It could also introduce new avenues for abuse, such as someone starting a new section on the same topic because they suspect an opponent is only monitoring the original section and don't want them to notice and reply.
Another a good thought. I've also documented this on Phabricator here: T274215#6845061.
Talk page sections can be fluid, where sometimes they'll be created in a discussion that's already well under way, or sometimes threads on the same topic will be merged.
Can you describe this scenario in a bit more detail? Or better yet, link to a page/diff where you've seen what you're describing happen?
This might be a little overly fancy, but sometimes, there are pages where I might want to pay attention only to future sections that meet or exclude particular criteria.
This idea of enabling editors to be able to write custom rules for the kinds of activity they are and are not notified about strikes me as something that could be, as you said, quite "powerful." While it is outside of the scope for what we are able to take on as part of this project, I've created this ticket in Phabricator so we don't lose sight of it: T275260.
Here's a common type of thread merge at WP:VPT. It's a busy enough page that many editors don't really want to watch the whole page.
May I ask how deep a level will the implementation of this feature go? Will there be some backend that will keep data related to sections (sections themselves, not subscriptions, not notifications)?
Because, you know, the biggest issue with watching sections on wikis is that there are absolutely fluid; it's extremely hard to come up with a general solution to tell if two sections as of different revisions, possibly on different pages, are the same section. There can be two sections with the same name on one page, and there can be a section same as some other section on this/other page, but named differently (renamed/moved/archived). If a section is moved to a different page, will it be able to trigger notifications for users who subscribed to it on a different page? That could require backend support.
(Actually, in the respect that sections are fluid, comments are not much different, and I believe @Matma Rex would give you a full insight on that, so I'm not at all sure that conceptually/practically it would make sense to keep such a registry, since if we wanted topics/comments to be perfectly encapsulated and kept in the database in a 1-to-1 fashion, we would reinvent Structured Discussions.)
I can say that in Convenient Discussions, there is a method dedicated to searching for sections on the current page. It uses a number of factors with different weights that add up to a score that should be above a certain threshold:
(This method is used to match sections as of different revisions on the same page in order to notify the user while they have the page open, Convenient Discussions doesn't use it for watching purposes, as there is too much data to keep, and the script currently doesn't rely on any external databases.)
The section's headline may change for obvious reasons, just as the index and the id (but these would help if there are absolutely identical sections on the page, which is sometimes the case with bot-created sections). The first comment's anchor may change because the user edited the comment and added another timestamp or if a bot added its comment under the section's headline (this often happens in Russian Wikipedia, for example) or if there is another comment with the same timestamp on the page. Ancestor chain, which uses headlines, may also change, but is extremely helpful to tell between subsections with the same name.
If too many parameters of a section are altered, we could lose track of it, but also could rightfully ask, should we consider it the same section after all (see Ship of Theseus).
On the fluidity of sections
We plan to identify sections by their anchor and the timestamp of the oldest comment in the section. We're using the oldest comment instead of the first for exactly the reasons you outlined.
The subscription will not depend on the page on which the section is, so it will trigger notifications even if it's moved to another page, or if it's transcluded from another page in the first place.
When two or more sections have identical anchors and timestamps, subscribing to one of them will subscribe you to them all. We expect that to be very rare.
We will parse every edit to detect sections being renamed (this will work together with the code that will parse every edit to detect new comments and send notifications), and update your subscriptions to point to the new name when it happens.
When a section is renamed in some messy way, we might lose track of it still, but at least we'll be able to tell that is has disappeared and maybe send a notification about this or something. We haven't figured out the details yet.
On a registry / database of topics and comments
We're not doing this right now, but we have some vague ideas about a backend structure that would track each comment and section, and allow us to have permanent links that would point to the latest version of the comment/section even if they're archived or deleted. These could be used for sections in your list of subscriptions to find out if the section has been archived or renamed, and for comments in your notifications so that the links in them still work after a few weeks when the comments are archived.
We couldn't "reinvent Structured Discussions" even if we wanted though, because as long as the pages are written in wikitext, comments will sometimes disappear or be indistinguishable from each other. But we think we could make these links pretty reliable.
I have a lot of ideas for testing section-watchlist that are only written in notebooks; I'd be happy to put them up if there's any interest in that. As it is, the diff-handling code is perhaps halfway there (although it covers almost all edits in practice). There are a lot of details.
> the timestamp of the oldest comment in the section
Oh that's a good idea, have updated Convenient Discussions to use it.
Thanks for the explanation. Interesting architecture, seems like it might work. I can recall the cases (rare indeed, but still) where Convenient Discussions failed with similar premises in Russian Wikipedia, apart from bot-created sections that I mentioned:
May I ask about a thing that I'm strongly concerned about—will topic subscription be open to integration with user scripts? The architecture you described looks promising, so there could be no point to keep the section watching functionality in existing tools, including my CD, given that a third-party script (not an extension) would never have the capacity of a native tool with full support from backend. But for user scripts to embrace the native functionality, there should be convenient integration, for example the ability to read and write topic subscriptions using API.
(Actually, I wanted to ask this question in relation to various aspects of DiscussionTools, starting from the JSON for parser data that can be found at mw.loader.moduleRegistry['ext.discussionTools.init'].packageExports['parser/data.json'], but seemingly only after loading and executing Reply Tool—and ending with your planned format for hash links for comments which I will then need to make compatible with CD that currently uses the format yyyymmddhhmm_author[_id], if your format is different. But let's start with this.)
Thanks, it's interesting to think about these corner cases. Right now we only plan to allow subscribing to toplevel sections. The backend could support subscribing to subsections or even to replies to individual comments, but it would be difficult to present this in the interface in an understandable way, so we're giving up on that for now.
We plan to implement all the new functionality by adding API modules for it, and then using them in our tools, so other tools should be able to use them as well (although I can't promise that this will be a stable interface, at least while we're actively working on new things).
I would recommend not accessing stuff inside the 'ext.discussionTools.init' module from your code, we keep changing it in incompatible ways. I'd be happy to make the things in data.json accessible in some other way (some of it already is, this just packages them up in way that's easier for us).
Revision IDs are absolute. Each section (and each reply) could be rendered to include the ID that created it. Each reply could state the revision ID of exactly what they are replying to. Any subscription would be to a specific revision ID - so you could subscribe to any part of a discussion - not just at the top section level. User scripts could highlight specific replies or chains of replies.
Revision IDs would be nice too, but they're not quite the magical solution.
The big obvious problem is that we don't know the revision ID where a section or comment was added. We'd have to go through the previous revisions of the page to find that out (potentially hundreds on an active page like village pump), or have some database that gets updated whenever a section or comment is added (which is something I'd like to work on some day, but it does not currently exist).
Further less obvious problems include: handling reverts, handling revision deletion, handling sections being renamed, handling comments being transcluded from a different page than the one you're viewing, handling edits that add multiple comments… All of this is solvable, but I don't think it's less complex than what we're working on right now.
@Jack who built the house seeing the approach you've taken with Convenient Discussions is helpful – thank you for taking the time to document this.
A follow up question for you, and I suspect @Enterprisey, related to what @Matma Rex shared above: Based on the experiences you've had developing tools for talk pages, how often have you encountered [i] two or more talk page sections that have identical anchors and timestamps?
Context: I ask the above as we weigh the tradeoffs associated with decoupling topics, and by extension comments, from the pages on which they exist. More details in T264885#6859503.
---
i. E.g. 1) you have never seen this happen, 2) you have seen this happen a couple of times, or 3) you have seen this happen on a weekly or monthly basis.
I have never encountered this situation myself, but I designed section-watchlist as if it were possible. As an example, someone could start two RfCs at once, each with a "Support" and "Oppose" section. section-watchlist identifies sections using a combination of anchor and duplicate index, i.e. the index of this section among all sections of the page with the same anchor. Every time a section is renamed, all sections with the same anchor have to be re-identified.
That's a big drawback, so I just thought of another idea: use the parent section's anchor. I think it's just about impossible (among workflows on enwiki) for two sections to have the same anchor and parent anchor.
As a final note, I have thoughts about timestamps, if those end up being used. I think either the first or oldest timestamp should be used, but they both have issues: for the first timestamp, sometimes enwiki inserts another comment above the oldest comment, such as with closing statements or process notes ("this section has been moved from..."). For the oldest timestamp, sometimes people copy/paste older comments into their comment, bringing the timestamps. Even worse, sometimes this happens at the end of a line, in which case the comment is difficult to distinguish from one left naturally. However, searching the first N comments, or taking the first comment where both the previous and next comment have newer timestamps, might be more successful.
It's helpful to know how you have yet to encounter a situation where two talk page sections have the same subject name and have been posted at the same time. We appreciate you thinking about this, @Enterprisey.
As for the "drawback" you are raising and the proposed design to resolve it, I think @Matma Rex is better positioned to add any thoughts, if he has any.
> with the same anchor
Do you mean the same headline? Because sections are assigned unique anchors (the id parameter) by the engine.
> For the oldest timestamp, sometimes people copy/paste older comments into their comment, bringing the timestamps.
Yup, that's a valuable note. Convenient Discussions excludes blockquote tags as well as elements with the classes defined in the wiki configuration from places where signatures should be searched for, but that could not be enough. As I can see, Reply Tool currently places its reply links right in blockquote tags, which I believe should be fixed. Created phab:T275881.
> taking the first comment where both the previous and next comment have newer timestamps
I'm not very familiar with the English Wikipedia customs; is it impossible for a discussion to emerge after the closing statement? Are you sure this method will be reliable? In Ruwiki, we often have multiple bot comments added one after another (for example), but the most recent comment is always added to the top, so your approach would work with that.
> use the parent section's anchor
Convenient Discussions uses the headlines of the whole ancestor chain, as I mentioned above. Imagine the following section structure:
== Proposition title == === Opinions === === Voting === ==== Support ==== ==== Oppose ==== == Other proposition title == === Opinions === === Voting === ==== Support ==== ==== Oppose ====
Using the whole ancestor chain would work with it. Although the project members already said they currently don't plan allowing subscribing to subsections.
Do you mean the same headline?
I'm glad you stopped to confirm, @Jack who built the house. Yes, I meant the "headline"...I think! Copying @Matmarex in case I'm mistaken.
Assuming that in the context of this comment, it would be accurate for us to understand "anchors" as a section's headline/title, how often have you encountered two or more talk page sections that have identical headlines/titles and timestamps?
As I can see, Reply Tool currently places its reply links right in blockquote tags, which I believe should be fixed. Created phab:T275881.
Great spot. Thank you for filing this.
how often have you encountered two or more talk page sections that have identical headlines/titles and timestamps
I'm not sure I can recall top-level sections (== ==) that have identical headlines and timestamps. Perhaps some poorly configured bots could notify a user several times about several subjects with the same headline, but I couldn't find any links with a quick search. I definitely remember my script having problems with renamed sections having the same timestamp, where a rename resulted in the script not being able to identify the section by timestamp alone. This has led me to use more factors for identification.
The cases that I encounter on a regular basis concern subsections, and I described them in this comment.
Peter, you might look at these search results on the English Wikipedia. WikiLove is not very smart about its section headings.
I appreciate being asked for my opinion, but I have long ago given up on meaningful discussion on Mediawiki.org. Because I hate Flow, or whatever this talk page software is on MediaWiki.org. I suggest moving this discussion to English Wikipedia where the talk pages work fine. Except for of course, section notification. :)
The 2nd most important missing notification is interwiki talk section notification in watchlist format. I rarely check the Mediawiki.org watchlist. It's too much trouble. See:
Ping me please if you want a reply. I notice that the ping template is different here too. Grrr.
Watchlist and notification for sections is one of the most appreciated features of Flow. No need to ping to participants, just unwatchlist it if you are not interested anymore. This features in wiki talk pages will be appreciated too.
I would prefer interwiki stacked watchlists. That way I could look at the watchlists when I wanted to. Instead of seeing an annoying pile of push notifications listed at the top of any Wikimedia page I am on. Notifications can't be ignored as easily as with a watchlist. They are harder to scan quickly when there are a lot of notifications. I don't want to remove the pages from the watchlist. By the way, why isn't this indented since I am replying to you, Vriullop? Another problem with Flow.
We appreciate you dropping by to share the thoughts you have, @Timeshifter.
The 2nd most important missing notification is interwiki talk section notification in watchlist format.
Would it be accurate for me to interpret the above as you saying: "One of the most important issues i have with the current watchlist and notification experiences is the inefficiency/frustration/etc. that comes with having to visit multiple projects in order to see all of the activity that is relevant to me."
I ask the above in an effort to make sure I understand the value of en:Wikipedia:Global, cross-wiki, integrated or stacked watchlists and the reason you shared it in this context.
You wrote in your original post "a way for people to elect to be notified when another person adds a new comment in a specific talk page topic (read: section)." I see no notification method that I like for section notification except standard watchlists.
I don't like Special:Notifications except as a last resort. I also don't like m:Special:GlobalWatchlist. It started up recently. I like some features of it. But overall I don't like it. See my Feb 21, 2021 comment in Phabricator T5525. Cross-wiki watchlists concerning it.
For local notifications I would like section notifications to be added to standard watchlists.
I would like cross-wiki notifications (containing those section notifications) to consist mainly of stacked standard watchlists. Basically as cross-wiki templates. See my September 14, 2019 comment in Phabricator T6547: Support cross-wiki template inclusion (transclusion => interwiki templates, etc.).
I would like the option to use Special:Notifications for some section notifications from some wikis. For example; for wikis where I don't want to regularly check their standard watchlists (whether locally or via cross-wiki stacked watchlists).
I wish that notifications for thank you's and pings were added as special entries into standard watchlists. I am talking about for watchlists I check daily, or near daily, such as Wikipedia and the Commons.
@Timeshifter I appreciate you for following up to share this added context; I'm sorry it's taken me until now to respond. A couple of follow up comments and questions in response..
It sounds like you are saying that the Watchlist is the tool you have found most effective for staying up to date about new activity, across projects.
Assuming the above is accurate, a couple of follow up questions for you:
I would like the option to use Special:Notifications for some section notifications from some wikis. For example; for wikis where I don't want to regularly check their standard watchlists (whether locally or via cross-wiki stacked watchlists).
The new feature we are building will enable you to do what you are describing. Would you be up for giving it a try and sharing what you think about it once we have a prototype ready next week?
@PPelberg (WMF). I don't go to Special:Notifications. I only see the notifications at the top of every page. I assume they are the same. Is that Echo? I honestly don't know. I notice that once I mark something as read, then some stuff goes below grayed out), and some stuff disappears. It irritates me. It is not permanent like the watchlist.
I want to go to one page: Stacked collapsed watchlists from English Wikpedia, the Commons, Meta, and Mediawiki. With a table of contents so I can instantly go to any of those 4 collapsed watchlists on the page. For everything possible including thanks, pings, section watchlisting, etc.. I don't want a watchlist to look different on the stacked page versus their source page on their wiki. I want my individual per wiki settings to apply no matter where the watchlist shows up. Different settings for each watchlist. All of those settings are important to me.
As much as possible I would prefer no notifications by any other methods. I don't like being on call. I don't need to instantly see thanks and pings in most cases.
There are times I do want to know rapidly about edits to a thread of interest, or to an article section. Not very often though. I would like to be able to instantly turn on/off notifications for any specific thing. But most of the time I prefer to respond in my own time after occasionally checking a watchlist. If I do turn on notifications for an item, I still want that item to still be listed on the watchlist too.
I will check out the prototype. By the way, thank you and all the developers for all the work you do. Often, you only hear me while I am complaining. And the occasional feature request (often while complaining about a problem it might fix).
What do you think is important for us to consider as we begin designing and implementing this feature? These are just random ideas:
Thank you for coming by to share these thought, @Matěj Suchánek. There are two particular things you said that I wanted to ask a bit more about:
1. The more types get added, the greater chance one action will send more than just one notification to a single user. This may annoy people if it happens regularly.
Interesting point, did you have a particular experience in mind when you wrote the above? Asked another way: have you noticed yourself receiving multiple notifications for the same event?
2. When thinking about notifications, a common question will be: How do I turn them off?
Great point – can you share the aspects of a notification you would expect to be able to control and where you would intuitively look to exert that control?
Did you have a particular experience in mind when you wrote the above? ... have you noticed yourself receiving multiple notifications for the same event? I am certain that I was once pinged by a user on my talk page. You always get a notification about an event on your talk page, you don't really need to get pinged there.
Since pinging in DiscussionTools has become very easy, people will likely ping you (in text or summary) in a discussion you have already subscribed to. Which is somewhat understandable because whether you are subscribed or not is private information (I suppose, just like whether you are watching a page or not).
Can you share the aspects of a notification you would expect to be able to control and where you would intuitively look to exert that control? As I wrote: Watchlist is a well-established feature and everybody is used to use it. In watchlist, I'm able to see the list of pages I am watching and unwatch them in this list. Or I can unwatch them by visiting them and clicking unwatch (the same process as when I want to watch it). You can also enable buttons that allow you to unwatch pages directly from the list of changes to watched pages.
So at least I would expect to see an unsubscribe button where I agreed to subscribe. Individual notifications should also offer this (or take me somewhere where I can unsubscribe.) Additionally, if there was a list of discussions I am subscribed to (which will probably be easy to have but just having it is not enough, people should be able to navigate it using a link in the interface and shouldn't have to remember the name of the page), I would like to be able to unsubscribe in it.
It might be counter-intuitive, though, that notifications are generally managed in the preferences. (And if you choose to have notifications sent to your email, this is where the link in the footer takes you to.) So you might have to have a look at that interface and perhaps indicate there that subscriptions to topics are handled differently (or allow some management there).
In fact, you don't have to completely reinvent the wheel, some of the above works in Flow.
@Matěj Suchánek – these clarifications are helpful...thank you for taking the time to share them and I'm sorry you're just now hearing back from me. A couple of comments in response below.
Since pinging in DiscussionTools has become very easy, people will likely ping you (in text or summary) in a discussion you have already subscribed to.
The risk of duplicate notifications being sent for the reasons you mentioned [i] is a great point. In fact, just yesterday, @Esanders (WMF) was working on a patch to lower the likelihood of this happening. More in: phab:T276990.
I would expect to see an unsubscribe button where I agreed to subscribe. Individual notifications should also offer this (or take me somewhere where I can unsubscribe.)
Understood. As you described, the topic subscription feature will enable you to unsubscribe from conversations in the two places you described above: 1) on the page where you subscribed and 2) on the notification within Echo.
...if there was a list of discussions I am subscribed to (which will probably be easy to have but just having it is not enough, people should be able to navigate it using a link in the interface and shouldn't have to remember the name of the page), I would like to be able to unsubscribe in it.
Being able to visit a single place where you can view and manage all of the conversations you have subscribed to is something we are thinking about. While this is not something that will be offered with this first iteration for the feature it is something we are pay attention to. In case you're curious, the work and thinking about this potential feature is happening in phab:T273342.
In the meantime, can you think of another website or app you use that you think has implemented a feature like this well?
---
i. Talk page edits are more likely to contain pings as a result of DiscussionTools making it easier for people to insert them. Therefore, we can assume new comments are more likely to contain pings. These two things increase the likelihood people could, conceivably, receive two notifications for a single edit: a notification about a ping and a notification about a new comment in a conversation they are subscribed to.
Thanks for your reaction. I'm sorry you're just now hearing back from me. No problem.
In the meantime, can you think of another website or app you use that you think has implemented a feature like this well?
Another issue with topic subscription is what exactly you can subscribe to. If it's only second-level (== ==) sections, that's a correct naming, but if sections of any level are allowed to be subscribed to, then I believe "section subscription" is a better naming.
The ability to subscribe to subsections raises several issues/questions.
=== ===) with Reply Tool and "Subscribe to section" is checked, do you subscribe to the subsection or the parent section?Convenient Discussions answers to these questions "yes", "subsection", "not critical, the user can unsubscribe easily from the section's menu", "not critical, show an alert".
Having these scenarios documented will be helpful if/when support for subsection subscriptions is prioritized – thank you for sharing them, @Jack who built the house!
As @Matma Rex shared above, this initial implementation will enable people to subscribe to H2 level sections.
In the meantime, I've filed T275943 so we can keep a memory of what you've shared here.
A few days ago, I had a big fat red “(99+)” notification indicator in Minerva. The bulk of those notifications were from Structured Discussions on mw-wiki. (Which I have, admittedly, been neglecting.)
I think it is important tor you to consider that subscribing to a long or active discussion topic has the potential to generate a lot of notifications. It may be a challenge to design how to display, group, and mark-as-seen these notices so that they don’t swamp other ones.
Great call, @Pelagic. Are you able to read the Stories section of T275949's task description and comment on the ticket whether you think any edits and/or additions should be made to what I've drafted?
Thanks, @PPelberg (WMF), that covers it for the bundling aspect. But to “triage those notifications” and “feel confident taking an action” I may jump out of the Alerts/Notifications drop-down(s) and go to Special:Notifications.[1] At that point, WAID's observation below about filtering becomes pertinent.
I would like to be able to filter by type of notice: e.g. pings + talk-page posts, just the subscribed topics, new topics on subscribed boards, all wikis except for one high-volume one. Saved filters like those for Recent Changes might be handy.
I like in Minerva how I can tap the filter button and see a side panel with notice counts grouped by wiki and page. I don’t see that in Timeless nor Vector.
[1] You might ask why I feel the drop-down isn’t sufficient, or what is better about the “View all notifications” page, and I’d be hard-pressed to put my finger on why. Maybe the whole-page layout is better for seeing an overview, though for that purpose it could be made more compact. Maybe it’s the filter panel in Minerva.
Bundling (or even filtering, on the Special:Notifications) by type of notification (e.g., all the 'thanks' at once) isn't currently available. I don't know how much work it would take to implement that.
Another thing to keep in mind is that the system only stores your most recent 2,000 notifications (a little more than a year for my work account). That is probably enough, but it is definitely not infinite.
I want to be notified when:
I do not want:
The community requests for section watchlisting includes all pages, not just discussions.
It's helpful to know what expectations you have for what activity you are and are not made aware of, @Alsee. Some comments in response below.
I do not want: To be notified when a comment is made in a watched section.
Understood. A couple of things to note:
I do not want: Hundreds of notifications from watching a large/busy section. Bundling wouldn't solve that, I don't want to be interrupted with a notification or notification-bundle every few minutes for large/busy discussions.
The scenario you are describing sounds disruptive. You raising this is leading me to wonder whether Echo, the system on which topic subscriptions are built, has functionality intended to lower the likelihood of this happening. I'm going to look into this and follow up up with what I find.
In the meantime, a resulting question for you: can you share a link to the kind of "large/busy" conversation you have in mind? I'd like to make sure I have a clear image in mind for what you are describing...
I do not want: I do not want to DATA LOSS of important notifications because the notification limit was quickly blown out by frivolous notifications from a handful of busy sections I want to watch.
Agreed. At no point should people worry they are not being notified about activity they are expecting to be made aware of.
The community requests for section watchlisting includes all pages, not just discussions.
A couple of things: