Talk:Talk pages project/Notifications

Channel parity

T263820: Use case #2: Subscribing to topics

It's absolutely essential that there is parity of functionality across all of the ways that editors can contribute. I was floored recently to learn that the iOS (Wikipedia) app doesn't notify users when they receive a talk page message or another notification. Collaboration is absolutely integral to all of our projects - so whatever features are recommended here, they have to be implemented across all of our channels - iOS app, Android, mobile browser, desktop browser, and anything else I might be missing. Best, Darren. Darren-M (talk) 01:24, 23 January 2021 (UTC)

Strongly concur with Darren-M. This even has dispute-resolution and sanctions implications, since timely response is expected and failure to make it can be seen as damning/recalictrant. Also, on en.WP, admins are expected as part of WP:ADMINACCT policy to respond to questions and concerns about their administrative actions in a timely manner.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:14, 24 January 2021 (UTC)

Collaboration is absolutely integral to all of our projects - so whatever features are recommended here, they have to be implemented across all of our channels - iOS app, Android, mobile browser, desktop browser, and anything else I might be missing

This is a key point; I'm glad you took the time to stop by and mention it @Darren-M .

We still have some research to do before I can confidently say whether we'll be able to offer the notification improvements to the apps at the same time we'll be able to offer them on the web (desktop and mobile).

I am going to follow up in this thread once I know with more certainty what platforms we'll be able to offer support for at the outset.

In the meantime, if you're curious, the thinking we are doing about the first notification improvement we're going to offer (subscription to specific topics) is happening in this ticket: T263820. Note: "Open questions" #1 and #2. PPelberg (WMF) (talk) 02:38, 23 January 2021 (UTC)

Just so everyone knows, the iOS team is actively working on notifications (and has been doing so for a while). Johan (WMF) (talk) 20:52, 8 February 2021 (UTC)

@Johan (WMF) this is helpful context – thank you for dropping by to let us know as much. Can you recommend a link where we can learn more about this notification work? My first instinct was to review Wikimedia Apps/Team/iOS... PPelberg (WMF) (talk) 02:41, 10 February 2021 (UTC)

There's a scattering of Phabricator tasks, but no epic task (for those unfamiliar with Phabricator: it's the task management system used for the technical development of the Wikimedia wikis. An epic task can be described as a long-term task which collects all smaller tasks about a major undertaking, like getting notifications in this case) as of yet. There will be one soon. Johan (WMF) (talk) 15:21, 10 February 2021 (UTC)

(In short: no. There should be, but there isn't. But there will be soon.) Johan (WMF) (talk) 15:22, 10 February 2021 (UTC)

Inbox

I wish I have an inbox for Notifications, and especially for new messages. A central place where I can find back pings, messages on my talk page, or messages posted on pages I watch. Maybe Special:Notifications needs more love? Trizek ^{from FR} 20:57, 23 January 2021 (UTC)

A central place where I can find back pings, messages on my talk page, or messages posted on pages I watch.

@Trizek: can you share a bit more about what prompted you to suggest the above? Asked a different way: what do you find difficult/frustrating/confusing/etc. about the existing ways available for knowing when someone is talking to you? PPelberg (WMF) (talk) 00:06, 30 January 2021 (UTC)

A long list of notifications can be difficult to check. And it is even more difficult when I look for a ping from a while ago.

I find frustrating to check my watchlist and miss discussions there. I can filter them, but it is not really the usual behavior I can observe. And I find very frustrating to have a gigantic diff to check for some talk pages while I'm only interested one particular discussion.

Well, now that you ask, it seems that my complains aren't around Special:Notifications, but more around how to link discussions to the real word (aka one with permalinks for each comments, and ways to connect them to the human being who receives them). Trizek ^{from FR} 23:37, 30 January 2021 (UTC)

Flow's original design included a central "feed" that would make it easier to find, sort, and manage notifications and ongoing conversations and other notifications (e.g., the Articles for Deletion discussion has reached its minimum time limit). It was never built. High-volume editors (e.g., me) would benefit from something like that. Special:Notifications does some of this, within some limits. One of those limits is that it only stores the most recent 2,000 notifications. In my case, 2,000 notifications ago on this wiki was somewhere in the middle of "A memorable talk page experience" about 15 months ago. Whatamidoing (WMF) (talk) 19:02, 8 February 2021 (UTC)

General point: separation of content from discussion

One thing that's bugged me about MW from day one is failure to separate the content (encyclopedia article, policy page, etc.) from the talk page about it in the watchlist system, at least without jumping through filtering hoops. They're really very different things from a human perspective. I would much rather be able to "subscribe" to a thread or an entire talk page, and have a discussions widget in the menu that showed me that stuff separately, and then be able to pare my watchlist down to nothing but content pages, and maybe a tiny handful of talk pages to explicitly treat as watchlist items for tracking any edits at all, e.g. ones that serve the purpose of noticeboards, or which are presently undergoing disruptive antics.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:17, 24 January 2021 (UTC)

+1 -- Nemo ^Discuter 19:54, 25 January 2021 (UTC)

One thing that's bugged me about MW from day one is failure to separate the content (encyclopedia article, policy page, etc.) from the talk page about it in the watchlist system...They're really very different things from a human perspective...

This is a sharp point, @SMcCandlish. Can you please expand on the differences between how you think about and what you need in a system for staying up to date about changes to content you are interested in and becoming aware of new activity in conversations you are interested in?

---

Meta: you bringing attention to the distinction between content and discussion comes at a great time for we are thinking about this very point. More to come in the new topic I will be starting shortly. PPelberg (WMF) (talk) 00:12, 30 January 2021 (UTC)

Well, what I'm thinking of is the interface widgets at page-top: the alert/notice icons. Presently they're a random mix of content and communications-related stuff (in both of the icons). I would rather have one, maybe with an icon of heads talking to each other, that is all about talk-page activity (probably including pages not in talk namespace that have been configured to behave as talk pages, such as administrative noticeboards); and another one that is all about content (maybe with a pencil icon or something). The current "bell" and "letter tray" (I think) icons aren't really meaningful.

What we have now, at en.WP, is an Alerts icon, which has a bit of a confused purpose, showing pings (communications/messaging stuff), posts to one's own user talk page (comms), failed pings by you (meta-comms), reverts (content), "you've got e-mail" notices (comms), and I'm not sure what else.

Then we also have a Notices icon, which shows Thanks (comms), "The page X was connected to the WikiData item Y" (meta-content), notices that a page has been Reviewed (meta-content), and I'm not sure what else.

Very confusingly, both of these icons have "All notifications" and "Preferences" controls, that go to the same pages! And there is no way to determine which of the two categories any of these things should be in, and there are very few of them, mostly of weird stuff the average editor doesn't feel a strong urge to be notified about.

I think this is hopelessly muddled. My guess is that the idea was to use "Alerts" for "stuff we think you'll consider important" and "Notices" for "stuff we don't think you'll care much about", but this is wrongheaded, since different users care about different things, and there is no reason to have an interface widget devoted to non-important stuff anyway.

It would make much more sense to divide these between communications/messaging in one icon, and content plus meta-control of content, in another, with separate "all notifications" trackers and separate preferences. E.g., I might want to exclude Reviewed notices entirely, and mark WikiData notices as high-priority, and so on.

Then add ability to track more things to each, e.g. to "subscribe" to notices of new posts (something with a new sig and timestamp) to a talk page or even a specific thread at one, on the communication side. Or be notified of any changes at all to the content of a certain non-talk page. And whatever. I'm sure different people could come up with a dozen different things. One could start by seeing what the watchlists already have as options, and working them into the notification system as things that can be selected for notifications.

This would not make the watchlist obsolete. I have thousands of watchlisted pages, and if I'm in "Today is Watchlist Day" mode, I may spend all day poring over non-minor edits at all the billiards articles I'm tracking, or whatever. It's a convenient tool for many things, especially when one learns its filtering capabilities. But it is not a notifications system; it's a destination ones goes to. The extant notification system is mostly showing you reverts and pings and user-talk posts in one tab (i.e., that which is likely to trigger an adrenalin spurt!) and trivia we do not actually usually need any kind of interruptive notification of at all in the other icon. It would be better for both if important (not just potentially alarming) stuff could be made to produce continual streams in both icons, one focused on inter-editor communication and one focused on non-talk content (articles and policypages, basically). I would like these to be active all day long, not with rare blips in them.

This is not the only site with problems in this area. E.g. NexusMods.com has a single notifications icon, and it commingles mod upgrade notices (content) with notices that people have replied to your forum posts (comms), which is very unhelpful and frustrating.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:34, 8 February 2021 (UTC)

Are you still using the defaults at https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-echo ? Whatamidoing (WMF) (talk) 22:28, 10 February 2021 (UTC)

No, I have web notifications turned on for everything except "Successful mention" (which is the most pointless option in there), and "Page link" which would drive me nuts.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:59, 11 February 2021 (UTC)

The detail you shared in the comment above has helped me to more clearly imagine the frustration and confusion you alluded to in the original post – thank you for taking the time to write out this thinking.

Before responding to the suggestions you raised, I'd like to try articulating the issue you raised in my own words to make sure I've understood them correctly and then ask a follow up question in response...

Issue you raised

You find the purposes of Alerts and Notices to be unclear because the two icons/systems deliver similar notifications [i] and offer similar functionality.[ii]

Follow up question

@SMcCandlish, can you share what impact the current Alerts and Notices experiences have on you? For example, what do you feel/think when you arrive on wiki and notice the Alerts and Notices icons are illuminated?

---

i. Alerts and Notices both deliver notifications about "meta" events. In the case of Alerts, you are shown a notification when a ping you attempt to make fails. In the case of Notices, you are shown a notification when a page you created was reviewed).

ii. The Alerts and Notices "drop downs" both contain controls for "All notifications" and "Preferences" PPelberg (WMF) (talk) 01:11, 13 February 2021 (UTC)

I don't think that really got at the issue. More like the following, with the most important points emphasized:

• I find the utility of the Alerts and Notices interface options low, and their purposes unclear, because:
  • The two icons/systems deliver similar notifications and functionality.
  • They each commingle communications-related and content-related notices, instead of there being a clear division between them.
  • Their current division into two interface widgets appears to be on a basis of prioritization/importance, but that entire notion is hopelessly subjective, and is variable not just between editors but from day to day, even hour to hour, for a particular editor.
  • And There are too few notification options, and too few of the ones available now are very meaningful to most editors, especially compared to the filtering options available in the Watchlist.
• But the Watchlist is not a notification system; it's a tool we can manually go to and manually filter. (Though, yes, there is an option to generate e-mail from it, if you want to be extra-mega-super-notified by a firehose of watchlist messages!)
  • The Watchlist and the Notifications systems need to get integrated/related better so that anything the Watchlist can track is something the Notifications system can notify about, and anything the Notifications system can track (that has anything to do with wikitext, in a content or a talk namespace) should also be a filtration option in the Watchlist.
  • If this were the case, then the Watchlist could even have options to turn a filtration option into a Notificiation type (automatically sorted as Content or Communications, depending on the page type to which they pertain). That's a pretty big feature idea, though. Still, it won't even be possible under the current system.
• As a side matter, the Alerts and Notices interfaces both contain controls for "All Notifications" and "Preferences", but these are not actually divided between Alerts and Notices. "All Notifications" just dumps all Notices and all Alerts into one list, and "Preferences" does not distinguish in any way between which widget (Alerts or Notices) each of the few available options relates to.
  • Rather than fix this to separately control "Notices" and "Alerts", it would be better to have one interface widget for Communications messages and one widget for Content messages, instead of two widgets for a random and arbitrary mixture of both. The present ones, as far as we can tell, are distinguished and sorted only by the developers' guesses as to what they think an editor "should" think is important versus trivial. That is a non-useful approach because it is subjective and variable, and because if a type of notice really was categorically trivial, there would be no need to receive immediate notices about it, ever. That is, under the current division/sorting of these things, the "Notices" icon has no reason to even exist.
  • If a Content/Communications split, instead of an Alert/Notice split, were the new way it worked, then "All Notifications" and "Preferences" not distinguishing two notification types would become moot, because they would inherently already be distinguished as content vs. communications in nature, instead of needing to be artificially distinguished by some kind of prioritization guess.
  • PS: I don't care what they're called. It could be "Content Notices" and "Messaging Notices", or whatever. I think I suggested a pencil-and-paper icon for the one, and talking cartoon heads for the other, but I don't feel strongly about it.

To answer your direct question:

• When I see that the "Notices" icon wants attention, I'm annoyed that there's probably-pointless junk I'm being notified about, though there is a chance it's a "Thank" in there which would be pleasant news. But I feel compelled to check it anyway, because there may be some WikiData thing that needs examination. Most of them don't (from my perspective), but some of them do, e.g. if they have possible w:en:WP:BLP implications. So, I can't really completely ignore this icon if I'm not in the mood for communications/social stuff.
• When I see the "Alerts" icon turn active, I usually have an adrenalin spurt and can feel my blood pressure rise. Odds are that it is one of three things: I got reverted (and given my experience level, there's about an 80% chance that was a bone-headed move and I'm going to have to explain to someone why they're being a bonehead); someone has posted to my talk page, which is probably "drama"; or I have been pinged to a discussion, which is probably more drama. This bell icon is kind of apt, in a sense, because this icon going off does act like an startling and annoying alarm. (That might be less the case for someone who studiously avoids noticeboards and high-controversy topic areas.)

So, my thoughts and feelings about both icons are basically negative, on a daily basis.

It would be much better if we had one icon for communications-related stuff – and more things to track in that category, like posts to talk pages or even specific threads, that we want to track, plus social stuff like Thanks, e-mail notices, ping fail/success (if anyone even wants to track the latter), and so on. Then have a separate one for content-related stuff, again with more options – like "any non-trivial, non-bot changes to this page", "any changes at all to that page", "any anonymous IP changes to that other page", WikiData notices, Reviewed notices (which I would turn off, though others might want urgently to see those, especially if they work a lot on creating new articles), page moves/renames, listings for deletion, etc.

There are all kinds of things that conceivably could be tracked here. E.g., as someone with the Template-editor bit, I would like to see when a w:en:Template:Edit template-protected is used, anywhere (as a Communications-category notification, since they always go on talk pages). I have a thing at the top of my en.Wikipedia talk page that shows me these things, via a bot (but also mixes in tracking of changes to protection level at templates). But it would be better if these were available as Notifications, so I and other TE's would be inspired to act on them more promptly (I've seen it take over a week for one to be answered). Admins have even more categories of things like this that they could track this way, and it would be much more practical with Content/Comms split.

If we had these two Content vs. Comms categories of notices, and they were a mix of priority/importance/urgency (perhaps with different-colored bullets or something? maybe there could be a way to set priority levels on them in the preferences), from very important to just not-quite-trivial, then both icons would be useful every day (especially if they could be sorted to show most recent, the present only options, or also most urgent). Neither of them would inspire dread or annoyance, since the majority of both of them would be routine but also useful, and clearly split between "something is going on with content I'm tracking" vs. "someone or some thread may need input from me".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:19, 13 February 2021 (UTC)

