Thank you to @Samat for inspiring this ticket: https://www.mediawiki.org/w/index.php?title=Topic:Vjxycppfwer4qmrm&topic_showPostId=vk55wmcmxz97fnck#flow-post-vk55wmcmxz97fnck

Related talk page: https://www.mediawiki.org/wiki/Topic:Vzs4ur30kpi1ef5t

Many replies consist of simple "Thank you" messages. These messages clutter talk pages and increase the nesting depth of discussions unnecessarily. Adding a Thanks button would help to reduce this. I just updated the task description with these reasons.

As an implementation note: the relevant edit to thank can surely be deduced out of the timestamp.

Also see https://www.mediawiki.org/w/index.php?title=Topic:W5wqmnpooz2meqe1&topic_showPostId=w60rj2bs5w7l6nkb#flow-post-w60rj2bs5w7l6nkb.

In T249893#6700257, @Sophivorus wrote:

As an implementation note: the relevant edit to thank can surely be deduced out of the timestamp.

What uniquely identifies an edit is the revision id, not timestamp. Signatures don't include real timestamps, they miss seconds. There may be multiple revisions in the same minute (and even second), on the same page and by the same user. And the revision id cannot be easily saved with the signature, because it's only known after the edit was saved.

Convenient Discussions has implemented this by guessing the revision from the username and timestamp:

https://github.com/jwbth/convenient-discussions/blob/20a7e7410b8331f1678c66851abbd5eeb4c4e51f/src/js/Comment.js#L2290

• It searches for edits that match the username in the sig, and are within a specific time window as described below (-10 minutes, to 3 minutes):
  • Search for the edit in the range of 10 minutes before (in case the comment was edited with timestamp replaced) to 3 minutes later (rare occasion where the diff timestamp is newer than the comment timestamp).
• It then iterates over all these edits looking for the one which contains the most words in common with the comment (using https://github.com/jwbth/convenient-discussions/blob/20a7e7410b8331f1678c66851abbd5eeb4c4e51f/src/js/util.js#L903)
  • There is a secondary comparison of how close the edit timestamp is the comment's, but I suspect that rarely gets used.
• A confirm dialog is then shown with the diff, so the user can check the correct diff was "guessed". Example:
  • 

I think a better approach for us would be to define a new type of "thank" notification, similar to what was down with Flow, so that we can link thanks to comment IDs directly.

Change 752325 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/DiscussionTools@master] WIP Comment thanking

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

Some more open questions:

• Should the feature be disableable?
  • Could depend on the prominence of the "thank" link
  • You can't disable "thank" links in edit history or on Flow boards
  • Config bloat: More things to test and maintain
  • Could be hidden with user CSS even without a config option
• Should we ask for confirmation before sending?
  • In edit history we do, and there is even a config for it in software
  • Warns users that "thanks" are technically public (although you have to rummage through Special:Logs to find them)
  • This config is ignored on Flow boards and thanks are always sent instantly
  • A confirmation is probably a bit heavy for such a light interaction - comparable features on social networks don't have confirmation
  • "Thanks" can't be undone/unsent

Regarding the second question whether to ask for confirmation or not, I
would normally vote no, but given that we're already going to show the
diff, then it might aswell contain a text like: Do you want to send public
thanks to User for the following edit/comment?

Test wiki created on Patch demo by Patrik L. using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/1690861505/w/

Test wiki on Patch demo by Patrik L. using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/1690861505/w/

but given that we're already going to show the diff

That's how Convenient Discussions works. Any implementation we make would probably attach the "thanks" to the comment ID directly, rather than attaching to a specific diff.

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/a14f473a0d/w/

In T249893#7607437, @Esanders wrote:

• Should we ask for confirmation before sending?

I’d say definitely yes, especially because

• "Thanks" can't be undone/unsent

If you accidentally click the link, there’s no way back (this annoys me on Flow boards as well). The social media sites I use (Facebook, YouTube, Microsoft Teams) all allow undoing the like/reaction. I think it’s okay not to have a revoke possibility, but then at least prevent the user from accidentally sending it.

This issue was mentioned in connection with the new reply tool.

This work fits nicely with the Growth team's Positive Reinforcement efforts, so please let us know if there is anything we can do to help move this along.

Perhaps we could help with the Thanks confirmation step, which we hope to improve soon?

Anecdotally, as a newer editor myself, I really appreciate the ease of Thanking people for their comments in Flow (on Mediawiki) and wish it was as simple on other wikis.

For implementation, I suggest re-working the attached patch to use the hook introduced in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/ /961809.

In T249893#9223714, @kostajh wrote:

For implementation, I suggest re-working the attached patch to use the hook introduced in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/ /961809.

Yeah, thanks for your work on that, I was just thinking about this.

Test wiki on Patch demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/a14f473a0d/w/

In T338534#9213065, @Tacsipacsi wrote:

In topic-level v2, I see “Thanks” buttons. I don’t think they should be there – one can thank an edit, and the (mostly) 1:1 correspondence is between an edit and a comment, not an edit and a topic. If one wants to send thanks for starting the topic, they should thank the comment starting the topic, not the topic itself. It may be a bit less discoverable, but way less confusing in terms who receives the thanks. (The person starting the topic? Everyone who has commented in the topic?)

In T338534#9223548, @Sdkb wrote:

