Feature summary (what you would like to be able to do and where): Remove the 'confirmation' step in the thanks feature. Currently sending a thanks is a two-step process, with jumping buttons. This is especially tricky because the 'thank' button is fairly short and the confirmation message is much longer, often pushing the confirmation button over a line break (see video).

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): The user goes to a history page, and sees a recent non-bot edit that they want to thank the user for. They click 'thank'. Rather than immediately submitting a thankyou, it first asks if they are sure. This is a bothersome step that both costs time of the people that are kind enough to thank others, and casting doubt if this is the right thing to do. Apparently the software suggests it's a bigger deal!

Benefits (why should this be implemented?): The thanks feature has been previously shown to have positive short term effects on editing frequency as well as on retention and thanks-sending frequency. This is a simple intervention that seems to have positive effects. We should make it easier to use the thanks button.

Details I can imagine that details matter here. I would propose to remove the confirmation step on two conditions: 1. the thanking user is autoconfirmed, 2. the thanking user has already sent 10 thanks in the past (and therefore knows what to expect). Further confirmations are repetitive. Ideally, the user would be able to opt-in to the confirmation step again, via their preferences (in case they often misclick).

Data checks To verify whether this is a desirable change, it would be possible to do a few sanity checks:

• If both the initial 'thank' request and the confirmation are being logged, you could check how many people don't follow through with the confirmation step. You could also take a random sample from both the confirmed and the not-confirmed thanks-edits and see if they are meaningfully different in nature. If the percentage of non-confirmed thanks messages is high, and their nature is different, that would be an indication that this feature request should not be implemented. On the other hand, if the percentage is very low, or if the nature is very similar, those would be indications that the request might be beneficial.