I was just wondering about the opposite. There's a setting in the watchlist (one I don't use) that shows every edit to a page separately (I prefer seeing only the most recent). If you use the "expanded" list, you can see all the edits in reverse chronological order, or you can have them grouped by page. I was wondering whether that grouping should include the talk page, so that you could see the recent changes to the article right next to the recent changes to its talk page. Whatamidoing (WMF) (talk) 19:34, 8 February 2021 (UTC)

That could also be cool, for sure, as a feature to use sometimes. What I was getting at, really, is default behavior of the WL, and an interface widget devoted to discussion tracking. I don't want to reduce the possibilities in any way.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:07, 8 February 2021 (UTC)

Attirer les gens sur une discussion

T273343: Introduce a way for people to see the new activity in conversations related to a particular topic(s) in one place T273341: Introduce permalinks for talk page topics

Bonjour, j'ai identifié un problème qui arrive souvent sur Wikipédia

1. Quelqu'un lance un sujet sur une page de discussion.
2. Cette dernière n'est pas très suivie donc personne ne lui répond.
3. Des groupes de contributeurs tel que des projets pourraient être intéressé par le sujet

Il faudrait avoir un système pour suivre les discussions plus efficacement que la liste de suivi actuelle, et permettre de trier les discussions par thèmatique. Ça rejoint « T263820: Use case #2: Subscribing to topics ». Individuelement, on pourrait avoir une sorte de boite de réception cf ici, dans le style de la page d'accueil. Voir aussi w:wp:dashboard.

Aussi, les pages de discussions centralisés sont régulièrement archivé, et donc les liens sont à chaque fois obsolète ce qui n'est pas pratique pour référencer une discussion. (Il faudrait idéalement un lien permanent). -- Nemo ^Discuter 20:16, 25 January 2021 (UTC)

Allo, @Nemo Le Poisson. Je suis heureux que vous soyez venu ici pour partager ces commentaires! Je parle un petit peu de français, alors j'espère que ce que je dis est clair. (j'ai utilisé une traduction automatique aussi). Je vais également répondre en anglais au cas où @Trizek pourrait vérifier que j'ai du sens :)

Quelqu'un lance une discussion sur une page de discussion.

Cette dernière n'est pas très suivie donc personne ne lui répond.

Des groupes de contributeurs tel que des projets pourraient être intéressé par le sujet

Je suis curieux: remarquez-vous que cela se produit sur certaines pages plus que sur d'autres?

Individuelement, on pourrait avoir une sorte de boite de réception cf ici, dans le style de la page d'accueil. Voir aussi w:wp:dashboard.

Il semble qu'il pourrait être très utile de permettre aux personnes intéressées par des sujets particuliers de voir plus facilement la nouvelle activité dans les conversations qui y sont liées. J'ai créé cette tâche où nous pouvons approfondir cette idée: T273343.

Au fait, c'est la première fois que je vois ce lien - merci de le partager!

Aussi, les pages de discussions centralisés sont régulièrement archivé, et donc les liens sont à chaque fois obsolète ce qui n'est pas pratique pour référencer une discussion. (Il faudrait idéalement un lien permanent).

Bonne idée; j'ai créé une tâche pour cette idée: T273341.

---

Quelqu'un lance une discussion sur une page de discussion.

Cette dernière n'est pas très suivie donc personne ne lui répond.

Des groupes de contributeurs tel que des projets pourraient être intéressé par le sujet

I'm curious: do you notice that this happens on some pages more than others?

Individuelement, on pourrait avoir une sorte de boite de réception cf ici, dans le style de la page d'accueil. Voir aussi w:wp:dashboard.

This sounds like there could be a lot of value in making it easier for people interested in particular topics to see the new activity in the conversations related to them. I have created this task where we can consider this idea further: T273343.

By the way, this is the first time I am seeing wp:dashboard – thank you sharing it!

Aussi, les pages de discussions centralisés sont régulièrement archivé, et donc les liens sont à chaque fois obsolète ce qui n'est pas pratique pour référencer une discussion. (Il faudrait idéalement un lien permanent).

Good idea; I've created a ticket for this idea: T273341. PPelberg (WMF) (talk) 01:25, 30 January 2021 (UTC)

Merci pour votre retour et les tâches Phabricator lancées. Je peux moi aussi traduire vos messages de l'anglais vers le français, comme ça on fait tous un effort, comme vous préférez :)

Au sujet des message "abandonnés", je dirais que ça arrive plus souvent sur des sujets d'articles moins "grand public", des ébauches... Seul le créateur de l'article suit par défaut son article. Si quelqu'un d'autre veut suivre les nouvelles discussions, il est obligé de suivre aussi chaque contributions de l'article associé, ce qui peut-être rebutant si on veut pas trop surcharger sa liste de suivi. Peut-être une fonction pour suivre uniquement la page de discussion ou lorsque quelqu’un lance un nouveau sujet ?

Pour comparer les lacunes flow-wikicode, on peut prendre Wikipédia:Forum des nouveaux. Chaque semaine, jusqu'à 80 nouveaux lancent un nouveau sujet de discussion. Si c'était en wikicode :

• Il faudrait archiver très souvent la page pour que ça ne devienne pas une "usine à gaz". Les nouveaux risqueraient de ne pas retrouver leur message.
• Si on prend en charge une demande, impossible de suivre uniquement cette discussion. Et les nouveaux ne maîtrisent pas forcément le système de mention.
• La discussion peut ensuite être conservé via un lien sur la page de discussion d'un article-qu’un nouveau a créé. Aucun risque que ce lien soit invalide et seule cette discussion est affichée, elle n'est pas noyée dans d'autres discussions sans rapport.

Voilà, ceci pour expliquer les avantages de Flow pour attirer les gens sur une discussion, même si le wikicode a l'avantages de respecter la structure d'un wiki. -- Nemo ^Discuter 09:44, 2 February 2021 (UTC)

Enable Wikipedia projects to watch Talk pages

A chronic problem exists with the Talk pages of many articles that lack watchers: someone posts a comment on one, & it will go unnoticed for days, sometimes even years. (Yes, I know of one instance of years elapsing between a comment & a response.) This lack of a response not only discourages new editors, but makes it hard for veteran editors to monitor these pages.

I have a possible solution: set up a script or bot that will watch the Talk pages of articles tagged by active Wikiprojects, & update those changes to a subpage of that Wikiproject.

I have no idea how difficult this would be to code, but I know it is possible. Individuals can & do watch selected articles. And whenever a given article on en.wikipedia is nominated for GA, FA or deletion, a bot updates an "Alert page." Llywrch (talk) 18:46, 29 January 2021 (UTC)

...someone posts a comment on one, & it will go unnoticed for days, sometimes even years...This lack of a response not only discourages new editors, but makes it hard for veteran editors to monitor these pages.

It was encouraging to read the comment you posted, @Llywrch. Specifically, the bit I've quoted above. Reason being: a key objective of the Notifications portion of the Talk pages project is increasing the likelihood people receive timely and relevant responses to what they are saying.

I have a possible solution: set up a script or bot that will watch the Talk pages of articles tagged by active Wikiprojects, & update those changes to a subpage of that Wikiproject.

Now, as to what solutions could be effective in causing people to receive more timely and relevant responses to what they are saying, this idea you are raising of making it easier for people interested in a particular topic area to view the new conversation activity on pages related to that topic area seems like it could be valuable...have you seen anything that resembles the functionality you have in mind already implemented on-wiki?

So you're aware, I'm asking that in case there'd be a quick way for us to see how something like what you are describing could work and how people are engaging with it. PPelberg (WMF) (talk) 00:28, 30 January 2021 (UTC)

WikiProject Medicine does something sort of like this. See w:en:Wikipedia:WikiProject Medicine/Lists of pages to pick a page, and then you run Special:RecentChangesLinked on the page you picked. You can filter the results, e.g., like this, to focus on talk pages. (This link uses a shorter list of more general articles, for editors with 10–500 edits, on talk pages only.) Whatamidoing (WMF) (talk) 19:30, 8 February 2021 (UTC)

First feature: subscribing to topics

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. PPelberg (WMF) (talk) 01:16, 13 February 2021 (UTC)

The idea of being able to more precisely follow particular talk page sections has come up many times over the years.¹²³⁴

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 PPelberg (WMF) (talk) 01:29, 13 February 2021 (UTC)

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. Sdkb ^talk 02:37, 13 February 2021 (UTC)

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. PPelberg (WMF) (talk) 02:38, 20 February 2021 (UTC)

Here's a diff of splitting out a new section, and here's one of merging. Sdkb ^talk 03:52, 20 February 2021 (UTC)

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. Whatamidoing (WMF) (talk) 00:13, 23 February 2021 (UTC)

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:

• headline
• anchor (id)
• ancestor chain
• first comment's anchor (id) (date + author + index)
• index on the page (lowest weight)

(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). Jack who built the house (talk) 04:04, 13 February 2021 (UTC)

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. Matma Rex (talk) 18:23, 13 February 2021 (UTC)

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. Enterprisey (talk) 00:22, 22 February 2021 (UTC)

> 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:

• We have an "Administrators' noticeboard" page, and admins who close requests would usually create a subsection and call it "Result". If an admin decides to close multiple requests at once or within a minute, two sections with the same name and oldest timestamp may be created. In this case, looking for the section's ancestors would help. Of course, if you plan to consider subsections subscribable at all.
• On RfC/polling pages, there are often subsections pre-created for users to comment/vote in support/opposition to some idea, simply called "For" and "Against" or something like that. First of all, initially these sections are empty, with no signatures at all, so I'm curious how you will deal with such sections. When first comments/votes appear in such sections, multiple sections often have identical signatures.

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.) Jack who built the house (talk) 02:59, 19 February 2021 (UTC)

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). Matma Rex (talk) 15:46, 19 February 2021 (UTC)

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. — GhostInTheMachine ^{talk to me} 10:36, 19 February 2021 (UTC)

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. Matma Rex (talk) 15:55, 19 February 2021 (UTC)

@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. PPelberg (WMF) (talk) 04:22, 26 February 2021 (UTC)

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. Enterprisey (talk) 05:46, 26 February 2021 (UTC)

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. PPelberg (WMF) (talk) 00:10, 27 February 2021 (UTC)

> 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. Jack who built the house (talk) 14:36, 26 February 2021 (UTC)

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. PPelberg (WMF) (talk) 00:16, 27 February 2021 (UTC)

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. Jack who built the house (talk) 03:03, 27 February 2021 (UTC)

Understood, okay. Thank you, @Jack who built the house. PPelberg (WMF) (talk) 01:15, 5 March 2021 (UTC)

Peter, you might look at these search results on the English Wikipedia. WikiLove is not very smart about its section headings. Whatamidoing (WMF) (talk) 18:46, 5 March 2021 (UTC)

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:

• Wikipedia:Global, cross-wiki, integrated or stacked watchlists. - Interwiki talk page notification.

Ping me please if you want a reply. I notice that the ping template is different here too. Grrr. Timeshifter (talk) 05:48, 13 February 2021 (UTC)

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. Vriullop (talk) 16:46, 13 February 2021 (UTC)

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. Timeshifter (talk) 17:45, 13 February 2021 (UTC)

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. PPelberg (WMF) (talk) 00:22, 27 February 2021 (UTC)

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 (talk) 02:38, 27 February 2021 (UTC)

@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..

===Question===

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:

1. What – in your mind – are the kinds of updates (broadly defined) you would like to be notified about via Echo?
2. Can you pinpoint what leads you to dislike Special:Notifications?

===Comment===

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) (talk) 00:38, 27 March 2021 (UTC)

@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). Timeshifter (talk) 03:34, 27 March 2021 (UTC)

What do you think is important for us to consider as we begin designing and implementing this feature?

These are just random ideas:

• Watchlist is a well-established feature and everybody is used to use it. However, it is not much flexible for the developers, and it's very hard to enhance it with a new feature (like the recent watchlist expiry). On the other hand, notification management is very easy (for either side).
• Watchlists and notifications sometimes duplicate each other and the new topic subscriptions will certainly do, too. But I wouldn't call it a problem. As I wrote above, changing the way how watchlists work won't be an option for you.
• There are already many types of notifications. 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.
• When thinking about notifications, a common question will be: How do I turn them off?
• Besides, telling the user what happens when they post a comment or giving them the possibility to choose would also be nice. Matěj Suchánek (talk) 10:55, 13 February 2021 (UTC)

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? PPelberg (WMF) (talk) 00:39, 27 February 2021 (UTC)

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 (talk) 14:46, 27 February 2021 (UTC)

@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. PPelberg (WMF) (talk) 00:56, 27 March 2021 (UTC)

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?

• In Flow / Structured Discussions, the management of subscriptions to topics is shared with the general watchlist management. Not bad. It even avoids those magic Topic:W3c084ihivgkm9vt keys, which don't tell much.
• In (Wikimedia) Phabricator, this is integrated into its general structured search which is definitely not so convenient. Note that you can see all subscriptions by anyone (like me), but this is probably a no no for Wikimedia wikis.
• I was pondering for a while if GitHub offers a similar feature, but I don't know.
• Similarly for Stack Overflow but I'm not an active contributor there (only a frequent consumer :)).
• And of course, I was also thinking about Facebook for a while, but I'm not using it actively now and don't remember. Matěj Suchánek (talk) 11:18, 27 March 2021 (UTC)

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.

1. If you subscribe to a section, should a new comment in a subsection of that section trigger a notification? If yes, this makes it impossible to get notified about comments only in the first chunk of the section (its content before the first subsection).
2. What happens if you reply in a subsection (=== ===) with Reply Tool and "Subscribe to section" is checked, do you subscribe to the subsection or the parent section?
3. In the same situation, what if you're subscribed to a section and want to unsubscribe? If you answered "subsection" to the previous question, you won't be able to do it from the comment form.
4. And if you want to subscribe to the subsection instead, there would be a duplication which may seem unnecessary. Also, if you're subscribed both to a section and its subsection and then unsubscribe from a subsection, the user should get some alert that they still watch the subsection via the section. Probably the other way around too.

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". Jack who built the house (talk) 13:17, 13 February 2021 (UTC)

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. PPelberg (WMF) (talk) 00:51, 27 February 2021 (UTC)

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. Pelagic (talk) 09:05, 17 February 2021 (UTC)

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? PPelberg (WMF) (talk) 01:38, 27 February 2021 (UTC)

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. Pelagic (talk) 00:23, 6 April 2021 (UTC)

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. Whatamidoing (WMF) (talk) 19:13, 19 February 2021 (UTC)

I want to be notified when:

• Someone explicitly addresses me with a mention;
• Someone explicitly contacts me on my user_talk;
• Someone reverts my edit.

I do not want:

• To be notified when a comment is made in a watched section.
• 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.
• 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.

The community requests for section watchlisting includes all pages, not just discussions. Alsee (talk) 05:09, 14 March 2021 (UTC)

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:

1. People will be able to opt-out of topic subscriptions if they do not find the feature valuable
2. For people who do value the topic subscription feature, they will be able to decide which channels (e.g. Apps, email, web) they receive notifications through.

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:

