Topic on Talk:Talk pages project/Notifications/Flow

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?

I want to sub as long as the discussion is open.

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.

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.

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.

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.

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

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

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?

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!

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

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

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.

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.

How many conversations stay active for a year? or even a month?

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?

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.

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.

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.

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.

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, 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?

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.

Well, okay, if it's a problem, set whatever default you need to. I'd personally like at least six months, though.

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?

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.

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