Page MenuHomePhabricator

[Intervention] Automatic topic subscriptions
Open, Needs TriagePublic

Description

This task represents the work involved with introducing ways for people to become automatically subscribed to topics and by extension, being notified when new comments are posted in said "topics."

Note: the key difference between automatic and manual topic subscriptions is the actions people take to become subscribed to receive notifications about new comments in specific sections.

Objective and theory of change

Objective
This work is intended to increase the likelihood Junior and Senior Contributors know when someone is talking to them.

Theory of change
We think that:

  • If people can decide to automatically receive notifications when new comments are posted in topics they've participated in...
  • Then they will be able to more easily and quickly identify comments requiring a response
  • ...and be more likely to respond to those comments in a timely manner.

Background

We've run multiple usability tests with Junior Contributors throughout the design and development of different DiscussionTools features. As part of these tests, we've asked participants – when applicable – how they would expect to know when someone responds to something they have said on a talk page.

All of the participants who answered this question have stated that they expected to automatically receive some kind of notification. This work is a direct response to these findings. More details in T273908.

User stories

  • As a Junior or Senior Contributor who is starting a new discussion on a talk page that is not my own user talk page, I want to immediately be made aware when another person says something in said discussion, so that I can seize an opportunity to talk with another person who may have valuable information to share about a topic/question/idea/decision/etc. I have expressed an interest in.
  • As a Junior Contributor or Senior Contributor who commented in a discussion on a talk page that is not my own user talk page, I want to be made aware when another person says something in said discussion, so that I can know about new information people have to share about the topic/question/idea/etc. I have expressed an interest in.

Requirements

Meta

  • 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

Note: the functionality should be implemented in such a way that in a future iteration it will be easy for the software to offer people the ability to change what conversations they are and are not automatically subscribed to on a conversation-by-conversation basis.

Initiating a subscription

  • 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
    • 2) Starting a new discussion
  • After "1)", people should see the [ subscribe ] affordance on the page turn into [ unsubscribed ]

Being made aware of automatic subscription

  • 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

Notification delivery/receipt
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

Managing automatic subscription behavior

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

Open questions

  • 1. What happens in cases where someone responds to the authors of two separate comments [in the same section] without tagging either of them? See the example @Tacsipacsi described in T254263#6334962 .
  • 2. How do we ensure people are aware that automatic topic subscriptions exist and understand how they can enable/disable the feature?
    • This question is now represented as a requirement within the **Initiating a subscription** portion of the ===Requirements` section above and it will be "answered" through the user experience design which will fulfill this requirement.
  • 3. Where is the preference for automatically subscribing to topics surfaced? This will be answered in T281017.
  • 4. How – if at all – might the existing Watch this page setting within the two tools' Advanced shelves impact peoples' understandings of what notifications they will receive from conversations they've participated in and/or started?
    • This is a question we will not prioritize answering at this time. Instead, we will revisit it if/when people express confusion/uncertainty about how the Watch this page checkbox relates to topic subscriptions.
  • 5. Is there an override whereby you can opt-out of automatic subscriptions on a per-conversation basis? More in: T281017.
    • To start, there will not be. Instead, people will have two options for managing automatic topic subscriptions:
      • 1. They will be able to opt-out of being automatically subscribed to conversations entirely by adjusting a to-be created preference in Special:Preferences#mw-prefsection-editing
        • 2. They will be able to unsubscribe to conversations they have automatically been subscribed to by clicking the [ unsubscribe ] affordance that will accompany all talk page conversations
    • If the two options above prove to be insufficient, we will explore offering people more granular control over the conversations they are and are not automatically subscribed to (e.g. exposing a setting within the Reply and New Discussion Tools themselves).
  • 6. For people who have automatic topic subscriptions enabled, is it possible for the "state" of the [ subscribe ] affordance to change upon them publishing a comment to said section?
    • @Esanders confirmed this is possible. I've updated the **Initiating a subscription** portion of the ===Requirements above to reflect this.
  • 7. Is it possible for the "Automatic topic subscription" setting (exact name TBD) to be visible such that the two things below are true?
    • A) The "Automatic topic subscription" setting is only visible to people if the Enable topic subscription settings is enabled
      • The above is possible and straightforward to implement. More in T263819#7143367.
    • B) The "Automatic topic subscription" setting appears to people as if it is a "sub-setting" of the Enable topic subscription setting
      • The above is possible and not straightforward to implement/maintain. More in T263819#7143367.

Done

  • All Open questions are answered
  • All Requirements are implemented

Related Objects

Event Timeline

Good spot, @Tacsipacsi. I've added, what I think is, the question this example prompts to the "Open questions" section of T263819's description...can you please review to make sure it captures the case you are describing above? And if not, edit the question so it does?

Thanks, I think the description summarizes the issue as accurately as possible.

ppelberg renamed this task from Ensure people are aware when someone is talking to them to Use case 1: Ensure people are aware when someone is talking to them.Oct 2 2020, 7:25 PM
iamjessklein renamed this task from Use case 1: Ensure people are aware when someone is talking to them to [Experiment] Ensure people are aware when someone is talking to them.Feb 4 2021, 7:41 PM
ppelberg renamed this task from [Experiment] Ensure people are aware when someone is talking to them to [Intervention] Automatic topic updates.Feb 8 2021, 8:49 PM
ppelberg renamed this task from [Intervention] Automatic topic updates to [Intervention] Automatic comment notifications.Feb 8 2021, 8:59 PM
ppelberg updated the task description. (Show Details)
ppelberg added a subscriber: iamjessklein.

META
Adding the findings @iamjessklein compiled in T273908 to the task description's===Background` section.