1. Electing to be notified about new comments within sections you are interested in and electing for new edits within particular sections you are watching to appear on your watchlist are technically related.
2. For right now, the scope of changes the Editing Team is making as part of the Talk pages project are limited to talk pages.
3. Considering "1)" and "2)" we are thinking of the work we are doing with topic subscriptions as an incremental step towards offering "section watching," across namespaces. Note: the Editing Team does not have plans to implement section watching across namespaces as part of this project. PPelberg (WMF) (talk) 01:09, 19 March 2021 (UTC)

Prototype: topic subscriptions

T275232 contains the issues and opportunities for improvement that surfaced in this conversation. These same issues and opportunities have also been documented on the project page: Talk pages project/Notifications#Usability testing.

An *in-progress* prototype of the new topic subscription feature is ready for you to try.

This prototype enables you to elect to receive a notification via Echo when someone posts a new comment in any conversation you have decided to "subscribe" to.

Below is information about:

1. The goals of this prototype
2. How to share feedback about the prototype
3. How to try the prototype
4. What will happen after you all share feedback PPelberg (WMF) (talk) 23:24, 1 April 2021 (UTC)

===1. Goals===

The goal of sharing this prototype with you all at this stage is to learn:

1. Which – if any – of the fundamental assumptions we've made about how the feature works conflicts with existing workflows/practices?
2. What – if anything – do you think could be changed about how the feature currently works for it to improve your awareness of new comments in conversations you are interested in?

===2. Sharing feedback===

Once you have tried the prototype and you are ready to share what you think of it, please add a new topic to this talk page by doing the following:

1. "Start a new topic" on this talk page
2. Name this new topic: "Topic subscription prototype feedback: YOUR USERNAME"
3. Write your answers to the "Feedback questions" below. PPelberg (WMF) (talk) 23:25, 1 April 2021 (UTC)

===3. Trying the prototype===

1. Visit this link on a desktop computer: https://patchdemo.wmflabs.org/wikis/77cda30f9d/wiki/Talk:Main_Page
2. Create a new account (this is a test wiki, not a single-sign on wiki)
3. Experiment with the feature by "subscribing" to a few conversations on this talk page and/or create a new talk page.

===4. Feedback questions===

Please answer the questions below when sharing feedback about the prototype.

1. What did you find unexpected about how the prototype looks and functions?
2. What do you appreciate about the prototype?
3. What do you wish was different about the prototype?

===5. Next steps===

1. We will compile the feedback you all share and post it to this page.
2. Communicate when we will address the issues that surface
3. Learn what people who are new to using talk pages think of the prototype
4. Refine the prototype PPelberg (WMF) (talk) 23:31, 1 April 2021 (UTC)

Update: there had been an issue that would have prevented you from trying the prototype. That issue should be resolved as of earlier today, 6-April. PPelberg (WMF) (talk) 21:48, 6 April 2021 (UTC)

We have in ruwiki :ru:Википедия:Гаджеты/Удобные дискуссии and it is MUCH better for expirienced users, who likes wikitext. You see - I had to insert space inside wikilink and use copy-paste to have an opportunity to add plain text after wikilink (it typed inside wikilink). Also - no preview and no custom buttons. Carn (talk) 08:08, 1 June 2021 (UTC)

===Thank you===

@Dyolf77 (WMF), @Patriccck, @Pelagic, and @Sunpriat: we value the time and effort you all put in to trying the manual topic subscription prototype and sharing the feedback you had about it with us.

We've documented, and in some cases, acted upon the feedback you all shared in this Phabricator ticket T275232. PPelberg (WMF) (talk) 00:34, 11 June 2021 (UTC)

Topic subscription prototype feedback: Pelagic (try 1)

Currently, when I try to create an account, I get:

... RuntimeException: SFS IP file contents and file md5 do not match!

Backtrace:

from /srv/patchdemo-wikis/77cda30f9d/w/extensions/StopForumSpam/includes/DenyListUpdate.php(222)

1. 0 /srv/patchdemo-wikis/77cda30f9d/w/extensions/StopForumSpam/includes/DenyListUpdate.php(86): MediaWiki\StopForumSpam\DenyListUpdate::fetchDenyListIPsRemote()

...

Pelagic (talk) 22:59, 5 April 2021 (UTC)

Topic subscription prototype feedback: Pelagic (try 1)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Currently, when I try to create an account, I get:

... RuntimeException: SFS IP file contents and file md5 do not match!

Backtrace:

from /srv/patchdemo-wikis/77cda30f9d/w/extensions/StopForumSpam/includes/DenyListUpdate.php(222)
#0 /srv/patchdemo-wikis/77cda30f9d/w/extensions/StopForumSpam/includes/DenyListUpdate.php(86): MediaWiki\StopForumSpam\DenyListUpdate::fetchDenyListIPsRemote()
...

Pelagic (talk) 23:00, 5 April 2021 (UTC)

This is certainly not ideal.

@Pelagic, can you try the following:

1. Create an account once more on the prototype wiki [i]
2. If/when you receive that error, try reloading the page

...doing the above seemed to work for me just now.

In the meantime, here's a ticket that describes what I understand you to be experiencing: phab:T279395.

---

i. https://patchdemo.wmflabs.org/wikis/77cda30f9d/wiki/Talk:Main_Page PPelberg (WMF) (talk) 00:09, 6 April 2021 (UTC)

@Pelagic are you able to try creating a new account with the prototype once more and comment here whether you are able to do so successfully?

...we think we've resolved the issue that was causing you to see the error above. PPelberg (WMF) (talk) 16:12, 6 April 2021 (UTC)

Yep, works now, thanks @PPelberg (WMF)! I've commented at the Phab ticket also, to the same effect. Pelagic (talk) 09:14, 15 April 2021 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Topic subscription prototype feedback: Habib

I tried the prototype and these are my two comments about it:

• Can users select to add/not add the talk page to their watchlist? For example in a talkpage I want to subscribe to a topic but don't want to watch the page. It could be an option when subscribing: "Do you want to add this page to your watchlist?".
• Is it possible to add other users to the topic (subscribing them, and they may accept or refuse). It is a bit delicate, but sometimes we want a potential user to subscribe to some topics. Dyolf77 (WMF) (talk) 09:48, 13 April 2021 (UTC)

We appreciate you giving the prototype a try, @Dyolf77 (WMF). Comments and questions in response below...

===Follow up questions for you===

Can users select to add/not add the talk page to their watchlist? For example in a talkpage I want to subscribe to a topic but don't want to watch the page. It could be an option when subscribing: "Do you want to add this page to your watchlist?".

At the moment, "Subscribing" and "Unsubscribing" from topics and "Watching" / "Unwatching" pages are unrelated. The thinking for how we arrived at this initial decision can be found in the "Open questions" section of T279498's task description.

With the above said, can you share how you intuitively thought topic subscriptions and the watchlist would/would not relate?

Is it possible to add other users to the topic (subscribing them, and they may accept or refuse). It is a bit delicate, but sometimes we want a potential user to subscribe to some topics.

This is a great question. Currently, it is NOT possible for you to subscribe or unsubscribe another person to/from a topic.

Can you share what led you to ask this question? PPelberg (WMF) (talk) 19:52, 23 April 2021 (UTC)

Thanks @PPelberg (WMF), these are my answers to your questions:

With the above said, can you share how you intuitively thought topic subscriptions and the watchlist would/would not relate?

>> When a user finds an interseting topic to subscribe to, probably they were watching the page. I thought if they found a topic, certainly they don't visit pages or discussions randomly, they must be following these pages. In another case they can be pinged in a discussion in a page they don't watch, so, they want to follow to watch all the page when they subscribe.

Can you share what led you to ask this question?

>> When a topic is relevant for more than one user. For example, this user is working with a group on a common project, while pinging these other users is the "normal" practise, they can subscribe them to the topic. This way, they are updated with comment/feedback/questions. Dyolf77 (WMF) (talk) 17:32, 25 April 2021 (UTC)

>> When a user finds an interseting topic to subscribe to, probably they were watching the page. I thought if they found a topic, certainly they don't visit pages or discussions randomly, they must be following these pages. In another case they can be pinged in a discussion in a page they don't watch, so, they want to follow to watch all the page when they subscribe.

I appreciate you sharing how you are thinking about the relationship between the Watchlist and Topic Subscriptions, @Dyolf77 (WMF). I'd like to make sure I'm accurately understanding what you shared above and ask you two questions based on that understanding:

1. "People are most likely to discover topics worth subscribing to by way of their watchlist." Assuming I've understood this correctly, what do you think are the implications of this?
2. "When someone is pinged on a page they are not already watching, upon landing on that page, they are likely to want to follow (read: watch) the entire page when they go to "subscribe" to the topic in which they have been pinged. Assuming I've understood this correctly, are you suggesting "Watching" and "Subscribing" being treated as separate actions will cause extra work for people?

>> When a topic is relevant for more than one user. For example, this user is working with a group on a common project, while pinging these other users is the "normal" practise, they can subscribe them to the topic. This way, they are updated with comment/feedback/questions.

Ah, okay. I understand this more clearly now...thank you for explaining this. I understand what you are suggesting here as: one possible way of increasing the likelihood people are made aware of comments that are relevant to them is by enabling other people to subscribe them to conversations.

We are going to revisit this general idea as part of the next iteration of the topic subscription feature. In this next iteration, we are planning to introduce a way for people to automatically become subscribed to conversations they participate in and/or start. More context in phab:T263819.

As it relates to the specific idea you proposed about offering people the option to subscribe others to conversations: I'd worry this could lead people to A) become inundated with notifications they did not elect to receive and B) become vulnerable to abuse/harassment. PPelberg (WMF) (talk) 01:32, 30 April 2021 (UTC)

Topic subscription prototype feedback: Pelagic (2)

First impressions (brain dump, apologies if this is a bit too stream-of-consciousness)^[1]