This looks good overall! I was about to make a similar comment to @Tacsipacsi's, though, about "thanks" being a weird option in the topic-level menu. If it is retained there, changing the text to something like "thank topic creator" might clarify a bit.

In T338534#9227853, @Tacsipacsi wrote:

In T338534#9223682, @Esanders wrote:

You can actually thank anything you can generate an ID for.

For a thank to be delivered, you need a recipient as well. I didn’t think it’s technically possible to thank something that’s neither an edit nor a log event; but thanking something that has no single author is conceptually impossible without spamming users.

I agree it might not make sense to thank topics, although this will be an implementation detail for T249893.

I don’t agree. What users can and cannot thank should be a product/design decision informed by technical possibilities, not a purely technical decision.

In T338534#9227853, @Tacsipacsi wrote:

I don’t agree. What users can and cannot thank should be a product/design decision informed by technical possibilities, not a purely technical decision.

I meant it was a detail for this task, not necessarily a technical decision.

For a thank to be delivered, you need a recipient as well.

Yes, in this case the recipient would be the author of the topic title (i.e. the first poster), but it may not make sense to have two ways to thank the first comment.

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/32d0720836/wiki/Talk:DiscussionTools

In T249893#9525981, @PatchDemoBot wrote:

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/32d0720836/wiki/Talk:DiscussionTools

Happy to see some life here!
How can we test it?

Looks nice, and the per-comment hamburger menu is probably a good long-term UX investment - I imagine we'll need it eventually for flagging abusive comments.

The reply button is visible immediately but the menu button shows up with a split second delay, I wonder if they could be rendered via the same mechanism.

In T249893#9528904, @Trizek-WMF wrote:

How can we test it?

Just click on the link and log in.

Thanks @Esanders, the patch looks great!
(@Trizek-WMF I logged-in on patchdemo to try it)

Quick thought: speaking with the Growth team, it seems like they've implemented "thanks" on their dashboard using the userTalk icon.
Instead of the heart as mocked up, could we switch to the other icon for consistency?

I must be dumb on this, but aren't we supposed to have a test account given for each patchdemo?

In T249893#9530871, @nayoub wrote:

Quick thought: speaking with the Growth team, it seems like they've implemented "thanks" on their dashboard using the userTalk icon.
Instead of the heart as mocked up, could we switch to the other icon for consistency?

The smiling-talk-page-icon is the one used on Echo, as the notification you receive. Using the same icon everywhere is a good idea.

In T249893#9533823, @Trizek-WMF wrote:

I must be dumb on this, but aren't we supposed to have a test account given for each patchdemo?

You can log in to any Patch Demo wiki as user "Patch Demo" with password "patchdemo1" (unless someone else logs in and changes the password). Or you can just create a new account for yourself (please don't use a password that you use anywhere else, as they can easily leak).

Thank you @matmarex.

I'm getting a "No valid recipient found" message, but I assume this is due to the test environment. Otherwise, it looks nice!

Thank/Thanked
One thing that our users could request is a different state (Thank/Thanked) for the button when you already thanked a given comment. At the moment, you can thank a given comment again and again.
Suggestion:

Edited comments
In short, what if a comment is edited? The thank is lost?
Should the user who thanked the comment be informed of this change? One would say "Let's define a number of characters where the change is kept", but I would not follow this idea, as a letter changed in a word can sometimes change an entire sentence, in a bad way.

From communities' background discussions:

• Shall we take the opportunity of this change to work on T229168: Add a help link to Thanks confirmation & remove the confusing word "publicly"?
• We will also have the very ancient T71636: Thanks: Implement an undo feature to come back, in particular now that the thank button will be super visible.

Some less direct suggestions:

• This suggestion made for Flow could be interesting to consider: T181753: Display whether Thanks (and how many) has been given to a reply on Structured discussions. The idea is to show publicly when a user acknowledged an answer.
• We also have the question of what Thanks are. As this change will make them more discoverable, we should consider an onboarding step for newcomers, which is covered by: T333027: Growth design: finalize designs for thanks confirmation UX

In T249893#9538012, @Trizek-WMF wrote:

I'm getting a "No valid recipient found" message, but I assume this is due to the test environment. Otherwise, it looks nice!

Indeed, it’s because you tried to thank a user that doesn’t exist locally. Try to thank the comment in https://patchdemo.wmflabs.org/wikis/32d0720836/wiki/Talk:DiscussionTools#Test. (BTW Alice also has the password patchdemo1, and so does Bob. These three accounts always exist on Patch Demo wikis.)

Thank/Thanked
One thing that our users could request is a different state (Thank/Thanked) for the button when you already thanked a given comment. At the moment, you can thank a given comment again and again.
Suggestion:

Maybe using a different icon for the thanked state?

If the thank was successful, the state does change: the text is “Thanked” and it’s greyed out.

I think a completely different icon isn’t necessary, graying out and making it non-interactive should be enough. Non-interactivity also means that you can thank a given comment again and again only until you succeed. (I don’t know if the backend also prevents duplicate thanks, but the frontend certainly does.)

Thank you for the precisions, Tacsipacsi. I think all my tests with this demo are just perfect failures! 😓

In T249893#9530691, @Tgr wrote:

The reply button is visible immediately but the menu button shows up with a split second delay, I wonder if they could be rendered via the same mechanism.

Yes - we just weren't loading the ellipsis icon unconditionally on desktop, but after this patch we should as most pages will show it.

Change #752325 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Comment thanking

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