Page MenuHomePhabricator

RFC: Proposed "unthank" feature to roll back "thanks"
Open, Needs TriagePublic

Assigned To
Authored By
May 11 2021, 5:13 PM
Referenced Files
F34450586: image.png
May 11 2021, 5:13 PM
F34450589: image.png
May 11 2021, 5:13 PM
F34450581: image.png
May 11 2021, 5:13 PM
F34450583: image.png
May 11 2021, 5:13 PM
F34450597: image.png
May 11 2021, 5:13 PM
F34450579: image.png
May 11 2021, 5:13 PM



The Thanks extension provides something similar to a "like" button for revisions, called "thanks". Since the feature was first introduced, the lack of a corresponding "unthank" has caused concern, and eventually resulted in a two-click confirmation workflow to thank another user.

On revision page:

image.png (97×540 px, 16 KB)

In history view:
image.png (326×612 px, 96 KB)

Confirmation step:
image.png (32×333 px, 4 KB)

After thanking:
image.png (27×139 px, 2 KB)


image.png (488×439 px, 43 KB)

This issue was first discussed in 2013, on T49658: Thanks workflow needs further thought and on-wiki, where different implementations were considered including an "unthank" action. I'd like to re-open this question, hopefully with the advantage of hindsight.


The Thanks feature might be more widely used if the interaction were simplified to only require one click.



  • No confirmation step to thank.
  • Turn the gray "thanked" text into a link, which when clicked runs the existing confirmation workflow but in reverse. On desktop an inline question can be presented such as,
    image.png (29×343 px, 5 KB)


  • No configuration, this feature should be designed so that it's safe to enable everywhere.


  • Both thanking and revokation are logged permanently.

Grace interval

  • As with the thanking feature, we can give the user c. 2 seconds to change their mind.


  • Don't notify when revoking thanks. This is not actionable and can be easily misinterpreted.
  • Notify at most once per revision. If a user thanks, unthanks, and re-thanks on the same revision, don't send a second notification.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
mewoph added a subscriber: mewoph.

Hi @awight, thanks for filing this! I'm moving this task for our team to discuss.

This seems to me like a lot of work to take on based on a very ad-hoc hypothesis.

(Some apps, such as Gmail IIRC, provide an undo by faking the action on the client side but only actually performing it once the undo period has passed. But even that seems fairly complex to do.)

MMiller_WMF added a subscriber: MMiller_WMF.

@awight -- thank you for filing this. We talked about it on the team today, and we agreed that it is good practice to allow users to undo any sort of action. But we're not going to be able to prioritize this work on the Growth team, because of the other plans and priorities we have. I actually think this would be a good candidate for Community Wishlist, if you want to propose it the next time around.

Thanks for looking at it! To be clear, my personal motivation is to enable a 1-click "thank" workflow, on the hypothesis that it will increase interaction. "unthank" is not so interesting to me, merely a means to simplify the interface.

If you agree, I would like to add some metrics to the "thank" workflow to check whether users abandon before the second click. It's not perfect, but a drop-off there would demonstrate whether there's a problem.