• Created account successfully.
• Noticed that there are no "subscribe" links for my own talk page. (makes sense, after finding that they do appear elsewhere)
• The talk for Nellie Bly appears to be at Talk:Main Page, but no biggie. (https://patchdemo.wmflabs.org/wikis/77cda30f9d/wiki/Talk:Main_Page)
• Subscribe links are easy to notice.
• Typographic style for Subscribe / Unsubscribe feels different from other elements, but F12 inspect-element tells me it's 14px Arial bold and body text is 14px Arial. Maybe because "Edit source" is smaller and not bold, and there are three styles on the same line? (shrug)
• No objection to having Subscribe aligned-right on same line with the heading. (Is there a gadget or option on w:en that puts the edit links on the right? How would that interact?)
• Tried page with useskin=timeless, think it actually looks better than vector (maybe the narrower column width, or maybe the way the different weights and styles of Segoe UI relate versus Arial).
• I like how the text and mouseover colours are different for "Unsubscribe".Stands out subtly without being intrusive.
• Instructions say "Write your answers to the questions listed in the "Sharing feedback" section below" but I couldn't find that section/post. (I feel like I'm doing it wrong, but scroll around and can't see it.)
• Fired up an in-private browser and posted anon (which I feel okay about because the 172.16.x.x address doesn't expose my home IP as discussed previously elsewhere, and the preview shows my username as a 172.16 for reassurance)
• Switched back to first window, now it says logged out but, whatever, logged back in. 3 notices. Welcome to PatchDemo, we're glad you're here. You just made your first edit; thank you, and welcome. [IP] replied in "Moving article". Clicked the third (top) tile/item/whatever you want to call it. Noticed that it not only took me to the section but scrolled down to near the reply (?). Clicked back on Notices and see that the item is marked as read but still visible. Does prod Echo do that? Maybe it seems different because I normally have too many unreads.
• Switch back to anon window. notice that as a not-logged-in IP user I still see "Subscribe" links, and they are wrapped to the next line. Subscribe to see what will happen.
• Reply to unwatched topic (i.e. anon replies to topic not watched by Pelagic). Check back with notices and I did get a notification for an unwatched topic (unexpected). The page now says I'm subscribed (also unexpected). Did I mess up, or was there some weird interaction between the logged-in browser and the in-private not-logged-in browser?
• Time to take a break for now. There are some limitations to testing with two browser sessions on the same computer and IP.
• But I can't let it go. Back to anon window, refresh page, Subscribe links have disappeared. Doubting my sanity now, wish I'd taken a screenshot. Check that I'm definitely not subscribed to "Remarkable translation effort". Post anon reply (172.16.0.164). Go back to logged-in window and refresh. No notifications, that's better.
• Check watchlist. Nothing much there. That's expected based on previous discussions I've seen which indicate this would involve Echo notifications not Watchlist entries. Good for me; I don't work my watchlist much, but others work differently.

Overall: generally works; a little weirdness, but probably hard to replicate that. Sorry if too much detail, but instead of paying testers to record their narration on usertesting.com I can channel the underworld for free...

Question: How can I see all the topics that I'm subscribed to and manage them? Do I need to wait 'til I get a notification then click through and unsubscribe from there? Pelagic (talk) 12:58, 15 April 2021 (UTC)

First impressions (brain dump, apologies if this is a bit too stream-of-consciousness)[1]

@Pelagic, this is great. Comments and questions in response to what you've shared below...

===Follow up questions for you===

Noticed that there are no "subscribe" links for my own talk page. (makes sense, after finding that they do appear elsewhere)

Can you share what leads you to think "subscribe" likes NOT appearing on your own user talk page "makes sense"?

Reason I ask: we made a couple of assumptions when deciding on this behavior and so we're curious about how those assumptions compare with what you intuitively thought.

Typographic style for Subscribe / Unsubscribe feels different from other elements, but F12 inspect-element tells me it's 14px Arial bold and body text is 14px Arial. Maybe because "Edit source" is smaller and not bold, and there are three styles on the same line? (shrug)

Good spot. What do you think about this updated design that, we intend, to be more consistent from other elements on the page?

No objection to having Subscribe aligned-right on same line with the heading. (Is there a gadget or option on w:en that puts the edit links on the right? How would that interact?)

Can you share a link to the gadget you have in mind?

Note: I wonder whether this potential conflict is "moot" considering how we're planning for the Subscribe/Unsubscribe affordances to now be adjacent to the edit links that appear immediately next to section headings. See the updated design for reference.

Reply to unwatched topic (i.e. anon replies to topic not watched by Pelagic). Check back with notices and I did get a notification for an unwatched topic (unexpected). The page now says I'm subscribed (also unexpected). Did I mess up, or was there some weird interaction between the logged-in browser and the in-private not-logged-in browser?

This sounds unexpected. Before filing a ticket for this, can you please confirm the steps below describe what you experienced?

1. Open two browser windows.
2. In one browser window, you are logged in as User:Pelagic. In the other browser window, you are NOT logged in.
3. In the private browser window where you are NOT logged in, you posted a comment (call it "Comment 1") to "Topic A" (made up name)
4. ❗️ In the browser window where you are logged in as User:Pelagic, you receive a notification via Echo for "Comment 1" in "Topic A" despite User:Pelagic NOT having been subscribed to "Topic A"
5. ✅ In the browser window where you are logged in as User:Pelagic, you reload the talk page "Topic A" appears on and notice you are now "Unsubscribed" to "Topic A"

===Comments===

Instructions say "Write your answers to the questions listed in the "Sharing feedback" section below" but I couldn't find that section/post. (I feel like I'm doing it wrong, but scroll around and can't see it.)

You are NOT doing it wrong :) This was a mistake I made and one @Patriccck just pointed out to me as well.

Hopefully it's fixed now. See "2. Sharing feedback > 3. Write your answers to the 'Feedback questions' below."

Clicked back on Notices and see that the item is marked as read but still visible. Does prod Echo do that?

If by "still visible" you mean the below, then I think production Echo behaves this way as well.

1. Click the "Notice" (📥) icon
2. See the notification you clicked sometime before "Step 1" appears within the dropdown with a gray background

Question: How can I see all the topics that I'm subscribed to and manage them? Do I need to wait 'til I get a notification then click through and unsubscribe from there?

For now, it is not possible to see all the topics you are subscribed to. With this said, it is something we are thinking about introducing (see phab:T273342).

If you have ideas for what questions you would expect this view to help you answer and what actions you would expect it to allow you to take, we'd be keen to hear them! PPelberg (WMF) (talk) 19:41, 23 April 2021 (UTC)

• Can’t subscribe on my own talk page makes sense → because I already get alerts for posts on my talk page. Though there are other ways this could be done, e.g. one type of alert for new section/topic + a different alert for a reply + topics are subscribed by default and you get a link to unsubscribe. Would people want to unsubscribe from topics on their own talk when they could simply delete or archive them instead? Now I wonder, for other talk pages (not my own): would I want to watch the whole page but unsubscribe from specific topics? Should there be a subscribe-all link?
  • I agree with what you wrote at T276996#6909778, still reading the rest of the ticket/task.
• (Un)subscribe link style and position → Both have their merits. I really appreciate all the work Jess is doing with iterating over designs and testing. On the one hand, it's logical having the actions "edit | unsubscribe" together. On the other, having the links on the right, with different colours for subscribe/unsubscribe allows me to scan the page and see which topics are subscribed. That's less applicable where not all discussions are short, though. I suspect people may find the new design more natural, but not sure how you can get more opinions. Have you considered a ⭐️ marker to the left of the section heading, or some indicator in the ToC?
• Gadget for edit links on right → found it at English Wikipedia – Preferences – Gadgets – Appearance – Move section [edit] links to the right side of the screen. Haven't tried it myself, and I don’t know if it's installed on other wikis.
• Notice for unwatched topic → I'll retry and let you know. Rereading what I wrote, looks like I couldn't reproduce it at the time.
• Read but still visible → yes, you’re right. With a small screen and on a wiki where I have a lot of unreads, the read items are scrolled offscreen. Was just more noticeable when there are only a few items in the list, and the newly-read item didn’t change position. Pelagic (talk) 21:46, 6 May 2021 (UTC)

I'm sorry for the belated response, @Pelagic; comments below...

Can’t subscribe on my own talk page makes sense → because I already get alerts for posts on my talk page

Understood. It's helpful to see how this assumptions we've made line up with what you instinctively thought.

Should there be a subscribe-all link?

We share this question and so too does @Patriccck; I've added this to the "Issues" table in T275232's task description.

(Un)subscribe link style and position → Both have their merits. I really appreciate all the work Jess is doing with iterating over designs and testing.

@JKlein (WMF) will be glad to hear this ^ _ ^

On the one hand, it's logical having the actions "edit | unsubscribe" together. On the other, having the links on the right, with different colours for subscribe/unsubscribe allows me to scan the page and see which topics are subscribed. That's less applicable where not all discussions are short, though. I suspect people may find the new design more natural, but not sure how you can get more opinions.

These are the trade offs that have come to mind for us as well. Since I posted last, we decided for the Subscribe/Unsubscribe affordance to be located on the right side of the page [in LTR languages]. You can find the thinking that influenced this approach in T279149#7064405.

Have you considered a ⭐️ marker to the left of the section heading, or some indicator in the ToC?

We did consider the "⭐️" marker and ultimately decided against reusing so as not to lead people into mistakenly thinking "Watching" and "Subscribing" are currently related. The thinking behind the decision to treat these features as discrete, for now, can be found in T279498.

Gadget for edit links on right → found it at English Wikipedia – Preferences – Gadgets – Appearance – Move section [edit] links to the right side of the screen

Thank you for pointing this out – you sharing this gadget is the first I've heard of it.

By the way: are you aware of an easy way to see how popular a gadget is across projects?

I'm aware of Special:GadgetUsage, although based on what I currently know, I assume that to do the above I'd need to visit each project individually...

Notice for unwatched topic → I'll retry and let you know. Rereading what I wrote, looks like I couldn't reproduce it at the time.

Understood – thank you.

Read but still visible → yes, you’re right. With a small screen and on a wiki where I have a lot of unreads, the read items are scrolled offscreen. Was just more noticeable when there are only a few items in the list, and the newly-read item didn’t change position.

Mmm, I see. Even still, would it be accurate for me to understand part of what you're saying above as: "It can be difficult to differentiate between notifications you have and have not read within Echo's dropdown?" PPelberg (WMF) (talk) 01:08, 21 May 2021 (UTC)

Topic subscription prototype feedback: Patrik L.

1. What did you find unexpected about how the prototype looks and functions?

   I think that this new tool should notify me when is there any edit in the section. Some examples: When someone adds this template and do not reply, I want to know it. When someone adds a sub-section, I also want to know it.

2. What do you appreciate about the prototype?

   I like that I'm noticed immediately (instead of listing in watchlist that is a little bit disorganized and fussy - at least mine).

3. What do you wish was different about the prototype?

   There are some talk pages that I want to subscribe all. For example, if I can watch AN at cswiki, I can take action against vandals very fast. But this needs function described at point one. Patrik L. (talk) 20:09, 24 April 2021 (UTC)

Thank you for trying out the prototype and sharing the thoughts it brought to mind, @Patrik L. A couple of follow up questions for you below...

I think that this new tool should notify me when is there any edit in the section. Some examples: When someone adds this template and do not reply, I want to know it. When someone adds a sub-section, I also want to know it.

Can you share what led you to suggest the above? Asked another way: what do you worry will happen if the topic subscription feature is NOT adjusted to allow you to be notified whenever an edit, no matter its size/type, is made to a section you are subscribed to?

There are some talk pages that I want to subscribe all. For example, if I can watch AN at cswiki, I can take action against vandals very fast. But this needs function described at point one.

In describing the above, were you thinking about being able to subscribe to all of the existing conversations on a given page? Being able to subscribe to all new conversations that are started on a given page? Something else? PPelberg (WMF) (talk) 01:01, 27 April 2021 (UTC)

Can you share what led you to suggest the above? Asked another way: what do you worry will happen if the topic subscription feature is NOT adjusted to allow you to be notified whenever an edit, no matter its size/type, is made to a section you are subscribed to?

Hmm, good question. I think that minor edits like grammar or spelling fixes should not be supported by the topic subscription feature. But edits like adding template about the task at Phabricator are important, I think.

In describing the above, were you thinking about being able to subscribe to all of the existing conversations on a given page? Being able to subscribe to all new conversations that are started on a given page? Something else?

I wondered about being able to subscribe all new conversations that are started on a given page using a special button. Patrik L. (talk) 11:11, 27 April 2021 (UTC)

Hmm, good question. I think that minor edits like grammar or spelling fixes should not be supported by the topic subscription feature. But edits like adding template about the task at Phabricator are important, I think.

I see. So it sounds like what you are describing is a desire for being able to customize/configure the activity you are and are NOT notified about when you subscribe to a section.

Please let me know if I've understood this in a way that is different from how intended it.

In the meantime, I've noted this issue in phab:275232.

I wondered about being able to subscribe all new conversations that are started on a given page using a special button.

Understood. I've noted this issue in phab:275232.

...thank you, @Patrik L.! PPelberg (WMF) (talk) 00:44, 5 May 2021 (UTC)

Yes, you understood all that I wrote right. Happy to help. :) Patrik L. (talk) 08:44, 5 May 2021 (UTC)

Topic subscription prototype feedback: Sunpriat

notes before the test

• If there are a lot of notifications, they will spam the list and it will be more difficult to pay attention to something important, users will simply be afraid to use it, the list needs to merge its elements.
• I saw something like this in the Flow. Didn't look very helpful. Probably I would like to know from "when" the answers begin (date, how old the messages are there) just by looking at the merging notification.
• Users need rules so they can read them and know when notifications are triggered. To know how to proceed so that the notification is guaranteed and why (or how to do it if you need it) is not sent. (like a Manual:Reverts#Conditions for execution)

after the test

• Pressed subscribe, pressed spacebar to scroll down the text screen, unsubscribe occurred. The focus remained on the button. If you click on the star for adding to the watchlist, then when you press the spacebar, the star will not be activated again as an unwatch - it has no focus. Should work the same as the watchlist star.
• It is unusual to see the line not all the way to the right edge. This is some kind of gap in the border and the topics begin to merge, connect (it looks like a wikipedia:Template:Outdent for moving a comment thread, there is also an incomplete line). The line must be full width in order to be guaranteed to split for dosing information.
• When commenting with a participant's notification (@), the notification appears in a different (left) notification icon (some did not understand the need to separate notifications before. Now notifications look of the same type but appear under different icons - this is a bit difficult). If you click on the notification (@), it goes to the section heading. It was expected that it will also scroll further down to the comment (scroll from new notifications is more convenient).
• I was afraid that the list would be spammed unread, but everything turned out to be grouped. But when it was marked as read, now the list was spammed with the read. It was expected that what was marked as read would also group or disappear.
• And if you are subscribed to several topics, then, after being marked as read, the list is a complete mess of other people's nicknames, as if there is someone's chat. There is no "you" in the text of notifications, so they look like a completely alien mini-chat.
• When I click on the notification, it scrolls immediately to the comment, but at the same time the line of the previous comment is visible, and if there is such a short comment, then it seems that this is for the above comment - this can be confusing. In the Flow, the border on the left was highlighted in color after opening from notifications and it was immediately clear to which comment I went. It may be better for the comment to be immediately the first line at the beginning (top) of the screen.
• The discussion goes from top to bottom. Notifications go from bottom to top. In a collapsed group, I would like to see the natural order from top to bottom. This is confusing when you see the beginning of the lines and read/view them upside down, but they are in fact in the opposite order.
• I made a subsection in the topic and did not receive a notification. https://patchdemo.wmflabs.org/wikis/77cda30f9d/w/index.php?title=Talk:Citation_needed_example&diff=prev&oldid=91 If someone summarizes the topic, then I will not know about it.
• And there are no signature buttons for the subsection, notifications from the subsection are not received.

• Someone previously expressed a desire to receive notifications from replies to their replies. That is, for example, the ability to filter notifications only if the (::, :::)replies are deeper in the thread of your (:)reply, and other people's (:)threads are less interesting. Sunpriat 03:15, 3 May 2021 (UTC)

@Sunpriat we appreciate you taking the time to try out the prototype and document the thoughts in brought to mind.

Below are responses to the first half of the comments you shared. Later this week, I am going to comment again with responses to the second half of the comments you shared...

===Follow up questions for you===

1. Probably I would like to know from "when" the answers begin (date, how old the messages are there) just by looking at the merging notification.

What is "...the merging notification." you are referring to above?

2. It is unusual to see the line not all the way to the right edge...This is some kind of gap in the border and the topics begin to merge, connect...

Noted. I've documented this issue in phab:T275232.

In the meantime, can you share a bit more detail about what you mean by the topics merging? Are you suggesting that it's difficult to tell sections apart without the topic borderline extending all the way?

3. When commenting with a participant's notification (@), the notification appears in a different (left) notification icon (some did not understand the need to separate notifications before. Now notifications look of the same type but appear under different icons - this is a bit difficult)

I want to make sure I am accurately understanding what you are saying above. Are you saying that you find it confusing/unintuitive that notifications can appear in two places depending what kind of notifications they are? For example, if you are "pinged," you will see it appear in the "🔔" icon (the software refers to these as "alerts") whereas if a new comment is posted in a section you are subscribed to, it will appear in the "📥" icon (the software refers to these as "notices")?

4. If you click on the notification (@), it goes to the section heading. It was expected that it will also scroll further down to the comment (scroll from new notifications is more convenient).

Can you please read phab:T253082 and let me know whether that ticket describes the functionality you are describing above?

===Comments in response to things you shared===

5. Users need rules so they can read them and know when notifications are triggered. To know how to proceed so that the notification is guaranteed and why (or how to do it if you need it) is not sent.

We agree, people who are curious need to be able to read how the feature works. We will, most likely, document this information on the Talk pages project/Feature summary page.

6. Pressed subscribe, pressed spacebar to scroll down the text screen, unsubscribe occurred.

Good catch. I've documented this issue in phab:T275232. PPelberg (WMF) (talk) 01:14, 5 May 2021 (UTC)

@PPelberg (WMF)

1. When there are several messages from the same topic, they are shown as one message (group) (when you click on which a drop-down list with all messages appears), they are combined into one logical flow or as a node in a mindmap. Visually merged into a coherent dialogue. It can be a dumb button "unfold me" or a slightly smart button somehow useful itself summarizing its content into itself.

2. When the line is at its full length, when viewed from top to bottom - oh, here is the line, then this is the end, everything is simple. The new Vector has a fixed width and a lot of white space on the left and right (1920x1080). I look from top to bottom - there is no line in the right half of the screen, on the right side these topics are visually united, connect and continue each other, I have to look further along the left side, additionally compare the top topic and the bottom topic and the line between them - this takes a little more time and unnecessary actions.

3. Perhaps in English the difference in words is more understandable, perhaps the situation is worsened by a less distinguishable translation, as very similar synonyms. Imagine that instead of alerts|notices there is the same word (or there are no words, only icons bell|tray) notifications|notifications, and here it is difficult for many to understand how what comes to the first list differs from the second.

I subscribed to the topic, I receive mini-messages in the right list, then the user pinged me, a message appeared in the left list under the bell, but there is no message in the right, as if he pinged from the topic without my subscription. Everything related to the topic was transferred to the right stack in one place, then a part strongly related to the topic appeared in the left stack, while nothing new appeared in the right stack, and then there is a feeling that something went wrong, that there was a sorting error, that something was lost and did not come to the right stack.

I was expecting something to appear in the right column. I understand that displaying +1 at the bell and +1 at the tray at the same time would be a visual overflow. It can be +1 at the bell and 0 at the tray. But an element should appear in the right column - this shows that the message appeared in the subscribed topic, and, for example, this element has an additional icon bell icon that it was with a ping (it is immediately clear that the +1 was sent to the left column instead and nothing was missing in the right column, no missed incoming messages).

4. Almost, but here with the requirement/clarification that the user experience should not differ. I expect to see the message in exactly the same place on the screen and start reading it in the same place on the screen as when I click on the messages from the subscribed topics from the right column.

5. Sometimes users ask in the wiki forum / in discussions why the ping of another participant did not work, why some tag was not set for editing - except for curiosity, this is the need to send them to read somewhere via a link or to provide a qualified answer. Sunpriat 05:36, 5 May 2021 (UTC)

1. When there are several messages from the same topic, they are shown as one message (group) (when you click on which a drop-down list with all messages appears), they are combined into one logical flow or as a node in a mindmap. Visually merged into a coherent dialogue. It can be a dumb button "unfold me" or a slightly smart button somehow useful itself summarizing its content into itself.

Ah, now [I think] I know what you are referring to (see this screenshot)! Assuming I am understanding what you are describing above accurately, I think we have implemented the "merging" functionality you are referring to in phab:T275949.

Here's how it works right now:

1. When you have notifications for multiple comments from the same "topic," you will see them merged/grouped into one item within Echo that you can expand.
2. That "one item" will show you: i) the number of comments you are being notified about, ii) the title of the topic in which they were posted and, iii) the username of the person who posted the most recent comment.
3. You can open the "one item" to see all of the notifications contained within it by clicking the "expand" icon. You can see what the icon looks like by visiting this page and searching for the word "expand".

