If you want to go with something in the vein of "just one icon", we do have a well-defined way to select the "most important" transaction and could move it first and use its icon (i.e., the mechanism used by Feed). That would satisfy my concern about a less-important icon showing up first and drowning out a more important icon (e.g., "subscribe" vs "request changes").

I thought I designed something for this already, but perhaps not. I'll dig around my photoshop folders. It might be "icon: lots of things" then the list of things, that way there is no "importance"?

Also, we could probably drop all the timestamps and sources from the 2..Nth transactions to clean that up a little bit, and just not group transactions from different sources (we already don't group transactions which happened several minutes apart). We'd need to make sure, e.g., "Edit" links for comments were preserved, but that might help clean things up.

If at all possible I want to make sure a group containing an important transaction (like a "Request Changes" in Differential, which is normally red with a distinctive icon, in a future-world where we actually use this UI element in Differential) is rendered with "request changes" icon (and maybe other icons, etc.), so it's easier to pick out important transactions when scrolling through a log. I think we're sacrificing functionality if we sometimes render a transaction group including an important transaction with an uninteresting icon ("several changes", "added CCs", etc.)

Particularly, most interesting actions will group with a comment, so if we have a "lots of stuff" icon I think we'll rarely see the icons like "Close task" or "request changes".

I'll add that 'importance' in some cases can be somewhat context dependent; having a single "most important" change in each transaction identify the icon for that transaction deprives me of important visual cues for when I'm quickly scrolling through a task looking for certain kinds of changes: instead of looking for instances of a particular icon, I've now got to parse text, which is a lot of mental overhead.

Ordering events within a single transaction by importance might be a decent compromise, with the comment always being the "least" important.

Hmm, I wonder if we should simplify it then instead of getting granular on all the different transaction types. A simple "groupable" flag on low importance things?

It might be useful to create a taxonomy of things that can logically be part of a single transaction, and start the discussion from there.

Actually, let me elucidate my sorting suggestion based on the quick taxonomy I did in my head: I'd actually wager we've got two different situations:

1. Upon creation of a task/revision/whatever, we've got a bunch of relatively high importance things that can happen, e.g.: assigning priority, owner, projects, whatever (for tasks)
2. Upon an individual update (e.g., marking a task as a duplicate). In that case, you'd be doing some low importance things like adding CCs, but fundamentally only a single "important change" per transaction.
3. I lied, there's actually a third edge case, for example when I click "edit task". I consider that really a special case of 1. (Incendentally, it might be nice to be able to leave an optional comment when I use "edit task" - or similar for Differential. I might be making some big changes there and need to explain myself).

In 1 (and, well 3), I'm making a bunch of changes that are part of a single transaction, so I'd like to have them grouped (as an indicator that they were done together) but not lose the icon for the "important changes". In 2, I've only got one important change anyway.

I'd propose the following: "unimportant changes" don't get an icon at all, and ALWAYS get sorted to the bottom of the group. "Important changes" are always sorted to the top of the group based on their relative importance. Comments only ever get the "comment icon" if they are a standalone comment: transactions always have the possibility to have some text (the comment) attached to them; you only attach the comment icon if the whole of the transaction is a comment.

Important changes are called out not only because there is an icon associated with them, but because their text is aligned a little to the right. It's similarly clear which changes are unimportant by virtue of the fact that they lack an icon and are aligned a little to the left. Moreover, you don't have the ugliness apparent in the UI example of alignments jumping back and forth because the items in a group are always sorted according to their importance.

Of course, as a counterexample to my previous comment, when you are editing/creating a task/revision/whatever, it might be nice to be able to associate which "unimportant changes" happen as a result of each "important change", in which case @chad has a pretty good point.

Before, we had grouping rules which were roughly "transactions within a couple of minutes of one another by the same author with no intervening transactions, of which not more than one are a comment, group together". I think this produced very good results, and correctly reflected intent in cases where several edits happened in succession (not necessarily part of a single submit). I'd like to return to these rules, since I recall them consistently reflecting intent, compacting tightly, and never producing weird/awkward results.

A particular example is closing a task with a comment (like "This was completed by <such and such>.") This is reasonably common, and we previously grouped the operations, which I think was desirable and effective. I think we dropped the "added a comment" text in the case where the comment transaction grouped, even, so you got a very clean close + comment in a compact package.

If we don't group high-importance events, "close + comment" won't group together. I think this is undesirable: they grouped before, and it seemed good.

D7842 seems to be an entirely reasonable first step.

These should all group together once T3904 is fixed: