Last modified: 2014-08-23 15:19:29 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T58373, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 56373 - Allow users to comment when thanking others
Allow users to comment when thanking others
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Thanks (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-30 12:18 UTC by Nathan Larson
Modified: 2014-08-23 15:19 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Nathan Larson 2013-10-30 12:18:44 UTC
Usually when I thank someone using the Thanks extension, I end up also leaving a message on the user talk page explaining exactly why I found their edit helpful. The thanking feature should provide an opportunity to accompany thanks with a brief comment (e.g. 255 characters or less, so it could fit in log_comment). That will save users steps and help aggregate information on why users find the edits that they're thanking people for helpful.
Comment 1 Nathan Larson 2014-01-02 03:44:40 UTC
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.
Comment 2 Kunal Mehta (Legoktm) 2014-01-02 04:09:14 UTC
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.
Comment 3 MZMcBride 2014-01-02 05:18:28 UTC
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.
Comment 4 Nathan Larson 2014-01-02 06:38:26 UTC
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.
Comment 5 Nathan Larson 2014-01-02 07:15:38 UTC
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.
Comment 6 Quiddity 2014-01-02 09:15:38 UTC
(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.
Comment 7 Nathan Larson 2014-01-02 11:15:12 UTC
(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.
Comment 8 Quiddity 2014-01-02 19:07:24 UTC
(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. :)
Comment 9 Nathan Larson 2014-08-23 15:04:36 UTC
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".
Comment 10 wctaiwan 2014-08-23 15:16:02 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links