Please let me know if anything above prompts new questions and/or does not match up with what you would expect.

2. When the line is at its full length, when viewed from top to bottom - oh, here is the line, then this is the end, everything is simple. The new Vector has a fixed width and a lot of white space on the left and right (1920x1080). I look from top to bottom - there is no line in the right half of the screen, on the right side these topics are visually united, connect and continue each other, I have to look further along the left side, additionally compare the top topic and the bottom topic and the line between them - this takes a little more time and unnecessary actions.

I see. Thank you for explaining this in more detail. We've adjusted the prototype so that the horizontal line that runs underneath ==H2== sections is not interrupted by the Subscribe/Unsubscribe link. I think this addresses the issue you were referring to, but if not, please let me know.

3. Perhaps in English the difference in words is more understandable, perhaps the situation is worsened by a less distinguishable translation, as very similar synonyms. Imagine that instead of alerts|notices there is the same word (or there are no words, only icons bell|tray) notifications|notifications, and here it is difficult for many to understand how what comes to the first list differs from the second...

You described this in a wonderfully vivid way. While I think the sorting issue you are describing above is out of scope for this particular project, here is the ticket in Phabricator where this issue is being tracked so we do not lose sight of it: T142981.

We'd value you commenting on that ticket if you think there are important details that are missing.

4. Almost, but here with the requirement/clarification that the user experience should not differ. I expect to see the message in exactly the same place on the screen and start reading it in the same place on the screen as when I click on the messages from the subscribed topics from the right column.

You want to be taken to the precise location on the page where the content you are being notified about exists, regardless of what kind of content it is...understood.

Here is a ticket where we can track the work involved with implemented this: phab:T282029.

5. Sometimes users ask in the wiki forum / in discussions why the ping of another participant did not work, why some tag was not set for editing - except for curiosity, this is the need to send them to read somewhere via a link or to provide a qualified answer.

Are you able to share what "did not work" means in this context?

Are the people you referring to talking about pinging someone and that person not responding? Are they talking about pinging someone and doubting whether the person they are pinging was actually notified? Something else? PPelberg (WMF) (talk) 01:55, 14 May 2021 (UTC)

@PPelberg (WMF) 1. Yes, it's about a bundle. But the key point was in "from when". A similar flow-notification-reply-bundle was in Notifications/Message audit (2014), after adding the "subscribe" function it was rewritten to https://translatewiki.net/w/i.php?title=MediaWiki:Flow-notification-reply-bundle/qqq . There was also "x replied in y topic. last time". Comments can be imagined as hot (new) and cold (old). The bundle always shows the hot end of the queue and this provokes quick but harsh responses. Often you need to answer after thinking for a while, but not too long. Or to see the date of the oldest message in order to understand the time interval of the "reader's debt".

3. The key point was that notifications from one topic are strongly logically connected, and appearing in another column breaks this connection. Importance qualifier lost. The topic I subscribed to is important to me. But the ping notification remains similar to all other pings. I expected the connectivity to be preserved, for example, the text "you are subscribed to this topic" or the star icon appears in the ping notification, so that this ping stands out from the rest as more important to me.

5. "and doubting whether" e.g. Q: I updated the comment, but why hasn't the notification been sent? A: you must write both nickname and signature Help:Notifications/Types#Mentions Q: but I added both a nickname and a fresh signature A: you should do it on a new line Manual:Echo Sunpriat 16:20, 14 May 2021 (UTC)

Yes, it's about a bundle. But the key point was in "from when"...Often you need to answer after thinking for a while, but not too long. Or to see the date of the oldest message in order to understand the time interval of the "reader's debt".

@Sunpriat: can you share how you would expect the notification bundling to work? I ask this wondering whether you describing this will help me to more fully understand the issue you are referring to above.

...the text "you are subscribed to this topic" or the star icon appears in the ping notification, so that this ping stands out from the rest as more important to me.

Ah, I see. I've filed a ticket for what you are describing here: T283302.

Please comment on the ticket if you think it ought to be adjusted in any way.

"and doubting whether" e.g. Q: I updated the comment, but why hasn't the notification been sent? A: you must write both nickname and signature Help:Notifications/Types#Mentions Q: but I added both a nickname and a fresh signature A: you should do it on a new line Manual:Echo

These example questions are helpful; thank you for sharing them.

Would it be accurate for me to understand you as saying that there is a need for a single place to be able to direct people to where they can understand what is required for a ping to be sent successfully?

By the way: I appreciate how patient you have been in engaging with the follow up questions I've asked. PPelberg (WMF) (talk) 00:36, 21 May 2021 (UTC)

Topic subscriptions now available on 7 wikis

You can use the new topic subscriptions on seven wikis now:

• Meta-Wiki
• French Wikipedia
• Dutch Wikipedia
• Arabic Wikipedia
• Hungarian Wikipedia
• Czech Wikipedia
• and this one!

In all cases, you need to go to Special:Preferences, to the Beta Features tab, and enable "Discussion tools" for that wiki.

See Help:DiscussionTools for basic information. Whatamidoing (WMF) (talk) 18:53, 1 July 2021 (UTC)

Hi @Whatamidoing (WMF), good news! I came here from Meta-wiki, where I saw this feature enabled in main namespace. While some pages are intended for comments, others in main space there aren't, so it is rather weird to see [(un)subscribe] button on sections of stable content pages like m:Wikimedia Foundation elections. Is this feature tweaked to namespaces or can some pages be opt in/out of these notifications? Ата ^(talk) 18:17, 4 July 2021 (UTC)

It's bug T285796. I'm not sure how soon it will get fixed (definitely not this week, hopefully next week?). Subscribing to sections that contain no signatures/timestamps will have no effect. Whatamidoing (WMF) (talk) 03:43, 6 July 2021 (UTC)

Should topic subscriptions auto-expire?

I have a question for editors: If you subscribe to a conversation on a talk page, how long should you stay subscribed? Should we try to incorporate a Watchlist Expiry approach into subscriptions?

Thinking about my typical volunteer conversations, I usually want to follow a discussion for a couple of weeks. For work, I usually want to watch a discussion for a couple of months. It's really unusual for a conversation to be restarted after three months, although perhaps there's something I'd like to watch for a year or forever.

Would you be interested in having the subscriptions auto-expire? Whatamidoing (WMF) (talk) 18:57, 1 July 2021 (UTC)

I want to sub as long as the discussion is open. Valereee (talk) 19:00, 1 July 2021 (UTC)

Late to the party but yes, it would be useful. A default expire time of 1-2 months could be sufficient, as long as it would be possible for the user to make it longer, shorter or infinite. Wedhro (talk) 04:51, 24 July 2021 (UTC)

I don't think anything will be decided about this for a month or two, so there's plenty of time for people to share their thoughts. Also, whatever the initial decision is, it could be changed later. Whatamidoing (WMF) (talk) 18:33, 26 July 2021 (UTC)

I really like and use the Watchlist Expiry feature and so would appreciate the possibilty here, too. However, I think the default should be permanent; I should be able to choose other durations depending on the particular talk page/discussion. JohnFromPinckney (talk) 04:29, 27 July 2021 (UTC)

My first reaction is that I would want a choice, but if a discussion section has gone stale then it won't generate any new notifications, so what does it matter? Perhaps you don't want an alert if someone posts to an old thread that you no longer care about. Maybe it's a good thing: thread subscribers can contact the poster and tell them that their comment won't be seen by many people and to start a new discussion. OTOH, if the post is just a for-the-record kind of note, then follow-up isn't necessary and generates noise. E.g.

