Musing about implementation details:

I think the obvious approach is to treat auto subscriptions almost exactly like the manual ones, with an entry in the database for each one and the same logic used to send notifications, except that they're created after commenting rather than after clicking [subscribe].

We should mark them somehow to distinguish them from manual ones though. It won't have any affect right now, but it would be useful in the future for the management interface (T273342), and it would also be necessary if we wanted to answer "yes" to my questions 2 or 3 in previous comment. We could extend sub_state (currently representing two states: "0: unsubscribed; 1: subscribed") by adding a third state representing an automatic subscription.

Alternatively, we could also not store anything in the database, and instead whenever a comment is posted, check if each participant has auto subscriptions enabled, and send them a notification if so. We'd need this approach if we wanted to answer "yes" to my question 1 (or some combination of this and the other one). But if we don't need it, we probably shouldn't do it this way, it seems more difficult to understand and debug.

The database vs scanning participants decision also affects what happens if someone disappears from a conversation. I can imagine two cases:

• The comment is removed or the signature changed (potentially by a vandal) in a way that makes it unrecognizable. If the comment is removed, it’s unclear what should happen, but I think keeping the user subscribed leads to less confusion. (This means automatic subscriptions should be stored in the DB.)
• The user is renamed. In this case, the notifications should definitely continue to be delivered. AFAIK currently user renames aren’t followed, but this case can be resolved also by following renames (if it’s realistically feasible), not only by storing automatic subscriptions in the database.

Also, similar to the first case, it may currently (until T255324 is resolved) happen that the signature saved with the comment isn’t recognizable in the first place, but I think it should be resolved in T255324. (If the user uses the Reply Tool or New Discussion Tool to draft the comment, we may give them a hint that automatic subscription won’t work until they fix their signature, though.)

In T284836#7222639, @matmarex wrote:

A few things are not completely clear to me:

1. When we deploy the feature, should every user also be automatically subscribed to all topics they previously participated in?

No.

1. When a user disables the automatic subscription setting, should their existing automatic subscriptions stop sending notifications?

No.

1. Should the user be able to set notification methods (web/email/apps/none) separately for their manual and automatic subscriptions?

No.

I'm guessing that the answer to all of these is "no".

Yes ;)

Note: I've updated the task description to reflect the above; @matmarex, please comment if anything I've added in T284836#7223113 is ambiguous/unexpected.

@Tacsipacsi Thanks, good points (particularly about user renames, I did not think about that).

