Talk:Talk pages project/Notifications

Jump to navigation Jump to search

About this board

First feature: subscribing to topics

32
Summary by PPelberg (WMF)

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:

PPelberg (WMF) (talkcontribs)

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) (talkcontribs)

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

Accordingly, I'm going to tag *some* of the people who have participated in those conversations who we think will have valuable insight to share as the Editing Team begins designing and implementing this functionality:

@Sdkb, @Vriullop, @Mihia, @Another Believer, @Enterprisey, @Xneb20, @Jack who built the house, @Rjclaudio, @Timeshifter, @Drcrazy102, and @Pokéfan95.


---

1. https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2016/Categories/Watchlists#CW2016-R043

2. https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2015/Watchlists#Section_watchlists

3. https://en.wikipedia.org/wiki/User:Enterprisey/section-watchlist.js

4. https://commons.wikimedia.org/wiki/User:Jack_who_built_the_house/Convenient_Discussions

Sdkb (talkcontribs)

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.

PPelberg (WMF) (talkcontribs)

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.

Sdkb (talkcontribs)
Whatamidoing (WMF) (talkcontribs)
Jack who built the house (talkcontribs)

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

Matma Rex (talkcontribs)

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.

Enterprisey (talkcontribs)

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.

Jack who built the house (talkcontribs)

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

Matma Rex (talkcontribs)

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

GhostInTheMachine (talkcontribs)

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.

Matma Rex (talkcontribs)

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.

PPelberg (WMF) (talkcontribs)

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

Enterprisey (talkcontribs)

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.

PPelberg (WMF) (talkcontribs)

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.

Jack who built the house (talkcontribs)

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

PPelberg (WMF) (talkcontribs)

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.

Jack who built the house (talkcontribs)

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.

Timeshifter (talkcontribs)

I appreciate being asked for my opinion, but I have long ago given up on meaningful discussion on Mediawiki.org. Because I hate Flow, or whatever this talk page software is on MediaWiki.org. I suggest moving this discussion to English Wikipedia where the talk pages work fine. Except for of course, section notification. :)

The 2nd most important missing notification is interwiki talk section notification in watchlist format. I rarely check the Mediawiki.org watchlist. It's too much trouble. See:

Ping me please if you want a reply. I notice that the ping template is different here too. Grrr.

Vriullop (talkcontribs)

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.

Timeshifter (talkcontribs)

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.

PPelberg (WMF) (talkcontribs)

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.

Timeshifter (talkcontribs)

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.

Matěj Suchánek (talkcontribs)

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.
PPelberg (WMF) (talkcontribs)

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?

Matěj Suchánek (talkcontribs)

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.

Jack who built the house (talkcontribs)

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

PPelberg (WMF) (talkcontribs)

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.

Pelagic (talkcontribs)

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.

PPelberg (WMF) (talkcontribs)

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?

Whatamidoing (WMF) (talkcontribs)

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.

Reply to "First feature: subscribing to topics"

General point: separation of content from discussion

10
SMcCandlish (talkcontribs)

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.

Nemo Le Poisson (talkcontribs)

+1

PPelberg (WMF) (talkcontribs)

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.

SMcCandlish (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)
SMcCandlish (talkcontribs)

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.

PPelberg (WMF) (talkcontribs)

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"

SMcCandlish (talkcontribs)

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

Whatamidoing (WMF) (talkcontribs)

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.

SMcCandlish (talkcontribs)

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.

Reply to "General point: separation of content from discussion"

Channel parity

7
Summary by PPelberg (WMF)

T263820: Use case #2: Subscribing to topics

Darren-M (talkcontribs)

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.

SMcCandlish (talkcontribs)

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.

PPelberg (WMF) (talkcontribs)

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.

Johan (WMF) (talkcontribs)

Just so everyone knows, the iOS team is actively working on notifications (and has been doing so for a while).

PPelberg (WMF) (talkcontribs)

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

Johan (WMF) (talkcontribs)

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) (talkcontribs)

(In short: no. There should be, but there isn't. But there will be soon.)

Reply to "Channel parity"

Enable Wikipedia projects to watch Talk pages

3
Llywrch (talkcontribs)

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

PPelberg (WMF) (talkcontribs)

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

Whatamidoing (WMF) (talkcontribs)
Reply to "Enable Wikipedia projects to watch Talk pages"
Trizek (talkcontribs)

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?

PPelberg (WMF) (talkcontribs)

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?

Trizek (talkcontribs)

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

Whatamidoing (WMF) (talkcontribs)

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.

Reply to "Inbox"

Attirer les gens sur une discussion

3
Summary by PPelberg (WMF)

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

Nemo Le Poisson (talkcontribs)

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

PPelberg (WMF) (talkcontribs)

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.

Nemo Le Poisson (talkcontribs)

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.

Reply to "Attirer les gens sur une discussion"
There are no older topics