• Note: discussion seems to have petered out here, but see [[other page#new related discussion]]. user1, date.
  • Dude, no-one's going to read this. user2.
    • Will you two cut it out? Stop popping this up in my notifications! user3.
      • See, you did read it. user1.
        • Aaargh. user3
          • Unsubscribe if it bothers you, [[User:user3]]. user2
            • I did, but now you pinged me. user3
  • Actually, I didn't know about "new related discussion". Thanks for the update. user4.

Where it will make a difference is when/if (please?) we get a place to manage and view subscriptions. Will it be possible to show last-active date there? Filter or sort on staleness? Explicit expiration could de-clutter old stuff from the list, but so could a filter to show only the subscriptions to active topics. Pelagic (talk) 00:20, 8 August 2021 (UTC)

@PPelberg (WMF), I couldn't find a Phab task for a central location/method for managing subscriptions. If subscriptions are permanent, I'm going to have thousands of them, so "just find the one discussion and click the [unsubscribe] button manually" isn't going to be sufficient. Pelagic's idea of being able to sort/filter according to the last active date is a good one. Whatamidoing (WMF) (talk) 18:05, 9 August 2021 (UTC)

I couldn't find a Phab task for a central location/method for managing subscriptions.

I think T273342 is the ticket, or at least the "beginnings" of the ticket, you are looking for, @Whatamidoing (WMF).

Where it will make a difference is when/if (please?) we get a place to manage and view subscriptions...

@Pelagic (and anyone else here): can you please share more about what you think having a, "...central location/method for managing subscriptions" would enable you to do? I can assume of course, tho, I'd rather y'all bring language to the thinking behind this idea... PPelberg (WMF) (talk) 20:46, 9 August 2021 (UTC)

Sorry for not returning to this earlier, @PPelberg (WMF).

Something I could do with a My Subscribed Topics list is use it as an aide memoire. If I made the effort of subscribing to a conversation (though it's only a small effort to scroll back to the top and tap the link), then I must have found it significant. I could view all those significant conversations in one place and see patterns or themes that I would like to pursue further. Or I might be interacting in a new conversation, and recall “I remember talking about this not long a go in a couple of other places, and I think I subscribed to those, let me check my subscriptions list and see if I can find them”.

I could instead make a manual list of things to refer back to, but that requires a fair bit of maintenance effort. I could also filter my contrib's for Talk or Project namespaces: that shows everything I've commented on rather than subscribed to, mightn't work well with archived or renamed sections, and unless I tweaked the edit summaries, only lists the subheading not the top-level heading (what was that comment to /* Arbitrary break */ about?). If I did write a detailed custom summary, then looking at Contributions becomes a complementary search strategy to looking in Subscriptions.

That's not a formal user story or use-case statement, but does that help? Pelagic (talk) 20:11, 10 October 2021 (UTC)

That's not a formal user story or use-case statement, but does that help?

Knowing the various ways in which you could imagine yourself using this page absolutely helps...thank you for sharing them, @Pelagic!

...view all those significant conversations in one place and see patterns or themes that I would like to pursue further. Or I might be interacting in a new conversation, and recall “I remember talking about this not long a go in a couple of other places, and I think I subscribed to those, let me check my subscriptions list and see if I can find them”.

The use case(s) you are describing here are very clear to me, I think.

If/when you have a moment, could you please give T294162 a read and boldly make any edits you think are necessary to make the user story I've drafted accurately and exhaustively represent what you were meaning to communicate in sharing the above?

aide memoire

Neat...this is the first time I'm encountering this term! PPelberg (WMF) (talk) 23:48, 22 October 2021 (UTC)

Yes, that's helpful.

Thinking about the "My Subscribed Topics list", what kind of information would you want on it? The name of the page, of course, but what else should be on the page? Section heading (it might change), date (when you subscribed, commented, original comment, most recent comment, something else?), other participants? What actions might you want to take from that page (e.g., unsubscribing)? Whatamidoing (WMF) (talk) 21:20, 12 October 2021 (UTC)

Yes, current page and section name where the thread is located. That's what appears in the Echo notification, no? I doubt it's necessary to store original page and heading. Usually when a thread is renamed or relocated, it should either be something obvious like an archive subpage, or someone should have added a note/template saying “discussion moved from otherplace”.

Some kind of start-date would be good, either date of OP or date subscribed. I'm inclined to prefer OP date: do I really care when it was that I started subscribing? And what if I unsubscribe then resubscribe? The original-post date is a property of the thread itself and is the same for everyone. Plus it's the right answer for “how old is this? when did it start?” (Sorry for being verbose, I'm thinking this through as I type.)

Date of most recent comment, to indicate freshness.

An indication of overall activity on the thread: number of posts, number of unique participants. Maybe also an indication of size: number of bytes or words.

Some web forums in their topic lists also display the usernames of the original and latest poster. I feel this gives too much prominence to those two people over the other participants. Is it practical or even useful to list all people? OP name could be relevant in some contexts like Teahouse or ANI.

Nice to have: Ability to sort on either date, and filter on these plus namespace, number of comments, number of participants. If subscriptions are never truly removed from the database but just flagged for don't-notify, an option to show unsubscribed discussions (as distinct from never-subscribed) could be interesting. Search box, or just use browser's find-on-page?

Thinking outside the box, imagine having a personal comment/description/notes field for each subscription. Often the topic heading doesn't well reflect the content of the discussion. Or I might want to record my own reasons for wanting to follow it. Managing these descriptions is more heavy-weight than the simple un/subscribed state, would people use such a feature?

Actions to perform: unsubscribe, resubscribe, delete, add/change description. (Mute notifications for x days? Probably not worth the implementation effort, if resubscribe is already an option.)

Flag for follow-up / pin item / mark as important? Maybe, but again it would be shaping a lightweight subscribe action into a lot more.

As usual, I've gone too long on this, but hope there are some parts you can pick out to support a use case or user story. Shorter answer:

• Info to show = page, section, start date (first post), last active date (most recent post), num. comments, num. participants, length (words or bytes).
• Actions/features: unsubscribe/mute, resubscribe/unmute, delete/unsubscribe; edit personal note; sort, filter; select view style (list, table, icons). Pelagic (talk) 20:44, 17 October 2021 (UTC)

As usual, I've gone too long on this, but hope there are some parts you can pick out to support a use case or user story.

@Pelagic the level of detail you've shared here is absolutely helpful. In fact, I find the "internal monologue" you included (e.g. Maybe, but again it would be shaping a lightweight subscribe action into a lot more.) to especially valuable for it helps us to see and think about the tradeoffs that could come with include or excluding certain information and/or actions.

This is all to say: thank you for taking the time to articulate the above...I've included the "info to show" ideas in Phabricator here: T294162#7486703. PPelberg (WMF) (talk) 21:40, 5 November 2021 (UTC)

I agree with Valereee; topic subscriptions should be indefinite by default. I would find it very surprising if I were unsubscribed from a conversation that was still active. Enterprisey (talk) 23:12, 8 August 2021 (UTC)

How many conversations stay active for a year? or even a month? Whatamidoing (WMF) (talk) 15:39, 12 August 2021 (UTC)

A month, very frequently. For some types the default setting is a minimum of a month. I have convos that long on my watchlist right now. Infrequently a year, but it does happen. I can think of a couple of times I've posted to a talk about a planned edit, forgotten to circle back promptly, and discovered it still on the page with a response to me that I hadn't been pinged to, so I started the conversation back up.

Is there any downside to staying subscribed until a conversation is archived? Valereee (talk) 16:28, 12 August 2021 (UTC)

Subscriptions follow the first comment in a section, so archiving (in the sense of the section being removed from one page and pasted into another) don't terminate the subscription. This suggests that the database will grow infinitely, which entails some risks/costs (not primarily of the financial sort). How rapidly that could grow depends in part on whether everyone loves being auto-subscribed to all the threads they participate in.

I was already getting about a hundred Echo notifications a month in each of my accounts (work-me and volunteer-me) before the notifications feature was deployed. Right now, it's in manual subscriptions (meaning: you have to click the [subscribe] button for each thread), and I'm already using it frequently. Imagine what that will look like if I am auto-subscribed to every thread I start or reply in, and multiply that times thousands of highly active editors.

I sometimes say that the flip side of Wikipedia:Don't worry about performance is that if, as rarely happens, Ops tells you that you are causing performance problems, you need to do whatever they say. I am looking at the number of discussions that I can realistically expect to be subscribed to by this time next year, and wondering what I'd like to recommend if (when?) Ops comes around to say that's enough. Keep the 2,000 most recent ones, like Echo/Notifications does? The five years' worth? Auto-expire everything after a year, but set a manual override for the discussions I want to watch forever? I don't know, but I want to think it through. Whatamidoing (WMF) (talk) 20:57, 24 August 2021 (UTC)

The fact that archiving doesn't terminate the subscription would be surprising to me. But then if it did, and someone unarchived a discussion, all the subscriptions would be lost. I would say we can definitely trade off support for unarchiving discussions, though, so I would prefer archiving to terminate subscriptions. Enterprisey (talk) 10:00, 27 August 2021 (UTC)

There's no straightforward programmatic way to differentiate between "copied to Village_pump/Archive_13 because the disucssion is archived now" and "copied to "Village_pump/Other because you posted it in the wrong place and I'm fixing your mistake". I have already seen the second in action, and I really like it. Whatamidoing (WMF) (talk) 05:12, 30 August 2021 (UTC)

I would imagine checking for the word "Archive" in the page title or the presence of {{Archive }}

(or the other templates like that) would be pretty reliable. Enterprisey (talk) 05:36, 2 September 2021 (UTC)

That would work for most of the archiving systems used at the English Wikipedia.

Also, if I wanted to get your attention off a discussion, I could "accidentally" click the button for any of the w:en:WP:ONECLICK archiving scripts and immediately self-revert. It would mean that anyone could remove a discussion from your subscription list. Whatamidoing (WMF) (talk) 19:25, 2 September 2021 (UTC)

Whatamidoing, I don't know about you or others, but I would topic-subscribe only on really long pages (like the Administrators' Noticeboard or some of the Something-for-Deletion pages at en-WP). That would leave me subscribed to pages to the extent I wish it, but not so many topics. Does that help? Or does it ignore what might be a (to me, unknown) problem: I currently have some 4000 pages on my watchlist. Are large watchlists a problem for us in general? JohnFromPinckney (talk) 11:20, 25 August 2021 (UTC)

Very large watchlists can be awkward from the POV of database administration. These might be more prevalent at Commons, since if you watch every file you upload, and you upload hundreds of thousands, then your watchlist will have hundreds of thousands of items.

This tool isn't using the watchlist database, however; I believe that it's using the Echo database for message delivery and its own database for the subscriptions. Echo notifications expire after a while, basically to make the database simpler. The subscription database is (currently) forever.

I'm finding that work-me wants to subscribe to every discussion I participate in, and volunteer-me wants to subscribe to everything except for WT:MED and the pub at the English Wikivoyage (I start every morning by going straight to the history tab for these two pages, to see what's been posted since the last time I checked in). That could turn into a lot of individual notifications (which will auto-expire according to Echo's current system), but over the course of years, it could turn into a lot of subscriptions. Imagine that I subscribe to an average of 50 conversations a week (a plausible level for me). At the end of one year, that's 2,500 database entries. At the end of 10 years (and I've been editing for 15 years already), that's 25,000 database entries – forever, even if I quit editing. I don't know what kind of limits might someday be necessary (maybe it would only be a problem if there were a million entries for an editor, or if the database growth were sudden), but I wonder if this might eventually become a problem. Whatamidoing (WMF) (talk) 17:46, 25 August 2021 (UTC)

Well, okay, if it's a problem, set whatever default you need to. I'd personally like at least six months, though. JohnFromPinckney (talk) 21:52, 25 August 2021 (UTC)

I don't know about MariaDB, but in MS SQL Server, database tables can become very large and still have fast lookups if they are well indexed and you're retrieving a small subset of the rows/records. Maintenance tasks like rebuilding indices or making full backups become more expensive for huge tables, though. The Revisions table grows forever, and would always be expected to be larger than the Subscriptions table, wouldn't it?

Also a question: does unsubscribing from a topic actually delete the row from the database, or does it just toggle a field from active=true to active=false? In the latter case the database is going to grow even if you unsubscribe or expire entries. For research purposes, would you want to keep records of subscriptions that were later unsubscribed? Pelagic (talk) 20:42, 10 October 2021 (UTC)

Is there no way to thread our replies? I click on the "Reply" next to the "Thank" right under the post to which I wish to respond, and my response still comes out left-justified. It looks like Whatamidoing managed to reply to Pelagic above, but I can't see how to make that magic work. Maybe I'm not waving my wand correctly. JohnFromPinckney (talk) 21:56, 25 August 2021 (UTC)

They stopped developing this interface (Flow) before they sorted out indentation models. The current state is that comments at the end are full width, and comments added to the middle (i.e., not a reply to the bottom-most comment) get indented (to show that they were added out of chronological order?). Whatamidoing (WMF) (talk) 17:08, 26 August 2021 (UTC)

Content pages have [ unsubscribe ] at first visit on Meta

Tracked in Phabricator
Task T285796

Is it just me? Most content pages on Meta have [ unsbscribe ] links next to the level-2 headings. Talk pages have [ subscribe ] as expected. Can't replicate issue on w:fr. Seen on two separate devices having Windows Firefox (Vector, New Vector, Timeless) and iOS Safari (Timeless) respectively.

E.g. [ unsubscribe ] – m:Wikimedia Foundation elections/2021/Candidates/CandidateQ&A, m:VRT, m:NOP

C.f. [ subscribe ] – m:VRT/Volunteering (!?), m:Talk:VRT,

Mix of both – m:Wikimedia Forum

This might only happen on first visit, I hit F5 on a few of those and the links changed to [ subscribe ]. Pelagic (talk) 15:47, 4 July 2021 (UTC)

The timeline appears to be "hopefully soon". Whatamidoing (WMF) (talk) 21:21, 16 July 2021 (UTC)

Feature request: automatic subscription to new sections on selected pages

T263821: Introduce New Topic Notifications

First of all, I really like the notifications. And I want more of them! I find it especially powerful to not need to visit my watch list to see if there is something said in a discussion I follow. But I still have to do that to see if there is a new discussion started on some page I am particularly interested in. For these pages, I would like to auto subscribe to all new sections. Since it was so easy to unwatch a topic straight from the menu, I don't mind getting many notifications. I still find it likely to save me many clicks and loading time of pages. Ainali (talk) 07:45, 24 September 2021 (UTC)

We appreciate you stopping by to share this feedback, @Ainali! A response to the points you raised below...

First of all, I really like the notifications. And I want more of them! I find it especially powerful to not need to visit my watch list to see if there is something said in a discussion I follow.

This is helpful context for us to know about. Related to it: can you share why you prefer learning about whether something new was said in a conversation by way of receiving a notification rather than by way of visiting your watchlist?

In the meantime I've added a note to the ticket where we are considering introducing the ability for people to be able to subscribe to be notified whenever a new section/discussion is added to a talk page. PPelberg (WMF) (talk) 19:10, 24 September 2021 (UTC)

Yes, since the notification is shown in any Wikimedia tab, I would notice it much earlier than if I have to switch to the tab where I have my watchlist. It is also similar to other platforms where I have conversations. I get notified wherever I happen to be (and for the best ones, I can also select what to be notified about). Ainali (talk) 19:55, 24 September 2021 (UTC)

Ah, this is helpful! To make sure I'm internalizing what you are describing, can you please read the below and let me know if I've interpreted what you've said in ways that are different from what you meant?

The way I am interpreting the comment you made above.

"I prefer learning when something new is said in a conversation via notifications because notifications are visible to me wherever I am on Wikipedia. The watchlist on the other hand requires that I a) remember to check it and b) leave where I am in order to know if someone has said something in a conversation I'm interested in."

Also, out of curiosity: it sounds like while you're editing Wikipedia you have the page you are editing open in one tab and your Watchlist open in another tab. Assuming this is accurate, are there any other Wikipedia pages you typically have open in tabs while you're editing? PPelberg (WMF) (talk) 00:41, 25 September 2021 (UTC)

I have at least one tab open of Wikidata, Wikimedia Commons, Swedish Wikipedia, English Wikipedia and Meta at all times. Usually several of each. Having them open and switching to them feels easier than switching to the tab. I have the watchlists as the default open page, and then any that have things I would like to read or come back to edit later.

This also reminds me that some other platforms (Mattermost, Slack, LinkedIn, Gmail) can give a visual clue in the favicon that there are notifications, so that if I would happen to be somewhere else knows that something has happened). Ainali (talk) 20:20, 25 September 2021 (UTC)

This additional context is helpful; I appreciate you sharing it, @Ainali and I'm sorry for how long it's taken me to respond here.

I've documented the idea you are raising of including some kind of "visual clue in the favicon" within Phabricator here: T1188#7486621. PPelberg (WMF) (talk) 21:10, 5 November 2021 (UTC)

Jan, do you think that, if they did this, you would see fewer article edits, or make fewer edits to articles? Whatamidoing (WMF) (talk) 19:20, 24 September 2021 (UTC)

Good question. I don't know. I imagine that I would be more active in discussions. That naturally leads to less time to make edits to articles. But hopefully those edits will now have fewer errors and instead be made with a clearer consensus. How it actually will play out, I can't really tell. Ainali (talk) 19:58, 24 September 2021 (UTC)

Last year, Peter told me about some research at Wikia/Fandom. They made it easier to comment on talk pages. The result was more talk, but no improvements to articles. Whatamidoing (WMF) (talk) 20:39, 27 September 2021 (UTC)

I would like this feature, and for me it should be completely separate from the watchlist. The reason why I like the topic notifications is that I don't have to (and don't want to) watchlist talk pages (e.g. local Village pumps). I would like to be able to "subscribe to a talk page" and get notification of new topics and their titles, but I don't want to be automatically subscribed to all new topics on the page. kyykaarme (talk) 19:40, 21 October 2021 (UTC)

One of the things they're looking at is automatically subscribing you to all discussion sections you start, no matter what editing tools you use. This means you could leave a warning message on a newcomer's talk page with a script (does fiwiki have a tool similar to w:en:Project:Twinkle?), and be automatically subscribed to that. (It wouldn't work with MassMessage, however.) Would that work for you? Whatamidoing (WMF) (talk) 00:32, 22 October 2021 (UTC)

We don't have Twinkle or any similar tool. Automatic subscription to self-started discussions could be a good idea, especially if it works the same way as watchlisting, so that you can choose if you want to subscribe to every discussion you started or do it manually each time. kyykaarme (talk) 20:09, 3 November 2021 (UTC)

hi @Ainali! A quick update to share that the functionality you started this thread seeking will be available within the next week.

There will soon be a new "Subscribe" button that appears in all desktop skins. When clicked, you will be notified whenever a new topic is started on this page.

Note: bringing this functionality to mobile will need to happen a bit later, once some technical issues are worked out. PPelberg (WMF) (talk) 00:46, 22 March 2023 (UTC)

Subscribing to lower-level headings, e.g. level 4

phab:T267288: Support new topics at varying heading levels

There don't seem to be any subscribe links at :en:Wikipedia:Categories for discussion/Log/2021 October 23, even though there are reply links. Will subscribe links be added on these sorts of pages? As you can see this page uses level 4 headings for each topic that should have a subscribe link, which might also be a problem. GKFX (talk) 21:29, 23 October 2021 (UTC)

I see subscribe links on en:Wikipedia:Village pump (miscellaneous), so the non-level 2 headings should be the cause. Since it’s currently not defined on the page that “topics” correspond to level 4 headings instead of level 2 ones (since there’s no way to define it), the software isn’t aware of this. Maybe there should be a way to define if topics on a page are not level 2 headings, for example a new magic word. Tacsipacsi (talk) 13:01, 24 October 2021 (UTC)

@GKFX, thank you for making aware of this case.

As @Tacsipacsi accurately described, Topic Subscriptions do not currently support non-H2 section level headings.

Although, we do have a ticket to expand this support and I've added the example you shared here to the ticket in Phabricator where we are tracking this issue: phab:T267288. PPelberg (WMF) (talk) 21:27, 5 November 2021 (UTC)

Level 2 heading followed by a level 3 heading

T295200: Subscribe affordances do not appear when followed by a level 3 heading

I don't see a subscribe link in this discussion :en:Wikipedia:Village pump (proposals)#Removing links to portals from the Main Page's top banner. There is a level 3 heading immediately after the level 2 heading, so maybe that's what's breaking the Notifications. kyykaarme (talk) 09:09, 31 October 2021 (UTC)

Great spot; thank you for reporting this, @Kyykaarme. This ticket now exists as an issue in Phabricator here: phab:T295200. PPelberg (WMF) (talk) 21:21, 5 November 2021 (UTC)

Prototype: Automatic Topic Subscriptions

Many people^[i] have raised the idea of becoming automatically subscribed to discussions you participate in.

Now, there is a prototype ready for you all to try what how this "automatic topic subscription" experience could look and work.

Below is the information you will need to:

1. Try the prototype and
2. Share feedback about the prototype

If any questions come up as you are attempting to try the prototype, please post them here...it is likely someone is wondering something similar to what you are.

---

i. @Ainali, @Dyolf77 (WMF), @Ffffrr, @GKFX, @Klein Muçi, @Kyykaarme, @NGC 54, @Pelagic, @Tacsipacsi, PPelberg (WMF) (talk) 22:39, 5 November 2021 (UTC)

===1. Trying the prototype===

1. On a desktop / laptop computer, visit: https://patchdemo.wmflabs.org/wikis/2f3d9efbec/wiki/Talk:Main_Page
2. Create an account by clicking the Create account link. Note: this is a test wiki so you will not be able to log in using the same username you use on other projects.
3. Return to https://patchdemo.wmflabs.org/wikis/2f3d9efbec/wiki/Talk:Main_Page
4. Start a new discussion
5. Comment in an existing discussion
6. Disable being automatically subscribed to the discussions you start and/or comment in

Notes:

i. For ease of testing, the popup appears every time you get auto-subscribed. In the production version, the popup will only appear once.

ii. Once deployed, being automatically subscribed to discussions will be an opt-in feature for everyone except new accounts. PPelberg (WMF) (talk) 22:39, 5 November 2021 (UTC)

===2. Sharing Feedback===

Once you have tried the prototype and you are ready to share what you think of it, please add a new topic to this talk page by doing the following:

1. "Start a new topic" on this talk page
2. Name this new topic: "Automatic Topic Subscription Feedback: YOUR USERNAME"
3. Write your answers to these questoins:
   1. What did you find unexpected about how the prototype looks and functions?
   2. What do you appreciate about the prototype?
   3. What do you wish was different about the prototype? PPelberg (WMF) (talk) 22:39, 5 November 2021 (UTC)

Reminder: There's still time to share your thoughts. Whatamidoing (WMF) (talk) 18:57, 20 December 2021 (UTC)

Automatic Topic Subscription Feedback: Ainali

1. That it showed every time. I imagined that after I clicked "Okay, I got it" it wouldn't show more. It was also unexpected that if I subscribed to a section, then unsubscribed, and then commented, I was not automatically subscribed to it again.
2. Beautiful popup!
3. If I wasn't surprised by the things mentioned in 1.

But I was actually wanting a way to be notified to new sections on a specific page, not automatically subscribed to something I commented in. I suspect that I will turn this feature off, as I imagine this will result in a lot of notifications I have moved on from (but I might be wrong here, the volumes in real use will be key). Ainali (talk) 23:17, 5 November 2021 (UTC)

But I was actually wanting a way to be notified to new sections on a specific page, not automatically subscribed to something I commented in.

Ah, you're right. I did not accurately remember the interaction we had that led to us creating T263821: Introduce New Topic Notifications. With this in mind, we appreciate you trying out the prototype for a feature you weren't exactly looking forward to ^ _ ^

Okay, now responses to specific pieces of feedback you shared...

I imagined that after I clicked "Okay, I got it" it wouldn't show more.

Comment: We agree with you in thinking the pop-up appearing each time you post a new comment or start a new discussion is not an ideal experience. In the version of Automatic Topic Subscriptions that gets made available in production, the pop-up will only appear once.

It was also unexpected that if I subscribed to a section, then unsubscribed, and then commented, I was not automatically subscribed to it again.

Question: would it be accurate for me to understand what you are saying above as the following? "If I (Ainali) have automatic topic subscriptions enabled, I expect to be subscribed to any discussion I comment in regardless of whether I've previously unsubscribed to said section manually." PPelberg (WMF) (talk) 00:54, 10 November 2021 (UTC)

> "If I (Ainali) have automatic topic subscriptions enabled, I expect to be subscribed to any discussion I comment in regardless of whether I've previously unsubscribed to said section manually."

I think experienced editors will expect the behavior to match the regular watchlist settings, which do not track whether you have previously unwatched a page. Whatamidoing (WMF) (talk) 19:00, 20 December 2021 (UTC)

Automatic Topic Subscription Feedback: Klein Muçi"

1. What did you find unexpected about how the prototype looks and functions?
   1. The popup was unexpected. Generally, we don't get popups at all in our every day wikiwork. That is, if we're not new accounts.
2. What do you appreciate about the prototype?
   1. Strange detail but I appreciate that it doesn't notify me when I comment to my auto-subscribed topic. I don't know why I always thought that would be a bug that would be present in the prototype.
3. What do you wish was different about the prototype?
   1. So far, nothing. I wrote a new topic, I got myself autosubscribed at it. The possibility of unsubscribing was 1 click way. Simple as it should be. I haven't had a chance to see how notifications behave though as I haven't had comments yet. I'll report back here in case I have any new ideas or find any strange behaviors. - Klein Muçi (talk) 00:31, 6 November 2021 (UTC)

We appreciate you reviewing the prototype, @Klein Muçi! Responses to the feedback you shared below...

The popup was unexpected. Generally, we don't get popups at all in our every day wikiwork. That is, if we're not new accounts.

Question: it's helpful to know the popup was unexpected and why you found it to be so. A resulting question for you: did you find the information contained within the popup helpful in any way(s)?

Strange detail but I appreciate that it doesn't notify me when I comment to my auto-subscribed topic. I don't know why I always thought that would be a bug that would be present in the prototype.

Question: would it be accurate for us to understand the above as meaning the following? "I (Klein Muci) assumed that when I added a comment within a discussion I am subscribed to, I would receive a notification for the comment I posted which seems redundant/unnecessary."

I wrote a new topic, I got myself autosubscribed at it. The possibility of unsubscribing was 1 click way. Simple as it should be.

This is wonderful to hear.

I haven't had a chance to see how notifications behave though as I haven't had comments yet. I'll report back here in case I have any new ideas or find any strange behaviors.

Thank you! We would value knowing if/when you encounter anything that you find to be unexpected. PPelberg (WMF) (talk) 01:06, 10 November 2021 (UTC)

@PPelberg (WMF), helpful of course. The only "problem" would be something that is outside of this topic: The preferences tab. Very few new users know about the preferences existence in general and I feel like they tend to avoid spending too much time sorting things out in it even if they're sent there with links. The amount of information/options there can be overwhelming. I've mentioned in another discussion that for the sake of new users, tabs like preferences, the "log out" link, maybe the watchlist, etc. should be changed from link-like to button-like, which Mediawiki rarely uses, not to say never. Buttons are more friendly towards new users and inspire exploration. But, as mentioned, this is another topic.

And yes, that interpretation is correct. Thanks for your attention! :) - Klein Muçi (talk) 01:50, 10 November 2021 (UTC)

I wonder whether it would be better to have a "click here to opt out", rather than sending people to Preferences (which requires clicking multiple times). Whatamidoing (WMF) (talk) 19:03, 20 December 2021 (UTC)

Automatic Topic Subscription Feedback: GKFX

1. What did you find unexpected about how the prototype looks and functions?
   • Testing as directed looked good to me in terms of UI. However, I (with the account GKFX) didn't receive any notifications for these edits (by me as GKFX2) despite being GKFX being subscribed, which seems wrong. I've checked my notification preferences which were all enabled, although I had not set an email address.
2. What do you appreciate about the prototype?
   • Straightforward UI.
3. What do you wish was different about the prototype?
   • I am interested in how "Once deployed, being automatically subscribed to discussions will be an opt-in feature for everyone except new accounts" will work - I hope that discovering how to opt in will be easy enough, particularly for people who are already using the discussion tools available. I would be interested in instead having a checkbox "Subscribe to this discussion" under the reply box, checked by default. This would be much like the "Watch this page" checkbox when editing articles, but with the presumption that people usually do want to see replies to their topics. GKFX (talk) 13:56, 6 November 2021 (UTC)

Thank you for giving the prototype a try and taking the time to articulate what you encountered. Responses below...

I (with the account GKFX) didn't receive any notifications for these edits (by me as GKFX2) despite being GKFX being subscribed, which seems wrong.

Question: do the steps I've listed below accurately and exhaustively describe what you experienced?

1. Visited Patch Demo and created a new account (username: GKFX)
2. Started a new discussion titled New section title
3. Noticed the You have been subscribed popup appear
4. Clicked the Okay, I got it button
5. Logged out of Patch Demo
6. Visited Patch Demo again and created a new account (username: GKFX2)
7. Posted two comments to the New section title discussion you started in step "2."
8. Logged out of Patch Demo
9. Logged back into the GKFX account
10. ❗️Did NOT receive notifications for the comments you posted with GKFX2in step "7."

I hope that discovering how to opt in will be easy enough, particularly for people who are already using the discussion tools available.

We too are curious about whether experienced volunteers will find it easy enough to discover Automatic Topic Subscriptions. We'll be evaluating how "discoverable" Automatic Topic Subscriptions are by looking at the percentage of topic subscriptions that are initiated manually vs. automatically in T280896.

I would be interested in instead having a checkbox "Subscribe to this discussion" under the reply box, checked by default.

Question: Ah, this is an interesting idea. Can you say more here? What do you think would be valuable to you about having the ability to adjust whether you are notified about new comments in a discussion each time you post a new comment or start a new discussion? PPelberg (WMF) (talk) 01:23, 10 November 2021 (UTC)

Missing notifications

I used Firefox's Container Tab feature to do the test, which lets you log into different accounts in different tabs by isolating the cookies (etc.) between each container. So I was logged into GKFX on one tab and GKFX2 on the other, and didn't log out at any point. I think I had:

1. Created the section and let myself be auto-subscribed as GKFX, seeing the dialog box and clicking OK.
2. Unsubscribed and resubscribed at least once to test that interface.
3. Navigated to "Main Page", i.e. away from the talk page.
4. Created GKFX2 in a new container tab
5. Replied to the post as GKFX2
6. Refreshed the page "Main Page" on the first tab (as GKFX). At this point I expected to see the notification icon light up, but nothing happened.
7. I repeated steps 5 and 6 and got the same result again.

I've logged back into those accounts again, and noticed now that "Peter" has also replied to that section, I'm still subscribed to it (there is an [unsubscribe] link in its header), and there is no notification about Peter's edit either.

Subscribe checkbox

What do you think would be valuable to you about having the ability to adjust... I would tend to subscribe to most of the quiet, normal discussions I comment on, as there are only a few people involved and it's good to be able to follow up on any later discussion. However, if there is an enormous controversial discussion, I would be more inclined to just read what has been said so far, express my opinion, but not want to receive any further notifications on the subject unless I'm pinged. (Of course, there is already an unsubscribe button so the choice to opt out of some discussions is there anyway.) The other reason for this suggestion was to make the feature more discoverable by giving it the same familiar, fairly prominent UI that page watching currently has. GKFX (talk) 21:23, 11 November 2021 (UTC)

Tracked in Phabricator
Task T297264

GKFX, volunteer-me is having problems with Firefox, too. Have you tried this out at enwiki, in your regular account (in prefs here)? Is automatic subscription working for you? Also, do you have NoScript or anything similar installed? Whatamidoing (WMF) (talk) 23:13, 20 December 2021 (UTC)

I don't have NoScript or similar installed. I have Firefox's Tracking Protection set to strict, but I wouldn't expect that to interfere. I've tried it on my sandbox talkpage on enwiki and it worked fine, I got notifications along the lines of "GKFX-2 replied in 'New test section'". I remembered that when it broke on the test wiki I had subscribed, unsubscribed and resubscribed, but I tried that on enwiki and it continued to work. Automatic subscription seemed to work OK on enwiki too. GKFX (talk) 23:32, 20 December 2021 (UTC)

I tried commenting from my brand new test account on enwiki (GKFX-2). I enabled automatic subscription in its preferences, replied, and it seemed to auto-subscribe me but without the first-use pop-up expected, and iirc the heading only displayed "[unsubscribe]" after I clicked "[reply]" again. The automatic subscription still worked fine for GKFX-2 in terms of actual notifications being generated, there was just something a bit off on the UI. So still definitely not a reproduction of the behaviour described at the start of this thread. GKFX (talk) 23:40, 20 December 2021 (UTC)

moved pages

T295431: Enable Special:TopicSubscriptions Contents to Update Automatically

The subscription seems to get lost if the (discussion) page ist moved. Peter Gröbner (talk) 06:38, 9 November 2021 (UTC)

That should not happen; the tracking of subscriptions is based on the author and date/time of the first comment, and not on the page or section title. Can you link to an example? Matma Rex (talk) 14:56, 9 November 2021 (UTC)

The subscription was moved from Diskussion:Weißrussland to w:de:Diskussion:Belarus#Änderung_der_Aussprache_von_stimmlosem_zu_stimmhaftem_„s“ (11:29, 15. Okt. 2021 NordNordWest verschob die Seite Diskussion:Weißrussland nach Diskussion:Belarus (gemäß Diskussion zur Namensfrage)).

But I don't understand why this ist not listed in [1].

Greetings, Peter Peter Gröbner (talk) 16:37, 9 November 2021 (UTC)

Thanks.

But I don't understand why this ist not listed in [2].

Apparently, the move log only shows the entry when you search for the old title – in this case, it's shown under Diskussion:Weißrussland: [3]. I found this old bug report about that behavior: T66184.

The subscription was moved from Diskussion:Weißrussland to w:de:Diskussion:Belarus#Änderung_der_Aussprache_von_stimmlosem_zu_stimmhaftem_„s“

I'm sorry if this sounds like a stupid question, but – there haven't been any comments in that section since October, so you wouldn't get any notifications anyway – so are you sure that your subscription was lost?

If you look at the section there, is there an "[abbestellen]" button (unsubscribe), or an "[abonnieren]" button (subscribe)?

Maybe it's confusing if you looked at Spezial:TopicSubscriptions. That interface will always display the original page title and topic title, even if they're changed (because we don't have a good way to track and display this there), but regardless of that, you should receive notifications if you're subscribed to the topic. Maybe we should file a bug about this. Matma Rex (talk) 00:01, 10 November 2021 (UTC)

You are right, I noticed it at the Spezial:TopicSubscriptions as a red link.Yet changing to the moved page the topic wasn't subscribed any more. At least it was noticed as to be made "[abonnieren]". Peter Gröbner (talk) 06:36, 10 November 2021 (UTC)

Are you sure you didn't unsubscribe on the TopicSubscriptions page? I don't know how else this could happen. Matma Rex (talk) 19:35, 10 November 2021 (UTC)

Maybe we should file a bug about this.

Good spot, @Peter Gröbner + @Matma Rex.

Here is a new ticket for this: T295431: Enable Special:TopicSubscriptions Contents to Update Automatically PPelberg (WMF) (talk) 00:38, 10 November 2021 (UTC)

My English is rather poor. What does „good spot“ mean? Peter Gröbner (talk) 06:37, 10 November 2021 (UTC)

Ah, I'm sorry about that, @Peter Gröbner. I was using "good spot" to mean "good observation" ^ _ ^ PPelberg (WMF) (talk) 16:22, 10 November 2021 (UTC)

Automatic Topic Subscription Feedback: Pelagic

T295946: First-Run Experience: Make "Preferences" affordance more obviously clickable

T295948: First-Run Experience: Pop-up appears behind page chrome when starting creating new talk page

T295950: Simplify automatic re-subscribe logic

T295087: Enable people to opt-out of being automatically subscribed from within DiscussionTools

What did you find unexpected about how the prototype looks and functions?

• Wasn't expecting the popup. Though you said there would be one, I hadn't read to the end of the instructions! Presumably in a non-demo environment I would have already visited Preferences to turn the setting on, but having the button to return to preferences is still a good thing. In another sense the pop-up was not unexpected: it's consistent with what happens when I use other features for the first time. On subsequent replies, would I get the normal “you have subscribed” box the same as when I tap the subscribe link?
• In Timeless skin, the text column in the popup is narrower, and the Okay I got it / Preferences buttons stack vertically instead of horizontally. (Not a problem for me, and the size of the box feels proportionate to the size of the page.)
• Creating a new discussion page in Vector, the pop-up is over the header area: the user links and edit / history tabs render on top of the pop-up, not behind it.
• (Not part of auto-subscribe, but noticed that) somehow the main page got added to my watchlist; seems the checkbox in reply tool is on-by-default and in my haste I hadn't expanded Advanced to turn that off.
• There appears to be some logic in place that you won't be auto-resubscribed to a topic that you already unsubscribed from. (!)

What do you appreciate about the prototype?

• As someone already familiar with Reply Tool and topic subscription, I appreciate that autosubscription smoothly fits those together – no mess, no fuss. Tested on desktop web, tablet, no keyboard, Vector (v1 “classic”) and Timeless skins.

What do you wish was different about the prototype?

• That it be available on mobile web also. 😉 I know, all in due time.
• Minor tweaks to z-order, per unexpected above.
• It would be nice to have an option in reply tool to (not)-subscribe as a one-off exception to the general auto-subscribe setting. (Probably more relevant when the setting is off.) How to convey that it's once-only action and not sticky? (I'm imagining a checkbox whose initial state and help tip depend on the underlying preference “[x] Subscribe to this section [?] ^{Unchecking this box will not change your preference to automatically subscribe to topics when replying.}”.) Pelagic (talk) 16:44, 12 November 2021 (UTC)

hi @Pelagic! We appreciate you trying the prototype and sharing the experience you had with it here. Comments and questions in response below...

1) Presumably in a non-demo environment I would have already visited Preferences to turn the setting on, but having the button to return to preferences is still a good thing.

This is helpful confirmation to have. Related to the link to "Preferences" that appears within the pop-up, we're planning to iterate on the link's design to make it more obviously clickable. You didn't mention this explicitly, tho I thought you might value being aware of this work. More details in T295946.

2) On subsequent replies, would I get the normal “you have subscribed” box the same as when I tap the subscribe link?