META
Updated the task description with Requirements and Open questions.

ppelberg added a subscriber: Esanders.

META
Updated task description with link to T276990 per this morning's conversation with @Esanders.

We also discussed renaming this to "Automatic subscriptions" or similar

ppelberg renamed this task from [Intervention] Automatic comment notifications to [Intervention] Automatic topic subscriptions.Mar 12 2021, 11:16 PM
ppelberg updated the task description. (Show Details)

We also discussed renaming this to "Automatic subscriptions" or similar

Task name and description updated. Please edit either if you perceive them as unclear.

For "META" are we describing requirements here related to subscription management? If so, I would like to give contributors the ability to receive batch notifications rather than one offs. (not sure if @Esanders decided this was feasible or not, so please let me know your current thinking on the matter).

For "META" are we describing requirements here related to subscription management?

Not in this task, no.

If so, I would like to give contributors the ability to receive batch notifications rather than one offs. (not sure if @Esanders decided this was feasible or not, so please let me know your current thinking on the matter).

If by "batch" you mean group web notifications together, within Echo, if said notifications are from the same topic then this should be possible per @Esanders. [i]

If there is anything you'd like to clarify about how this bundling happens, please express as much in T273911 considering what we end up implementing in this task will be based off of what we implement in the former one (T273911).


i. https://wikimedia.slack.com/archives/GRR5LM0MS/p1615539437038600?thread_ts=1615489071.032100&cid=GRR5LM0MS

(Updated the task description's ===Open questions section with the questions that surfaced during the team's 12-May meeting; I also clarified the ===User stories section).

Task description update

  • ADDED ===Requirements
  • DOCUMENTED answers to the ===Open questions we discussed during the team's 12-May discussion about this ticket.
ppelberg updated the task description. (Show Details)
ppelberg updated the task description. (Show Details)

Task description update

  • ADDED answer to ===Open questions #6
  • ADDED question #7 to ===Open questions
  • 7. Is it possible for the "Automatic topic subscription" setting (exact name TBD) to be visible such that the two things below are true?
    • A) The "Automatic topic subscription" setting is only visible to people if the Enable topic subscription settings is enabled
    • B) The "Automatic topic subscription" setting appears to people as if it is a "sub-setting" of the Enable topic subscription setting

@matmarex: what – if anything – technically constrains our ability to implement what is being described in A) and B) above?

  • 7. Is it possible for the "Automatic topic subscription" setting (exact name TBD) to be visible such that the two things below are true?
    • A) The "Automatic topic subscription" setting is only visible to people if the Enable topic subscription settings is enabled
    • B) The "Automatic topic subscription" setting appears to people as if it is a "sub-setting" of the Enable topic subscription setting

@matmarex: what – if anything – technically constrains our ability to implement what is being described in A) and B) above?

We can easily do A), it's similar to what we've already done with the "Enable experimental tools…" preference (which is only visible if you enable "Enable quick replying" or "Enable quick topic adding").

We could do B), but it would be trickier, we'd have to implement a custom preference type and then make it look different (e.g. indented or something?). I would recommend against this, I think it will be clear enough without the style change, and doing it would increase complexity and maintenance (e.g. we'd have to think about how that would interact with the interface of GlobalPreferences).

  • 7. Is it possible for the "Automatic topic subscription" setting (exact name TBD) to be visible such that the two things below are true?
    • A) The "Automatic topic subscription" setting is only visible to people if the Enable topic subscription settings is enabled
    • B) The "Automatic topic subscription" setting appears to people as if it is a "sub-setting" of the Enable topic subscription setting

@matmarex: what – if anything – technically constrains our ability to implement what is being described in A) and B) above?

We can easily do A), it's similar to what we've already done with the "Enable experimental tools…" preference (which is only visible if you enable "Enable quick replying" or "Enable quick topic adding").

Noted.

We could do B), but it would be trickier, we'd have to implement a custom preference type and then make it look different (e.g. indented or something?). I would recommend against this, I think it will be clear enough without the style change, and doing it would increase complexity and maintenance (e.g. we'd have to think about how that would interact with the interface of GlobalPreferences).

Understood. Let's "let go" of the "sub-setting" treatment for now. If representing the two dependent settings (Topic subscriptions and automatically subscribe) in a flat list causes people to become confused about how the two settings relate, we can revisit this approach.

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