According to the design specs, we should only provide 1 link in each notification. In this case we can choose between the diff and the user. If we don't link to the diff, the recipient has no way to know which edit they are being thanked for. But if we don't link to the user, it's hard to respond to the thanks. Do you think this is a case where we should break the "1 link rule" and provide 2 links to the user?

Personal opinion:

When it comes to Thanks, it makes sense to know WHO is thanking you for WHAT. No matter what the generic design specs say.

• Bug 48943 has been marked as a duplicate of this bug. ***

This is fixed in the flyout and archive versions, but not in the email version yet.

Can we tag this as "easy"?

Quim: I don't think so.

This is already linked for me in HTML. However, those users who for some reason haven't changed from the default plain text will not get links like this... I wonder if Echo should send a plain text URL (which the client will hopefully link) for the agent.

Prioritizing this as Lowest, since this seems to be the actual priority for this request that, yes, affects only users willing to receive plain text Echo notifications.

Alex, you say that the fix is not easy. Where does the complexity come from? Is the implementation complex or is there something else?

Currently, in an email notification for changes on a non-Flow page, there will be a link, e.g.

To contact the editor, visit
http://en.wikipedia.beta.wmflabs.org/wiki/User:ET12

If changes(and/or Thanks) happened on Flow-enabled pages, the email notification will have a link to a user page:

<a href="http://en.wikipedia.beta.wmflabs.org/wiki/User:ET12" title="User:ET12" style="text-decoration:none;color:#3a68b0" target="_blank">ET12</a>

Does it sufficiently cover the issue of "Echo's "thanked you for your edit" should also link to thanker user page in email notification"?