Interesting question.

Question: Before responding, can you share whether you would expect to see the same "you have subscribed" box as when you manually tap a [ subscribe ] link?

3) In Timeless skin, the text column in the popup is narrower, and the Okay I got it / Preferences buttons stack vertically instead of horizontally. (Not a problem for me, and the size of the box feels proportionate to the size of the page.)

Noted. For now, I'm going to categorize this in my mind as, "Not being an issue. Although, it's helpful to be aware of how the pop-up appears in Timeless."

If you think we should be thinking about this differently, please let us know as much!

4)Creating a new discussion page in Vector, the pop-up is over the header area: the user links and edit / history tabs render on top of the pop-up, not behind it.

Great spot!

Question: Can you please read the steps I've documented in T295948 and let me know if I've missed any part of what you were describing above?

5) ...somehow the main page got added to my watchlist

Question: To be doubly certain, would it be accurate for me to understand the above as you saying, "It was unexpected to me that in responding to a discussion on the Main page's talk page that I would be automatically be adding the Main page to my watchlist."

6) There appears to be some logic in place that you won't be auto-resubscribed to a topic that you already unsubscribed from

Interesting! We intentionally made it so when someone is automatically subscribed to a conversation, and they subsequently unsubscribe from that conversation, that person should remain unsubscribed to that conversation until they manually resubscribe to it.

