Page MenuHomePhabricator

[Implementation] Automatic topic subscriptions (DiscussionTools)
Closed, ResolvedPublic

Description

Open questions

  • What should happen when "Person 1" is automatically subscribed to "Conversation A" and then unsubscribes from "Conversation A"?
    • "Person 1" should remain unsubscribed to "Conversation A". This is documented in the newly-created Unsubscribing section within ===Implementation details.

Implementation details

Meta
  • Functional Requirements - @ppelberg
  • Platforms: mobile and desktop
  • 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. (We previously planned to handle the full-page source editor separately in T289021.)
  • The software should continue considering a discussion/conversation to be any == H2 == section that exists on pages - used for hosting conversations (e.g. talk pages, pages in wgExtraSignatureNamespaces namespaces...more in T249036).
  • No new comment notifications should be sent for comments authored by users the would-be recipient has muted in Special:Preferences#mw-prefsection-echo > Muted users
  • By default, automatic topic subscriptions should be enabled for all people who have the Enable topic subscription enabled
  • Design Requirements @iamjessklein
    • Not needed for this step of the workflow.
  • QA specifications
    • See Functional requirements above.

Relation to existing topic subscriptions
  • When automatic topic subscriptions are deployed, no one should be automatically subscribed to all topics they previously participated in.
Initiating a subscription
  • Functional Requirements - @ppelberg
  • For people who have automatic topic subscriptions enabled, they should be automatically subscribed to a topic after taking either of the following actions:
    1. Posting a comment in a discussion they are not already subscribed to
      • After "1)", people should see the [ subscribe ] affordance on the page turn into [ unsubscribed ]
    2. Starting a new discussion
  • Design Requirements @iamjessklein
    • Not needed for this step of the workflow.
  • QA specifications
    • See Functional requirements above.

Being made aware of automatic subscription | T262103
  • Functional Requirements - @ppelberg
  • The first time someone is automatically subscribed to a conversation, they should be made aware:
    • They will receive a notification if/when someone posts a new comment in that discussion
    • Where they can adjust whether they are automatically subscribed to discussions they participate in the future
  • Design Requirements @iamjessklein
    • User story
      • As someone posting a comment or starting a new conversation for the first time after automatic topic subscriptions became available:
        • I want to know that I will be made aware when someone posts a new comment in that discussion so that I have an accurate expectation for how I will know if someone responds to me.
        • I want to know where I can adjust whether I am automatically subscribed to the future discussions I start and/or participate so that I can ensure the notifications I receive are valuable to me.
    • Mockups
      • Mockups will be created in T262103.
  • QA specifications
    • See Functional requirements and Mockups above.

Notification delivery/receipt (no implementation required)
  • Functional Requirements - @ppelberg
  • In general, new comment notifications initiated via an automatic subscription should be delivered in the same ways they are when initiated via manual subscriptions (T263820).
  • Notifications about new comments in sections people are subscribed to should appear in Notices
  • Design Requirements @iamjessklein
    • Not needed for this step of the workflow.
  • QA specifications
    • See Functional requirements above.

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.

Managing automatic subscription behavior
  • Functional Requirements - @ppelberg
    • The setting that controls the channels through which new comment notifications are delivered should continue to be: Special:Preferences#mw-prefsection-echo > Talk page subscription
    • People should be able to enable/disable being automatically subscribed from all conversations they start and/or comment in within Special:Preferences#mw-prefsection-editing --> Discussion pages
      • This setting should only be visible to people who have the Talk page subscription setting enabled. More in T263819#7143367.
      • This setting should read: Automatically subscribe to topics. / When you start a new discussion or comment in an existing discussion, you will be automatically notified when others post new comments to it.
    • When a user disables the automatic subscription setting, their existing automatic subscriptions should continue sending notifications.
      • To unsubscribe from conversations in this case, people should be able to use the affordance within Echo that was implemented in T279150.
    • There should be one notification method setting (web/email/apps/none) that applies to topic subscriptions that are initiated manually and automatically
  • Design Requirements @iamjessklein
    • Not needed for this step of the workflow.
  • QA specifications
    • See Functional requirements above.

Minimum Test Case

Starting a new discussion

  1. On desktop, log in to the Beta Cluster
  2. Visit Special:Preferences: https://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-editing
  3. Locate the Automatically subscribe to topics setting and verify it is disabled
  4. Enable the Automatically subscribe to topics setting
  5. Visit a talk page https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Cats
  6. Start a new discussion on said talk page
  7. Verify the You have subscribed popup appears upon publishing said topic
  8. Verify there is an [ unsubscribe ] affordance within the == H2 == of the section you just started

Participating in an existing discussion

  1. On desktop, log in to the Beta Cluster
  2. Verify the the Automatically subscribe to topics setting is enabled
  3. Visit a talk page https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Cats
  4. Publish a comment in an existing discussion on said talk page
  5. Verify the [ subscribe ] affordance within the == H2 == of the section you published a comment in transitioned to an [ unsubscribe ] affordance upon publishing the comment [in Step "6."]

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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?
  2. When a user disables the automatic subscription setting, should their existing automatic subscriptions stop sending notifications?
  3. Should the user be able to set notification methods (web/email/apps/none) separately for their manual and automatic subscriptions?

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

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

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)

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

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.

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.

ppelberg renamed this task from [Implementation] Automatic topic subscriptions to [Implementation] Automatic topic subscriptions (DiscussionTools).Aug 17 2021, 12:47 AM
ppelberg updated the task description. (Show Details)

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/

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.

@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:
T295946 and T295950.

@ppelberg: FYI, the outstanding issues that are left fixing to close this task before next week's target of T295428 are:
T295946 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 (T295946 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 T295946 and T295950

@ppelberg: FYI, the outstanding issues that are left fixing to close this task before next week's target of T295428 are:
T295946 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 (T295946 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 T295946 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.

! In T284836#7572908, @Ryasmeen wrote:
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.

Wonderful. Thank you for confirming, @Ryasmeen.

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/