Page MenuHomePhabricator

Improve delivery of notifications for comments posted in close succession
Closed, ResolvedPublic

Description

This task involves the work with improving how notifications about new comments, posted in close succession, by the same person, are delivered.

Behavior

Case 1: new comments, posted in different sections, by the same person, in close succession
  1. Person A subscribes to Topic 1 and Topic 2
  2. Person B posts Comment 1 in Topic 1 and then quickly thereafter, posts Comment 2 in Topic 2

Current experienced

  1. Person A receives a new comment notification about Comment 1

Desired experience

  1. ✅ Person A receives a new comment notification about Comment 1
  2. ✅ Person A receives a new comment notification about Comment 2
Case 2: new comments, posted in the same section, by the same person, in close succession
  1. Person Z subscribes to Topic 3
  2. Person Y posts Comment 3 in Topic 3 and then quickly thereafter, posts Comment 4 in Topic 3

Current experienced

  1. Person A receives a new comment notification about Comment 3

Desired experience

  1. ✅ Person Z sees a new notification bundle for the two new comments that were posted in Topic 3
  2. ✅ Person Z clicks the notification bundle and sees discrete notifications for Comment 3 and Comment 4

Done

  • The Desired experiences for Cases 1 & 2 are implemented

Event Timeline

After thinking about this a bit more, I've realized that there are a few more interesting cases to consider. But I'm sure that we can still make improvements.

We should definitely add unit tests for all of the below.


Let's say we're starting in the following situation, where you just added the comment E:

== A ==
B. --[[User:X]]

== C ==
D. --[[User:Y]]
:E. --~~~~

(this is not real, correct talk page markup, but you know what I mean)

Your case 1 is:

== A ==
B. --[[User:X]]
:F. --~~~~

== C ==
D. --[[User:Y]]
:E. --~~~~

Your case 2 is:

== A ==
B. --[[User:X]]

== C ==
D. --[[User:Y]]
:E. --~~~~
:F. --~~~~

Alternative scenario inspired by case 1 (case 3) – the comment E is moved, instead of a new comment being added (perhaps you realized belatedly that you clicked [edit source] on the wrong section). We currently do not notify for moved comments, but in this case, we should probably notify users subscribed to section A?

== A ==
B. --[[User:X]]
:E. --~~~~

== C ==
D. --[[User:Y]]

Alternative scenario inspired by case 2 (case 4) – the comment is added to the existing comment E. We have no way to notify in this case, we can't distinguish this from a typo correction to comment E (of which we don't want to notify).

== A ==
B. --[[User:X]]

== C ==
D. --[[User:Y]]
:E. --~~~~ F. --~~~~

Alternative scenario inspired by case 2 (case 5) – comment F is added above the existing comment. We can't actually tell which comment is old and which is new; if this happens, we'll probably send a notification with a snippet of comment E again. This is probably not a big deal, since this isn't really done…?

== A ==
B. --[[User:X]]

== C ==
D. --[[User:Y]]
:F. --~~~~
:E. --~~~~

Now imagine the existing discussion had two more comments, and again you just added the comment E:

== A ==
B. --[[User:X]]

== C ==
D. --[[User:Y]]
:D1. --[[User:X]]
:D2. --[[User:Y]]
::E. --~~~~

Alternative scenario inspired by case 3 (case 6) – the comment E is moved, but we should not notify, because the comment is still in the same section, so everyone alreayd got notified.

== A ==
B. --[[User:X]]

== C ==
D. --[[User:Y]]
:D1. --[[User:X]]
::E. --~~~~
:D2. --[[User:Y]]

Alternative scenario inspired by case 5 (case 7) – comment F is added above the existing comment, but we can distinguish the new comment F from comment E because they have different parent comments:

== A ==
B. --[[User:X]]

== C ==
D. --[[User:Y]]
:D1. --[[User:X]]
::F. --~~~~
:D2. --[[User:Y]]
::E. --~~~~

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

[mediawiki/extensions/DiscussionTools@master] Test cases for comments posted in close succession

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

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

[mediawiki/extensions/DiscussionTools@master] Improve delivery of notifications for comments posted in close succession

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

Change 705414 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Test cases for comments posted in close succession

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

Change 705415 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Improve notifications for comments posted in close succession

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

matmarex added a project: Skipped QA.

The new functionality has automated integration tests, and I don't think it's a good use of time to be furiously clicking trying to leave multiple comments within a minute, so skipping QA.

The new functionality has automated integration tests, and I don't think it's a good use of time to be furiously clicking trying to leave multiple comments within a minute, so skipping QA.

Understood.

For posterity, noting down what @DLynch helped me to understand:

  1. We now have unit tests written for the cases Bartosz documented in T285528#7177220.
  2. And because we've now explicitly "written down" how we think said cases should behave, we will know when we make changes that break this behavior
  3. If and when "2." happens we can do a minimum of one of following two things: 1) Revise the tests to adapt to how we think the experience should be, 2) Fix the "bug" that is causing the test to fail