If the same person makes many label changes to an MR within a short space of time, each label change is listed individually in the activity. In extreme instances there can be so many changes that the label changes visually clutter the history, obscuring more important details.
Example:
Suggested solution
Collapse label changes in the MR activity log so that there is just one entry for all label changes made by the same person within a short period of time, perhaps 1 minute.
This same behavior is present on Issues and I assume Epics as well, ideally the solution hits all places where labels appear in system notes. The proposed behavior here makes sense to me.
@rdickenson Thanks for opening this. I fully agree with you, AND I think there is one other aspects, just not sure whether we want to handle them together in this issue, or in separate issues:
We should do the same for combining labels and scoped labels. Even when I add e.g. UX and devopscreate at the same time, this will create two separate system notes. I can't think of a reason why the user would consider this an important difference.
Side-note: We already combine system notes if someone consecutively updates descriptions. The same could be done here. Maybe even just in the "frontend" (combining events of the same type).
@rdickenson Thanks for opening this! I love any proposal to de-clutter the UI
It seems we have two proposals here:
Combine label changes from a single user made in the same time span (10 minutes maybe?)
Combine all label changes made in a single time span, regardless of user (and potentially add an expansion feature to see the granular details of who added what
I'm leaning towards option 1 because it's a simpler solution and I'm guessing this is once again, more of a GitLab organization problem than a product one. We use a billion labels but that's probably not super common for our users.
We should do the same for combining labels and scoped labels.
@mvanremmerden When we introduced scoped labels we were unsure if users would understand the automatic nature of adding/removing. We opted for a system note that would make this explicit (ie user added scoped::label2, automatically removing scoped::label1). I agree, it probably doesn't serve much purpose anymore and we should see if we can combine them.
@annabeldunstone - Like you, I believe that while we use many labels, our customers likely don't use nearly as many. For that reason, I also suggest we pursue option 1 first. If we find that labels significantly contribute to UI clutter, then we could pursue option 2.
I think label additions are split by scoped and unscoped. So if I add devopscreate and UI polish at the same time (like, in a quick action) it will be two separate system notes.
@leipert - Apologies for the delay in responding to your comment. I somehow overlooked it when last reviewing this issue. In looking at the example you provided, I agree that combining label changes with a small period of time, by different users, is still effective in communicating the essential information: which labels were added/removed.
In an earlier comment, I suggested we pursue option 1: combining label actions taken by a single user. I suggested that only because I thought that might be easier programmatically that label actions taken by multiple people. If it makes no difference in implementation, I suggest we pursue option 2.
All SUS-impacting issues need to have a proper severity label set.
Please add a severity label, remove the automation:ux-missing-labels label, and then reply to this comment briefly explaining your reasoning for providing this severity.
If you are not the DRI for this area and would like help determining the best severity, please @ the appropriate person for assistance.