Page MenuHomePhabricator

Improved bundling of SuggestedTags/CAT notifications.
Closed, ResolvedPublic

Description

User story: As a CAT user who does a lot of bulk uploads via UploadWizard, I want all me CAT notifications bundled into 1 message, so that I can see my other notifications more easily and not have CAT notifs crowd them out.

We have this:
After a 48 hour waiting period, newly uploaded files by a user who has opted in to the tool are run through the machine vision algorithm and a notification is sent to the user. Currently, the very first notification about files being ready for review in the SuggestedTags interface does bundle all the notifications into one. However, subsequent viewings of the notifications list shows notifications for every file individually.

Screenshot: although the initial notification comes in bundled, later views unbundle the notifications.

Screenshot: messages on the Special:Notifications inbox are not bundled at all

Additionally, on the Special:Notifications page, none of the messages are bundled.

We want this:
One notification from SuggestedTags, forever, on both the notifications dropdown list and the Special:Notifications page.

Acceptance Criteria:

  • When a new batch of files are ready for SuggestedTags, Special:Notifications only shows 1 notification
  • When a new batch of files are ready for SuggestedTags, clicking the little bell/notification icon only shows one notification from CAT, always.

During development, please test the following:

  • Test this feature on at least one mobile browser

COVID-19 Deployment Criteria

  • Can you roll back this change without lasting impact?
    1. A recovery plan is required as this will help identify our capacity for recovering from the failure
    2. THIS IS A KEY QUESTION, if you can’t answer it, you shouldn’t deploy
  • Is specialized knowledge required to support this change in production? If so, are there multiple people with this knowledge?
  • Is there a way to increase confidence about the correctness of this change?
    1. Reviews (Design, Code, etc)
    2. Testing coverage (unit tests, integration tests)
    3. Manual testing (e.g. Beta, vagrant, docker)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 23 2020, 3:53 PM
CBogen updated the task description. (Show Details)Mar 25 2020, 6:34 PM
Ramsey-WMF updated the task description. (Show Details)Mar 25 2020, 8:56 PM

It seems like the problem is that Echo doesn't really have a way to know that multiple events generated on the server at different times (as part of a job queue, for example) should be consolidated.

Our goal is simply to avoid spamming the user. We don't really need to convey much information here, just "You have new images ready to review". The place they go to review will always be Special:SuggestedTags, regardless of the nature or number of the images they have uploaded.

@Mholloway suggested two possible work-arounds here:

Hmm, I guess you could query the echo_notification table at that point to check for too-recent notifications, but that doesn't feel like a very elegant solution

If we only want users to receive one notification about this per N minutes, then maybe a better way to handle it is to run a periodic job every N minutes to send a single message to everyone with a newly labeled image in that window, rather than immediately notifying as soon as the labels come in for each individual image

I agree that the first approach feels a little more like a hack. I could probably muddle through the PHP code to figure it out though. The job-based approach might be better, but I don't know much about how to implement it; someone else should pick this up in that case. At the very least I'd need to be able to ask a lot of questions about how the job system works.

For the latter option, I was using the term "job" loosely, and probably shouldn't have — I meant "job" in the general sense of "task," rather than a thing to put on the MW Job Queue. I was thinking more along the lines of a maintenance script that could run periodically on a cron job.

Cparle claimed this task.Mar 30 2020, 4:50 PM
Cparle added a subscriber: Cparle.

Assigning to me so I can gather enough information for this to be ready for estimation

The current notification bundling is working exactly as intended: unread notifications are bundled; once read, they unbundle; Special:Notifications doesn't bundle.

So:

  1. we either change Echo's bundling rules (but there are good reasons for not rebundling read events, likely a lot of work)
  2. just leave things be - this is how it was designed to work. Only unread messages matter - no-one cares about unreads. And those that do can selectively turn off this notifications category.
  3. we send fewer notifications (which means a more vague description - it's no longer about specific files)

I have a patch ready for #3 (where users will not ever get another "Suggested tags are ready for review" notification until they've read the previous one), assuming we're not happy with #2 (do nothing, current situation is fine)
It's essentially similar to current situation (new notifications will end up bundled with existing, or will cause a new bundle when none were unread), except that there'll be far less 'unbundled after read' noise.

Change 586359 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/extensions/MachineVision@master] Self-bundle notifications

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

Thanks! #3 does seem like what we have to go with. The logic of the patch seems reasonable to me. I'm looking forward to the code review 😺

The current notification bundling is working exactly as intended: unread notifications are bundled; once read, they unbundle; Special:Notifications doesn't bundle.

So:

  1. we either change Echo's bundling rules (but there are good reasons for not rebundling read events, likely a lot of work)
  2. just leave things be - this is how it was designed to work. Only unread messages matter - no-one cares about unreads. And those that do can selectively turn off this notifications category.
  3. we send fewer notifications (which means a more vague description - it's no longer about specific files)

I have a patch ready for #3 (where users will not ever get another "Suggested tags are ready for review" notification until they've read the previous one), assuming we're not happy with #2 (do nothing, current situation is fine)
It's essentially similar to current situation (new notifications will end up bundled with existing, or will cause a new bundle when none were unread), except that there'll be far less 'unbundled after read' noise.

Tested this out locally, everything seems to work as expected. I didn't know about the EchoNotificationMapper class that lets you determine a user's unread notification count pretty easily. Merging this now.

I'd recommend some serious QA-ing on Beta once this is up there to ensure the behavior is falling more line with what people want now. Single uploads, batch uploads with UW, etc.

Change 586359 merged by jenkins-bot:
[mediawiki/extensions/MachineVision@master] Self-bundle notifications

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

Ramsey-WMF closed this task as Resolved.May 22 2020, 8:16 PM

After testing this a few times, going to call it closed and working on production.