(Added the open question that surfaced during the team's 21 July standup meeting to the topic description)

In T284836#7230643, @ppelberg wrote:

(Added the open question that surfaced during the team's 21 July standup meeting to the topic description)

Added the decision we came to during today's standup to the task description.

The first-time notification about auto-subscription might be a bit tricky.

Per the requirements, we want to auto-subscribe users when they post a comment using the wikitext editor too, and we want to notify them about it too:

The editing interface people are using to start a new discussion or post a new comment should NOT impact their - ability to automatically be subscribed to a topic.
The first time someone is automatically subscribed to a conversation, they should be made aware: (…)

The problem in this scenario is: we can't detect whether they posted a comment until we've ran our discussion parsing algorithm on the page, which currently is done as "deferred update" (potentially after the user is already viewing the page with their comment saved), so that saving the changes is faster. We're going to have to somehow wait for that…

We can get away with some inefficiency, since we only need to display the notification once per user, and only on talk pages. But I'll need to think how to do this, without slowing down other edits.

(When posting a comment with the reply tool or posting a new topic, this is not a problem, since we know ahead of time that there will be a new comment and thus an auto-subscription.)

In T284836#7280078, @matmarex wrote:

The first-time notification about auto-subscription might be a bit tricky.

@matmarex the complexity you are sharing here is clear and helpful. A resulting question for you...

• Considering the architecture/implementation you have in mind, would it be possible to handle the wikitext editor and DiscussionTools implementations of automatic topic subscriptions sequentially? Asked another away: could we first introduce automatic topic subscriptions "within" DiscussionTools and then in a second iteration, extend the functionality to the wikitext editor?

Here's the thinking that's behind the questions above...

1. Wikitext editor implementation sounds like it's going to be less straightforward than the DiscussionTools implementation
2. To start, the priority is for us to learn learning whether the auto-subscribe logic – starting a new topic and posting a new comment – and first-run experience (T262103) feels "right."
3. I do not think limiting this initial release to DiscussionTools will hinder what's described in "2."

Yeah, probably.

In T284836#7285417, @matmarex wrote:

Yeah, probably.

Great. Then, let's do this:

1. Start be limiting the initial automatic topic subscription implementation to comments made, and conversations started, with DiscussionTools.
   • This work will happen in this ticket (T284836).
2. Once we are confident in the auto-subscribe logic and first-run experience (T262103), we can extend this to the source editor.
   • This work will happen in T289021.

I've updated the task description to reflect the above.

Change 713322 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Minor cleanups in topic subscription code

https://gerrit.wikimedia.org/r/713322

Change 713538 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Automatic topic subscriptions

https://gerrit.wikimedia.org/r/713538

This patch implements almost all requirements (for both reply tool and old wikitext editor), except for:

After "1)", people should see the [ subscribe ] affordance on the page turn into [ unsubscribed ]
Being made aware of automatic subscription | T262103 (entire section)

Change 713322 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Minor cleanups in topic subscription code

https://gerrit.wikimedia.org/r/713322

Test wiki created on Patch Demo by PPelberg (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/6b4037a7d2/w/

In T284836#7287203, @ppelberg wrote:

Great. Then, let's do this:

1. Start be limiting the initial automatic topic subscription implementation to comments made, and conversations started, with DiscussionTools.
   • This work will happen in this ticket (T284836).
2. Once we are confident in the auto-subscribe logic and first-run experience (T262103), we can extend this to the source editor.
   • This work will happen in T289021.

On second thought, I'd like to fold this work back into this task.

Reasoning:

• I'd like us to commit to fully supporting the full-page source editor wherever we can, to ensure we don't leave the people using it behind when working on new features.
• I worry a little that if we leave the hard part for last, we might not actually ever get around to doing it, so I'd like to do it first.
• In the long term, it will be easier to maintain this feature if we have just one implementation, rather than separate reply tool and full-page source editor implementations.
• It's not actually that hard to implement, I just needed a few days to think it through – but that happens in parallel with other work :D

Change 713966 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Update the [subscribe] buttons when auto-subscriptions are added

https://gerrit.wikimedia.org/r/713966

That patch implements updating the [ subscribe ] affordances (and also backend things we'll need for the first-run experience, but not the interface yet), when using the reply tool or the full-page source editor.

I guess I'll attach the first-run experience patch to T262103 when I write it, so this task is basically ready.

Test wiki created on Patch Demo by PPelberg (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/31ac26cb5b/w/

Hello. I'm planning to integrate the topic subscriptions API into Convenient-Discussions (in fact, am already working at). CD has its own "watch section" functionality (which includes desktop notifications on open pages and highlighting edits and sections in various places), and users have sections they comment in automatically added to the watchlist by default. As Echo is inaccessible for CD's (a gadget) section watching, users can benefit from this integration, which is planned to imply, for a start, just subscribing to a topic when the user watches it in CD and unsubscribing when the user unwatches.

Regarding automatic subscriptions, I have a question:

Unsubscribing

• When someone is automatically subscribed to a conversation, and they subsequently unsubscribe from that conversation using any method (e.g. clicking [unsubscribe] on the talk page or unsubscribing from within Echo), that person should remain unsubscribed to that conversation until they manually resubscribe to it.

As I understand, effectively this means a distinction between the "unsubscribed" state of a topic ("the user purposefully did unsubscribe") and the undefined state ("the user didn't subscribe").

But is there a way to know which topics on a page the user has unsubscribed from? Especially if the user doesn't have DT enabled. From what I currently see at https://meta.wikimedia.beta.wmflabs.org/w/api.php?action=help&modules=main, I expect the answer is "no"? Apart from manually parsing a page with ?dtenable=1 in the background for some metadata if there is such.

It would be very helpful to have such a method in the API so that my tool and other possible tools could keep up with the functionality available in DT itself. Apart from automatic topic subscriptions, having the subscription state of the topics on the current page (or even on all pages) would be useful as well, as this would potentially eliminate the need for CD to rely on its own not-exactly-neat (due to limitations of a gadget) implementation.

@Jack_who_built_the_house It is not possible currently, but the patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/ /713966 will both add an API to check the subscription state (action=discussiontoolsgetsubscriptions), and change the markup of the (un)subscribe buttons to distinguish no subscription from a muted subscription (in the 'data-mw-subscribed' attribute). You can try them out on the Patch Demo wiki.

Writing this comment made me realize that proposed the API and the markup behave inconsistently, I might change them a bit. I should also probably clarify in a few places that unsubscribing really is muting.

@matmarex This is great! Is there any idea when this API may arrive? I'm trying to figure out is it worth it for me to try to synchronize CD's registry of watched sections and topic subscriptions (for newly watched topics), which will entail some clumsy solutions, or should I just wait for the discussiontoolsgetsubscriptions API to arrive to switch to the topic subscriptions API completely.

In T284836#7316278, @Jack_who_built_the_house wrote:

@matmarex This is great! Is there any idea when this API may arrive? I'm trying to figure out is it worth it for me to try to synchronize CD's registry of watched sections and topic subscriptions (for newly watched topics), which will entail some clumsy solutions, or should I just wait for the discussiontoolsgetsubscriptions API to arrive to switch to the topic subscriptions API completely.

I don't know when, but we could probably do it sooner than the rest of the work. I filed a separate task for the API work: T290185.

Change 716067 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Automatic topic subscriptions (only for reply tool and new topic tool)

https://gerrit.wikimedia.org/r/716067

Change 713538 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Automatic topic subscriptions (on any edit)

https://gerrit.wikimedia.org/r/713538

Change 716067 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Automatic topic subscriptions (only for reply tool and new topic tool)

https://gerrit.wikimedia.org/r/716067

Change 713966 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Update the [subscribe] buttons when auto-subscriptions are added

https://gerrit.wikimedia.org/r/713966

@ppelberg: FYI, the outstanding issues that are left fixing to close this task before next week's target of T295428 are:
T298636 and T295950.

In T284836#7557854, @Ryasmeen wrote:

@ppelberg: FYI, the outstanding issues that are left fixing to close this task before next week's target of T295428 are:
T298636 and T295950.

Excellent and understood, @Ryasmeen.

Would it be accurate for us to think "1." and "2." below are accurate? If yes, I'm thinking we can resolve this task considering the additional work on the issues you've identified will happen in separate tickets (T298636 and T295950 ) and no remaining sub-tasks of this ticket remain open.

1. Automatic Topic Subscriptions QA review has been completed
2. QA has verified Automatic Topic Subscriptions are working as expected, save for the issues identified in T298636 and T295950

In T284836#7571423, @ppelberg wrote:

In T284836#7557854, @Ryasmeen wrote:

@ppelberg: FYI, the outstanding issues that are left fixing to close this task before next week's target of T295428 are:
T298636 and T295950.

Excellent and understood, @Ryasmeen.

Would it be accurate for us to think "1." and "2." below are accurate? If yes, I'm thinking we can resolve this task considering the additional work on the issues you've identified will happen in separate tickets (T298636 and T295950 ) and no remaining sub-tasks of this ticket remain open.

1. Automatic Topic Subscriptions QA review has been completed
2. QA has verified Automatic Topic Subscriptions are working as expected, save for the issues identified in T298636 and T295950

That's correct @ppelberg. The QA review on Automatic Topic Subscriptions was completed two weeks ago and these two issues were raised on our team Slack channel. I see now that they have been marked as sub-tasks of T295428 not this implementation ticket since they are enhancements/improvements, in which case we can close this one.

Test wiki on Patch demo by PPelberg (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/6b4037a7d2/w/

Test wiki on Patch demo by PPelberg (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/31ac26cb5b/w/