Page MenuHomePhabricator

[Implementation] Automatic topic subscriptions
Open, Needs TriagePublic

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

Related Objects

Event Timeline

LZaman updated the task description. (Show Details)

@ppelberg Hi Peter, I created this child ticket as we discussed here. However, this ticket needs to be refined with the full team since it's not clear to me if all functional requirements are understood. The next opportunity to discuss this with the team is on June 23rd, 4 UTC. Let me know if you have questions about this recommendation.

@ppelberg Hi Peter, I created this child ticket as we discussed here.

Excellent, @LZaman.

However, this ticket needs to be refined with the full team since it's not clear to me if all functional requirements are understood.

I've made some edits to the task description in order to further clarify what needs to be implemented.

I assume the task description is clear and exhaustive enough for work on this ticket to begin. Although, if this proves not to be true, I figure the person working on this ticket will raise the uncertainty they encounter and from there, we can determine how best to resolve it.

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.