Yes, bugs go through a different code path because it was too heroic a job to convert them, but everything else goes through the same path for rationale construction.
We talked about this a bit on #launchpad-dev today. The problem with changing the existing rationales is that people may well have filters that direct anything without @ (i.e. notifications directed specifically at them) to their inbox and anything with @ to a "team junk I don't care about" mailbox, so adding @ would potentially cause people to not see notifications and not notice for some time.
How about sidestepping the issue and introducing a new header? X-Launchpad-Message-Subscriber or some such, that always identifies the person-or-team that the notification is being sent to. We could leave @ in X-Launchpad-Message-Rationale intact for compatibility, but the new preferred approach would be to filter on this new header.
Yes, bugs go through a different code path because it was too heroic a job to convert them, but everything else goes through the same path for rationale construction.
We talked about this a bit on #launchpad-dev today. The problem with changing the existing rationales is that people may well have filters that direct anything without @ (i.e. notifications directed specifically at them) to their inbox and anything with @ to a "team junk I don't care about" mailbox, so adding @ would potentially cause people to not see notifications and not notice for some time.
How about sidestepping the issue and introducing a new header? X-Launchpad- Message- Subscriber or some such, that always identifies the person-or-team that the notification is being sent to. We could leave @ in X-Launchpad- Message- Rationale intact for compatibility, but the new preferred approach would be to filter on this new header.