Aggregate similar stories in Feed, Notifications and Timelines
Open, NormalPublic
Actions

Assigned To

None

Authored By

	epriestley
	Aug 16 2017, 6:55 PM

Description

In several cases, notifications, timelines and feed can end up with a series of similar stories which would be easier for humans to deal with if they were better aggregated.

One example is many different users making the same edit:

@alice subscribed to this task.
@betty subscribed to this task.
@claire subscribed to this task.

This is probably better as:

@alice, @betty, and @claire subscribed to this task.

Another example is a single user making the same kind of edit:

alice edited the description of this task.
alice edited the description of this task.
alice edited the description of this task.
alice edited the description of this task.

This is probably better as:

alice edited the description of this task several times.

Motivating example:

In PHI33, an install presented an example of a user making about 20 roughly-consecutive edits to a task description as they revised it over time.

Less compelling examples, but we get them mostly for free if we fix that:

In T10890, a user raised a concern about subscriptions stories, token stories, and mention stories. I suspect these cases are largely specific to open source installs, and this is roughly equivalent to "a bunch of people +1'ing something generates a lot of sound and fury and not much value", which everyone already knows but that doesn't stop anyone. I don't find this use case terribly compelling, but we can improve it if we're already doing the work.
In T5891, a user raised a concern about reviewing large volumes of notifications after returning from vacation. I think this is also a weaker use case, but we'll get some traction on it more or less for free by doing the work.
As a small quality improvement, we could likely aggregate the "committed rXyyy" and "closed Dxxx" stories (which tend to arise from committing a reviewed change) into a single story. No one has raised a concern about this that I can recall, but the stories are fairly redundant and collating them would be nice.
Similarly, subtask/supertask stories can fold together when we'd otherwise render both.

In all of timeline, feed, and notifications I expect aggregations to be special cases, not the default. We'll select types of stories we specifically want to group and implement grouping behavior for them. Stories won't group on their own -- they generally can't anyway, since a grouped story needs its own strings to be translatable into other languages.

I generally expect to implement these kinds of stories:

alice, betty and claire subscribed to X.
alice, betty and claire awarded tokens to X.
alice subscribed to X, Y and Z.
alice closed Dxxx by committing rXYZ.

I generally do not expect to implement these kinds of stories:

alice, betty, and claire subscribed to X, Y and Z.
- Aggregating across both users and objects produces a confusing mess of a story.
alice edited the title (from A to B) and projects (adding Q, R; removing S) of X.
- Although it's possible we'll pair some edits like this (for example, maybe "created and assigned" happens often enough to justify this and can be expressed in a reasonable way), I'd expect most types of edits to different fields to remain separate.
- Note that different edits to an object are already aggregated implicitly in feed, where we only show the "headline" story for each group of transactions.

Broadly, the idea here is that there are a few types of use cases that are a little unusual, but reasonable, and produce a large volume of edit events. We can aggregate these specific cases on a case-by-case basis to improve behavior. Most stories will likely remain unaffected.