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.