Change 311198 had a related patch set uploaded (by Mooeypoo):
Remove primary link from the bundle of page linked notification

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

@Mooeypoo Can you describe the product decision that needs to be made (that you -2ed the patch for) and ping jmatazzoni in your response?

@Catrope yes, the original task said to get rid of the primary link for bundled page-link notification, and while that seemed to be the general consensus, questions were raised as to whether that should be the action we do.
Other options were also raised, for example changing the primary link of the bundle item to be the linked page itself, or the latest link that was done. And the spec itself dictates what the action currently does (linking to the latest link) though that, too, seemed to be wrong.

I wasn't completely sure whether we should change this at all and to what.

@jmatazzoni - can you confirm the solution here? Was the consensus about this that the bundle itself should not link to anything (but rather expand-on-click) ? If not, what is the consensus?

The patch is ready to do that (remove link, expand on click) unless we need to change it. If you confirm, I'll remove the -2 holding back the merge.

Talking to @jmatazzoni and team - the consensus is to cancel the primary link (make the bundle just open on click)

Removing the -2 on the gerrit patch.

Change 311198 merged by jenkins-bot:
Remove primary link from the bundle of page linked notification

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

Was the problem with page-linked specifically or do we want all local bundles to have expand as their primary action? If it's the later, we can enforce it in the UI and push the original primary link, if any, to the dotdotdot menu.

Other local bundles with primary link include: thanks, flow-thanks, flow-new-topic, flow-post-reply, and maybe mention failure but I'm not sure what state it's in.

( CC @Pginer-WMF )

I think there are two separate issues here:

Expand or provide a main action for bundles (of all kinds)

Notification bundles existed before it was possible to expand them.
At that time, users clicking on them were directed to the element affected by the bundled changes.

When we introduced the possibility to expand bundles, we kept the quick access to the content in the same way as before. There are advantages and disadvantages with that decision:

• Advantages:
  • No extra barriers if you just want to get to the information. In addition to the extra steps, sometimes forcing the users to select one individual does not make much sense (e.g., if you got 100 thanks for an article, and you want to check how the article has evolved, expanding the bundle and pick one of the individual bundled thanks s not a very meaningful decision).
  • Backwards compatibility. This is how bundles worked before they were expandable. To my understanding, the main issue was the impossibility of exploring individual items, not their main action to cause issues.
• Disadvantages:
  • Mistakes cannot be easily undone. Accessing the information element when trying to expand causes the bundle to disappear, causing you to lose track of the individual items that were unread.

We can reconsider the default behaviour for bundles, but we may want to check that (a) expanding is the default expectation for our users, and (b) we are not adding unnecessary friction to common actions for all bundles.

Picking relevant actions for bundles
A bundle represents the aggregation of their members. Thus, their main action (being it the default or not) should make sense for the whole group. In the case of page linking, it seems to just represent one of the bundled items. In this case we can link to the "what links here" page for the target page which is the common element of the bundled items.