Change Details

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. --- See also: T5891, T10890, PHI33. The anchor issue described in T7643#175911 is somewhat related here, but does not affect the design or behavior very much. --- Technical notes: - This is probably a good time to get `willRenderTimeline()` out of `PhabricatorApplicationTransactionInterface`, and either get rid of it completely or move it to a separate `Codex`-style interface. (It can probably be moved to the Editor safely?) - T12746 may be adjacent enough to keep in mind. - The "Show Details" for description edits needs to be some big mess which shows the overall diff and also the individual diffs, so we don't lose information as a consequence of this aggregation. - T11881 may be adjacent to changing how the "Show Details" workflow behaves.

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. --- See also: T5891, T10890, PHI33. The anchor issue described in T7643#175911 is somewhat related here, but does not affect the design or behavior very much. --- Technical notes: - This is probably a good time to get `willRenderTimeline()` out of `PhabricatorApplicationTransactionInterface`, and either get rid of it completely or move it to a separate `Codex`-style interface. (It can probably be moved to the Editor safely?) - T12746 may be adjacent enough to keep in mind. - The "Show Details" for description edits needs to be some big mess which shows the overall diff and also the individual diffs, so we don't lose information as a consequence of this aggregation. - T11881 may be adjacent to changing how the "Show Details" workflow behaves. - T9233 is a minor adjacent behavior.

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. --- See also: T5891, T10890, PHI33. The anchor issue described in T7643#175911 is somewhat related here, but does not affect the design or behavior very much. --- Technical notes: - This is probably a good time to get `willRenderTimeline()` out of `PhabricatorApplicationTransactionInterface`, and either get rid of it completely or move it to a separate `Codex`-style interface. (It can probably be moved to the Editor safely?) - T12746 may be adjacent enough to keep in mind. - The "Show Details" for description edits needs to be some big mess which shows the overall diff and also the individual diffs, so we don't lose information as a consequence of this aggregation. - T11881 may be adjacent to changing how the "Show Details" workflow behaves. - T9233 is a minor adjacent behavior.