The comment should probably be stored in echo_event.event_extra and in logging.log_comment. The dialog that I would want to change is implemented in extensions/Thanks/modules/ext.thanks.thank.js, in var confirmThanks. Currently, it just has the thanks-confirmation message and the ok and cancel buttons. I want to add a single-line text box for the comment.

You'd need to change some other things too, including the echo formatter and all the various messages, plus some back-compat code for existing thanks that don't have a comment.

I'm not sure this is a bug... this was likely an intentional design decision in the extension. If you have more to say than "thanks", you can leave a comment on the talk page. I'm not sure I see a need to attach a logged comment to thanks.

It can be a config setting, which WMF can leave disabled on its wikis if it wishes.

Why do we need a thanks log at all, when it comes right down to it? Its creation was probably motivated by the wiki-philosophy that (almost) everything should be transparent and that it's better to make (almost) as much information as possible publicly available. If we're going to do that much, we may as well take it to its logical conclusion.

I would favor making it possible for users to comment when performing any logged action (including marking pages patrolled) so that others don't need to ask, "Why did you do that?" to know the rationale. It's helpful to have the relevant info displayed right there in Special:Log rather than scattered across various user talk pages, etc. Users who don't want to include a comment don't need to, unless there's a norm requiring it. This can vary from wiki to wiki.

The downside might be that users might put Thank comments such as, "Thank you very much for this edit; I like your thinking here. I do have one minor quibble, which in some respects is connected to my larger theory concerning the implications of ..." Then it would be better to just add a talk page message, because that's likely the beginning of a back-and-forth dialog that will end up taking place on a talk page anyway. Readers will want to know what the first message in that exchange was. It could be copied and pasted into the talk page, though, in such cases. It might be useful to have an option, in viewing one's incoming "Thanks" notification, to get a permalink to the publicly viewable log entry. (I guess there's no logging.log_id parameter to Special:Log? https://www.mediawiki.org/wiki/Manual:Parameters_to_Special:Log)

These same arguments could be raised with reference to other log actions, e.g. what if someone blocks a user and puts a log comment such as "Repeated personal attacks at [[Talk:Foo]] and [[Talk:Bar]]"; this too could lead to a dialog taking place on a talk page in which it will not be possible for readers to know the original log comment that led to the conversation without viewing Special:Log. There are some wikis, e.g. RationalWiki, in which a lot of back-and-forth dialog takes place by means of block log comments that people view in RecentChanges. rationalwiki.org/w/index.php?title=Special%3ALog&type=block

I could probably do the backend stuff (database queries, etc.) needed to implement this option, but regrettably, my javascript-fu isn't all that great. I tried grepping around for some dialog code in other extensions I could adapt to implement the desired UI change but didn't see anything right off the bat. I'll continue looking, and maybe take the W3Schools JS tutorial or something.

I don't see this as the type of situation in which the status should be changed to UNCONFIRMED, since it's confirmed that Thanks currently lacks the feature. It doesn't seem appropriate to WONTFIX either, since it's an extension feature request that can be switched on or off by means of a config setting. Even if it's deemed unsuitable for putting in the Thanks extension, it can be implemented by forking the code to create a new extension.

Given the 255-character limit, people probably won't initiate very complicated conversations by Thanking; it would probably be more like "I found this very helpful for x" or the like.

(In reply to comment #4)

Why do we need a thanks log at all, when it comes right down to it? Its
creation was probably motivated by the wiki-philosophy that (almost)
everything
should be transparent and that it's better to make (almost) as much
information
as possible publicly available. If we're going to do that much, we may as
well
take it to its logical conclusion.

Alternatively, there is bug 55428 :Remove all logging for the Thanks extension

The downside might be that users might put Thank comments such as, "Thank you
very much for this edit; I like your thinking here. I do have one minor
quibble, which in some respects is connected to my larger theory concerning
the
implications of ..." Then it would be better to just add a talk page message,
because that's likely the beginning of a back-and-forth dialog that will end
up
taking place on a talk page anyway.

Exactly that. Especially in various cultures, or amongst certain personality types, where it might be considered rude not to acknowledge a personally-written-note.

(Yes, there has already been a feature request for a "Thanks for that thanks!" button :)

Also, some people feel obliged to fill in "context boxes", so might use "Thanks" less if that appeared.

"Thanks" isn't perfect for everyone, but the more we mold it further in any particular direction, the less of a "simple friendly thanks" it becomes. I personally like it kept simple.

(In reply to comment #6)

Exactly that. Especially in various cultures, or amongst certain personality
types, where it might be considered rude not to acknowledge a
personally-written-note.

So when people get a thank-you card in those cultures, they feel the need to reply? That must have really swelled the postal services' and phone companies' coffers before email came along. :)

(Yes, there has already been a feature request for a "Thanks for that
thanks!"
button :)

It's already customary in a lot of cultures to say "you're welcome", "my pleasure", "no problem", etc., so that button theoretically might not be such a bad idea. On the other hand, then one is burdening the recipient of the thanks with the job of hitting that button, which might deter some people from thanking. But, if someone were to want to implement it as an optional functionality that could be left disabled by those who don't want it, why not.

"Thanks" isn't perfect for everyone, but the more we mold it further in any
particular direction, the less of a "simple friendly thanks" it becomes. I
personally like it kept simple.

That's why commenting should probably be enabled or disabled by a config setting. I would like to test it out on my wikis and see what effect it has, but others can leave it disabled.

(In reply to comment #7)

(In reply to comment #6)

(Yes, there has already been a feature request for a "Thanks for that
thanks!"
button :)

It's already customary in a lot of cultures to say "you're welcome", "my
pleasure", "no problem", etc., so that button theoretically might not be
such a
bad idea. On the other hand, then one is burdening the recipient of the
thanks
with the job of hitting that button, which might deter some people from
thanking. But, if someone were to want to implement it as an optional
functionality that could be left disabled by those who don't want it, why
not.

Exactly. It is again creating something that some people will feel obligated to use.

Also, it would lead to hurt feelings, or thoughts of "did they even see my thanks?", if the recipient /doesn't/ then utilize the "thanks for the thanks" button.

(I do grok the good potential of the idea; but I can also clearly see the downsides. I'm just noting them, in case you or anyone else hadn't. :)

Another reason for allowing a short comment when thanking is that a user might be making, say, 1,000 wikignoming revisions to different articles, and you want to thank them for all of them, "e.g. thanks for fixing all those categories".

I like the way Thanks currently works. Leaving a talk page comment is pretty simple, so if one wants to attach a message, they should probably just do that instead regardless of the length.