Although, you sharing the feedback about is leading me to wonder whether we've assumed incorrectly here and if people would have an easier time "grasping" the feature were the logic that determines whether you are automatically subscribed to a discussion were to remain consistent in all scenarios.

In any event, I've filed T295950 for us to consider adjusting this logic.

7) ...I appreciate that autosubscription smoothly fits those together – no mess, no fuss.

The team will be glad to hear this ^ _ ^

8)That it be available on mobile web also. 😉 I know, all in due time.

Us too! You can track our progress on introducing topic subscriptions – manual and automatic – on mobile in T280821.

9)Minor tweaks to z-order, per unexpected above.

Question: can you say more here? Are you referring to the issue that's now described in T295948?

10) It would be nice to have an option in reply tool to (not)-subscribe as a one-off exception to the general auto-subscribe setting.

Question: Can you share a scenario where you'd want to comment in a discussion, or start a new one, and NOT wanting to be automatically subscribed to it? In the meantime, I've added you to T295087 where we are considering implementing something similar to what you're describing here. PPelberg (WMF) (talk) 02:56, 18 November 2021 (UTC)

Discussions that begin with a level-3 section

At this discussion, I wanted to subscribe, but couldn't because I began it with a level-3 section. Could something be tweaked so that these sorts of discussions will be recognized? Cheers, Sdkb ^talk 21:48, 8 February 2022 (UTC)

Previously requested here: T298617.

Removing the ===Background=== sub-heading from your section would make subscriptions work there. Matma Rex (talk) 22:11, 8 February 2022 (UTC)

Subscribe to replies

I recently saw task T304755 and was thinking, a possible alternative that could help account for these edge cases would be allowing people to subscribe to a reply (signature) and they would receive notifications for all replies to that.

This could be implemented by adding a "more options" three-dot button (...) next the the reply button where the following options could be "Subscribe" and "Link to reply". Lectrician1 (talk) 00:50, 27 March 2022 (UTC)

am not sure that would be useful very often. Whatamidoing (WMF) (talk) 23:12, 6 April 2022 (UTC)

Requested feature: Option to autosubscribe to sections you start on pages you don't watchlist

Every time so far that I've started a new thread on a page I don't watchlist, I've wanted to subscribe to it. It'd be nice if there were an option that did this automatically to save me the click/take care of it so I don't forget. Sdkb ^talk 18:30, 10 April 2022 (UTC)

This option already exists, though it hasn't been announced. See the last item in https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-editing-discussion

I find that it usually works for my work account (which I use in Chrome or Safari) but not for my volunteer account (in Firefox). Also, it's doesn't pay any attention to whether the page is already on your watchlist, and it may be restricted to edits made using DiscussionTools (e.g., when you [reply], but not when you [edit source]). Whatamidoing (WMF) (talk) 16:46, 11 April 2022 (UTC)

I found some problem here - I edited section, I have there notice [Subscribed], but in my preferences was this option disabled (And I haven't change this option in last months) JAn Dudík (talk) 13:02, 27 May 2022 (UTC)

Do I have this correct?

• The preference for automatic subscriptions is disabled in your account
• When you create a new section, you get subscribed to it anyway
• If anyone replies, you get a message in Special:Notifications

Is that right? Whatamidoing (WMF) (talk) 20:51, 27 May 2022 (UTC)

Notifications mix

Hi. There is a serious problem in talk page subscriptions. Large enough to turn off the mechanism for all the users until the fix, probably. I can't create a phab ticket, because there is no way to list reproductions steps. Is this a good place here to describe the problem? Thank you. IKhitron (talk) 19:03, 30 September 2022 (UTC)

Yes, please let us know. What's the problem? Whatamidoing (WMF) (talk) 21:41, 30 September 2022 (UTC)

The problem is that the tool ignores Special:TopicSubscriptions. I get notifications for random topics on random pages. For example, if I have page A topic B subscribed, I get all the time notifications for some unsubscribed topics C, D, E, F,... about a new post there, while the posts listed are not from the same topic. For example, for

Topic C
new post C1
Topic D
new post D1
Topic E
new post E1

I get a triple notification about posts C1, D1, E1, all of them in topic D. If I do not mark it as read, and later the page will look like

Topic F
new post F1

the notification will be now about posts C1, D1, E1, F1, all of them in topic F. Another example, I all the time get notifications about removed topics, when I am not subscribed for the topic, its page is not in my Watchlist, and the topic was created three days ago, when I opened the page last time three months ago. It looks like all the notifications are send to me instead somebody else, and mine are send to somebody, too. But, for some subscribed topics I get exactly what is expected. The list in Special:TopicSubscriptions looks fine. IKhitron (talk) 00:09, 1 October 2022 (UTC)

Are you having any other problems with your Notifications list? (For example, is the number of notifications frequently wrong, so it says 1 unread message but there are zero?)

Is "unsubscribed topic C" (located on the Page A, posted after the ==B== section) a ==Level 2== or a ===Level 3=== section? What does ?action=info say about lint errors on Page A? Whatamidoing (WMF) (talk) 02:17, 1 October 2022 (UTC)

No I didn't see anything like this.

Well, taking one such a page for example. All the topics are level 2 there. There is one missing end tag (i) and 21 obsolete tags.

(Doing this found a bug in Linter itself.) IKhitron (talk) 12:00, 1 October 2022 (UTC)

Can you give specific examples of the affected pages and topics? We haven't heard of this happening to anyone else.

If you don't want to discuss them publicly, please do it in a new "security issue": https://phabricator.wikimedia.org/maniphest/task/edit/form/75/

I can look in the database for your subscriptions and notifications once I know what I'm looking for, and try to figure out what is happening. Matma Rex (talk) 12:24, 1 October 2022 (UTC)

This is a page for example: he:wikipedia:דלפק ייעוץ. A lot of topics there. IKhitron (talk) 13:30, 1 October 2022 (UTC)

I've subscribed to the one called "REVISIONMONTH name?" I haven't had a subscription notification at hewiki for about 6 weeks, and never on that page, so it should be pretty obvious if I get notifications for other sections. Whatamidoing (WMF) (talk) 19:17, 1 October 2022 (UTC)

I can see why it happens. You can stop receiving these notifications by unsubscribing here: https://he.wikipedia.org/w/index.php?title=XXX&action=dtunsubscribe&commentname=h-פלוני_שכתב_ללא_חתימה-2000-01-09T22:00:00.000Z (this link might also work for other people experiencing the problem).

This happens because the "unsigned" template תבנית:לא_חתם generates a fake invisible username and timestamp when none is provided (using this sub-template: תבנית:לא_חתם/חותם). This is a clever hack to make reply tool work, but it causes topic subscriptions to get confused, because we track which topic you're subscribed to by the username and timestamp of the oldest comment (see details here: Extension:DiscussionTools/How it works#Tracking topics).

As a result, if you subscribe to any topic where the first comment was signed using that template without providing a username and timestamp, you will be subscribed to every such topic.

I don't see a good way to fix it in our code, but I'll think about it. For now, I suggest removing the feature from the template. Matma Rex (talk) 21:03, 1 October 2022 (UTC)

The problem is that this fix is not just for this tool, and removing it will cause more problems. Does it use the substituted transclusion of the wikicode of the signature, or the parsed result? IKhitron (talk) 21:45, 1 October 2022 (UTC)

Your answer might be in Extension:DiscussionTools/How it works. Whatamidoing (WMF) (talk) 03:26, 11 October 2022 (UTC)

Thanks, I'll check it out. Meanwhile, I'm continuing to get notifications about archived topics on pages I do not watch and did not open for years. And yesterday I saw somd page first time in my life, with all the topics marked as being watched. The page is not watched, and none of these topics is on Special:TopicSubscriptions. IKhitron (talk) 18:23, 12 October 2022 (UTC)

You can stop receiving these notifications by unsubscribing here: https://he.wikipedia.org/w/index.php?title=XXX&action=dtunsubscribe&commentname=h-פלוני_שכתב_ללא_חתימה-2000-01-09T22:00:00.000Z (this link might also work for other people experiencing the problem). Matma Rex (talk) 18:58, 12 October 2022 (UTC)

Why? It's completely different pages. IKhitron (talk) 19:17, 12 October 2022 (UTC)

Because of a technical decision we made long ago, where we don't check the page on which you subscribed, since that made it easier to keep the notifications working when the topic is moved to a different page. Matma Rex (talk) 23:22, 20 October 2022 (UTC)

I see. Very well, thanks. I did this. Let's see in the next few days if it helped and all the problems were solved. I'll be back. IKhitron (talk) 23:45, 20 October 2022 (UTC)

Well, I'm back. It's still very problematic, but the problems come from anonyms indeed. Thank you. I think this topic should be resolved now. IKhitron (talk) 18:59, 18 December 2022 (UTC)

Getting archive notifications for blanking

It's fairly common for vandals/inexperienced test editors to blank pages, e.g. here. This isn't normally a problem because it's easily/quickly reverted, but I've been getting "topic archived" notifications from it, which makes it a lot more annoying. I'd like to see the system improved so that these distractions go away. Sdkb ^talk 07:32, 6 January 2023 (UTC)

Do you want to get notifications when any subscribed discussions are removed from the talk page, or are you hoping that they can distinguish between blanking and true archiving? Whatamidoing (WMF) (talk) 17:51, 10 January 2023 (UTC)

I don't want to be getting notifications for test/vandalism blanking. Sdkb ^talk 17:54, 10 January 2023 (UTC)

If you are willing to give up notifications for true archiving as well, then you can turn off all notifications related to talk page archiving at https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-echo Whatamidoing (WMF) (talk) 17:58, 10 January 2023 (UTC)

Anchor imprecise

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Please look at this subject. Patafisik (WMF) (talk) 16:48, 17 February 2023 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Notification on removing a topic with same headline

Tracked in Phabricator
Task T334906

Hey,

I don't know if this is already reported: I've automatically subscribed a topic on a usertalkpage de:Benutzer_Diskussion:Toni_Müller#Wikipedia-Aktuelles_(40._Kalenderwoche) with my reply. As this was a massmessage, there are other topics with the same headline. Today two users removed the topic form their talkpage ([https://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:Hyperdieter&oldid=prev&diff=237913182] and I got a notification about the removal, although I've only subscribed this one on Toni Müllers page. An Special:TopicSubscriptions it shows the correct page, but on every usertalk where this headline occurs the "subscribe"-button is activated Janui (talk) 08:51, 6 October 2023 (UTC)

Confusing bug when watching section on a transcluded page

I'm currently watching a topic (the RfC on Electronic Intifada) on the English Wikipedia's reliable sources noticeboard.Intifada Recently, someone accidentally transcluded that page to a talk page. When they fixed the transclusion, I got a notification saying the discussion was closed. wiki Chess (talk) 05:27, 23 December 2023 (UTC)

Sorry you experienced this. You got a notification that the thread was removed or archived, right?

We recently deployed permalinks for talk pages at all wikis (all but English Wikipedia; it's coming soon!). This would solve the issue. Trizek_(WMF) (talk) 15:50, 5 February 2024 (UTC)

Translation into Japanese

日本語版において、"subscribe / unsubscribe"の訳はデスクトップ版では「更新を通知 / 通知を解除」ですが、モバイル版では「購読 / 購読解除」と、表記が異なります。分かりやすいように、「更新を通知 / 通知を解除」に表記を統一してほしいです。

In Japanese, the translation of "subscribe / unsubscribe" is "更新を通知 / 通知を解除" in Desktop, but "購読 / 購読解除" in Mobile view. Could you unify the translation to "更新を通知 / 通知を解除" for easier understanding. IXTA9839 (talk) 07:09, 24 December 2023 (UTC)

Translations can be updated on TranslateWiki. Matěj Suchánek (talk) 11:14, 24 December 2023 (UTC)