Specify which edit was thanked in Special:Log/thanks, both for private and public records' sake, if configured to do so
Open, NormalPublic

Description

Splitting this out from T49658#527202:

I just learned about [[Special:Log/thanks]] and think that this log should be expanded to include a link to the edit. So instead of:

11:26, June 3, 2013 Okeyes (WMF) (talk | contribs) thanked Foo (talk | contribs)

it would read:

11:26, June 3, 2013 Okeyes (WMF) (talk | contribs) thanked Foo (talk | contribs) for this edit

and the words "this edit" would link to the diff of the revision.


See Also:
T56983: Add thanking to $wgRateLimits as emailuser, to avoid "thank nuking"
T57428: Remove all logging for the Thanks extension
T58818: UserProfile displays page that user was thanked on

Details

Reference
bz49087
There are a very large number of changes, so older changes are hidden. Show Older Changes

After just having had a bad experience related to Thanks on pl.wp (account suspected of being a sockpuppet of a troll spamming thanks to an user involved in banishing the troll) I'm inclined to agree with Scott. The log should be full (maybe accessible only to checkusers or stewards or something, but accessible to *someone*), or should not exist.

Isarra added a comment.Oct 4 2013, 9:00 PM

What Scott Martin and Nemo bis said.

A log that doesn't give context is generally useless at best, and why should anyone genuinely thanking someone else want to hide? If there truly is reason, it should only be for special cases, and for those an email or other private correspondence would probably be more appropriate anyway.

Accountability has become inherent in how these projects operate, but for things that are best off the record (whether for reasons of politeness or policy or just generally avoiding drama or what have you), there are off-wiki ways to discuss/handle them. I'm not convinced of any need for that to change here.

So, it appears that my use case is materializing now... Sits back to watch. :)

swalling wrote:

The logs that were built in to Thanks were for accountability. But they were built in to prevent excessive, spam-like blasts of indiscriminate thanks, not control for quality of thanking in relation to the edit.

Nemo: Jon's comment from IRC was a sarcastic joke in and of itself. The mobile team pulled a prank on its technical lead creating a bunch of fake to-do items of "high priority" one of which was to investigate "thanks trolling".

The thank you message is the same whether you really mean it or not. It is not possible to send a malicious or sarcastic thank you, per se, only one that is confusing (such as if you also leave the person a warning message).

Thanks on Wikipedia are just that: a message of gratitude from one user to the other. Who is thanking whom is not really anybody else's business. It's not a public display of gratitude or appreciation for a given edit. Not mentioning which edit was associated with the thank you is very much intentional, to avoid implying that particular edits are better than others because they received thanks.

Recently, we removed showing thank yous in Special:Logs by default (bug 52118) based on community request: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Notifications/Thanks&oldid=571964775#Must_we_list_every_Thank_under_.22View_logs.22.3F

There is little evidence that Thanks are something used abusively at all, and that they need monitoring in the same way edits or uploads do. Transparency is one of our values yes, but that doesn't mean we completely avoid private messages between users (Cf. Special:EmailUser).

I don't think it'll be an issue because the information is not currently logged, as I understand it, but if the behavior is changed here, we have to ensure that past thanks are not retroactively linked to specific edits. Users currently thank with the expectation that their thanks are unattributed to any specific edit and we can't violate that.

swalling wrote:

(In reply to comment #24)

I don't think it'll be an issue because the information is not currently
logged, as I understand it, but if the behavior is changed here, we have to
ensure that past thanks are not retroactively linked to specific edits. Users
currently thank with the expectation that their thanks are unattributed to
any
specific edit and we can't violate that.

My comment was not about retroactive compatibility. It was reiterating why this was WONTFIXed.

We don't add logging "just because" or on principle. We do it for a reason. In this case, the potential drawbacks outweigh the benefits. Consider the factors at play here, when considering what kind logging is needed:

  • There is little opportunity for abuse, beyond sheer volume, which is also rate limited.
  • There has been almost no over-use or other abuse to date. No one has presented any evidence this occurs regularly. The example brought up in Comment 20 is as far as I can tell not a remotely common problem.
  • The English Wikipedia community, as a big example and the community with the most experience with the feature, finds even the current logs to be not useful. They specifically requested we not show them by default, because there is no reason to monitor them.
  • No one wants Thanks to become a popularity contest, where diffs can be ranked or assessed by whether they receive thank yous. Making "thanks" a public +1 for an edit would poison the well. This is not a Like button for edits, and let's keep it that way.

If people really think it's an all-or-nothing issue, where the logs should be turned off entirely unless the diff is also logged, that should be a separate bug.

swalling wrote:

Bug 55428 nows outlines the request to remove all logging.

(I'm personally agnostic on the issue, just documenting it separately for the sake of clarity.)

On "a popularity contest, where diffs can be ranked or assessed by whether they receive thank yous": did someone explain somewhere how this would be a consequence of this request? It generally would not, unless the thanks log also became filterable by revision ID; logs linking specific revisions generally are not, as far as I can see.

Maybe we should keep all previous thanks private (not sure if they're stored in a table anyway) as the thankers may have expected privacy. Just something to consider here.

(In reply to PiRSquared17 from comment #28)

Maybe we should keep all previous thanks private (not sure if they're stored
in a table anyway) as the thankers may have expected privacy. Just something
to consider here.

I've no problem with only select set of contributors being able to see this information in the logs as long as the system can access the information in the database as needed to know if User:A has already thanked User:B for revision:###. I think that both User:A and User:B should see which edit the thank was for and I also think that a vetted group such as administrators, ArbCom members, or identified groups such as oversighters should have access to the information. I think this information should be made retroactively if that is possible.

  • Bug 62507 has been marked as a duplicate of this bug. ***

Even as the user who was thanked or who did the thanking, I can't tell from the log what edit this is for.

I got a notice when I was originally thanked, perhaps a few months ago, but AFAIK there is no way for me to reconstruct that now.

(In reply to Pharos from comment #31)

Even as the user who was thanked or who did the thanking, I can't tell from
the log what edit this is for.

I got a notice when I was originally thanked, perhaps a few months ago, but
AFAIK there is no way for me to reconstruct that now.

You should be able to find details in your [[Special:Notifications]] page, although I don't know how far back that archive extends.
I vaguely recall a discussion about it only going back 365 days, but that might have been a suggestion, rather than the actual implementation.
If anyone knows/finds out, please document it at https://www.mediawiki.org/wiki/Echo/Feature_requirements#Echo_Notification_Storage

(In reply to Quiddity from comment #32)

(In reply to Pharos from comment #31)
> Even as the user who was thanked or who did the thanking, I can't tell from
> the log what edit this is for.
>
> I got a notice when I was originally thanked, perhaps a few months ago, but
> AFAIK there is no way for me to reconstruct that now.

You should be able to find details in your [[Special:Notifications]] page,
although I don't know how far back that archive extends.
I vaguely recall a discussion about it only going back 365 days, but that
might have been a suggestion, rather than the actual implementation.
If anyone knows/finds out, please document it at
https://www.mediawiki.org/wiki/Echo/
Feature_requirements#Echo_Notification_Storage

While digging through your [[Special:Notifications]] page may be possible, it is entirely impractical to expect to be able to find a notification even a month ago when you receive dozens of mentions and talk page notifications daily. Don't forget that the notifications page only loads a few results at a time and you have to actively click on "show more" to get the next chunk. That means if you average 15 notifications a day, this is a few clicks to load each day's notifications and if you want something that was a month back, likely 100 or more clicks to get back that far. It should simply be available in the log which offers at least some filtering so you can show results that were in or before month of year.

Created attachment 14789
15 months old notifications

There are certainly older notifications. However, one of the root issues/design decisions of Echo is, long story short, that notifications are meant to be ephemeral rather than long-lasting. It's a big shift for those used to talk pages, yes.

Attached:

  • Bug 64284 has been marked as a duplicate of this bug. ***

As I understand the feature from having a brief read through the tech news, the Notifications/Thanks feature was developed by the Editor Engagement Experience team, in order to try and strike a fine balance between trying to draw in newer editors by introducing a friendly "Likes" feature and simultaneously keeping it ephemeral and private enough to avoid the public scrutiny of the "We are not Facebook" crowd. Of course, as a feature design, it's extremely difficult to reach that balance without tilting too much one way or the other. I'm surprised that people did not know about the design choice to keep a log public while not revealing the target edit of the Thanks (avoiding point-scoring).

At the same time, the third previously unaccounted-for aspect of this feature, which is the accountability, and subsequently the abuse, did not seem to be properly addressed. Perhaps we should make something even as trivial as a friendly thank you message to someone else, subject to intense scrutiny, curation, triple-checking and investigation for abuse by oversighters or whatever powers that be.

One of the other considerations that weighed heavily in the design of the Thanks feature was to avoid the feature bloat that doomed ArticleFeedback. Everyone hated ArticleFeedback because it required so much work to curate, monitor, and oversight for very little actual benefit. Thanks was designed to avoid all of that by being dead simple and ephemeral.

While keeping a detailed permanent record of every action that transpires on Wikipedia sounds like a good idea on paper, it has real costs in additional workload for the community, especially folks like admins and oversighters who have to deal with complaints. The way we tried to strike a balance was giving people a way to complain about Thank volume abuse (sending too many thanks), but avoiding the drama of people complaining about who thanked who for what edit. Do we really want another noticeboard for "Inappropriate thanks"?

swalling wrote:

(In reply to TeleComNasSprVen from comment #36)

As I understand the feature from having a brief read through the tech news,
the Notifications/Thanks feature was developed by the Editor Engagement
Experience team, in order to try and strike a fine balance between trying to
draw in newer editors by introducing a friendly "Likes" feature and
simultaneously keeping it ephemeral and private enough to avoid the public
scrutiny of the "We are not Facebook" crowd. Of course, as a feature design,
it's extremely difficult to reach that balance without tilting too much one
way or the other. I'm surprised that people did not know about the design
choice to keep a log public while not revealing the target edit of the
Thanks (avoiding point-scoring).

At the same time, the third previously unaccounted-for aspect of this
feature, which is the accountability, and subsequently the abuse, did not
seem to be properly addressed. Perhaps we should make something even as
trivial as a friendly thank you message to someone else, subject to intense
scrutiny, curation, triple-checking and investigation for abuse by
oversighters or whatever powers that be.

It is unclear to me that it is in fact possible to really abuse the feature.

Consider the following:

  • You can't write a custom message with the thanks, so the notification contents is always friendly.
  • The use of thanks is rate limited. If we want, we can talk about whether to increase that rate limit.

Accountability doesn't really enter into the matter when thanks is a standardized action with no negative consequences, with the exception of sending an excessive/annoying number of notifications.

(In reply to TeleComNasSprVen from comment #36)

Perhaps we should make something even as trivial as a friendly thank you
message to someone else, subject to intense scrutiny, curation, triple-checking
and investigation for abuse by oversighters or whatever powers that be.

This was written half-satirically and I agree with Kaldari that we shouldn't be spending too much resources for oversight on such a simple feature. At the same time we needed to establish a few simple abuse checks in place (your rate limit is one good example).

(In reply to Ryan Kaldari from comment #37)

One of the other considerations that weighed heavily in the design of the
Thanks feature was to avoid the feature bloat that doomed ArticleFeedback.

As demonstrated above, including an oldid/rev_id in a log row is standard log formatting, so it can't in any way be considered feature bloat and has nothing to do with AFT (which, for instance, reinvented logging instead of using Special:Log, with catastrophic consequences).

Base added a comment.Sep 18 2014, 7:21 PM

I was about to file a duplicate bug when noticed this one :) Here goes the text I've written for the almost filed dup:
When someone thanked you for a edit you made you can click on the notification you receive and see what edit exactly you were thanked for. But if you see in the Special:Log/thanks a thank of user A to user B you can't see what exactly he was thanked for. If user B has 1 edit then there are no questions but if he has more edits than it's not an easy task to determine the object of thank. I'm used that on-wiki I can see everything save for some private things like OS and CU logs, other users' whatchlists so it seems not right that I can't see the data in the case. I assume the data are not private in the issue because otherwise I can see little sense in existence of the log at all.

Base added a comment.Sep 18 2014, 7:26 PM

(In reply to Oliver Keyes from comment #6)

Keeping the subject of the 'thank' unlogged is a way of ensuring that this
won't happen; it makes it utterly impossible for anyone to actually justify
a statement of "well, lotsa people thought it was a good edit, check out my
log". Adding the edits as an element makes this risk more likely, not less.

The abuser described already could just give a screenshot of his notification page or whatsoever.

This was a deliberate design decision that has by now had a lot of discussion. No reason to leave open at this time.

waldyrious added a subscriber: waldyrious.
Huji added a comment.May 24 2016, 12:43 AM

@Legoktm so then how does Flow know which edit I was thanked for? The revision ID has to be stored somewhere, if not in the logging table.

The revision is also stored as part of the echo notification. For Flow, it's slightly different, as users are thanked for posts rather than revisions (if I understand correctly).

That's right. The notification is generated at thank time, so for both (wikitext thanks and Flow thanks) we put the post/revision ID in the event metadata but not in the public logging table.

There was some discussion on IRC that this could perhaps be allowed if a certain $wg was set (WMF production would keep the current behavior).

I've written a hack that doesn't require you to set a $wg; it would just be a 5::revid parameter that you could display by changing MediaWiki:Logentry-thanks-thank to, e.g., $1 thanked $3 for revision $5.

There have been a few times when I've thanked someone and then wanted to look at the log to see where the revision was that I thanked them for, because I was having trouble finding it again. I was going to give them a barnstar "for x, y, and z" because I remembered there had been a few contributions I had found particularly important, but it had been awhile so I had forgotten what exactly they were. I tried going through his contributions manually, to try to jog my memory, but there were thousands to sift through because he's a very active editor.

I've written a hack that doesn't require you to set a $wg; it would just be a 5::revid parameter that you could display by changing MediaWiki:Logentry-thanks-thank to, e.g., $1 thanked $3 for revision $5.

The $wg would control whether the $5 is passed. On WMF wikis, it would not be, since this is considered private information.

I've written a hack that doesn't require you to set a $wg; it would just be a 5::revid parameter that you could display by changing MediaWiki:Logentry-thanks-thank to, e.g., $1 thanked $3 for revision $5.

The $wg would control whether the $5 is passed. On WMF wikis, it would not be, since this is considered private information.

To clarify: the reason you need a $wg to control whether $5 is passed at all is because if $5 is passed unconditionally, it could trivially be exposed using ?uselang=qqx, and it'd also be visible in the logging table through the replica DB in tool labs. To make this information inaccessible on wikis that want it to be inaccessible, it needs to not be stored.

What do you want to call the $wg setting?

Tjlsangria added a comment.EditedSep 10 2016, 4:04 PM

I created this nifty maintenance script to retroactively populate the thanks log with revision IDs. https://www.mediawiki.org/wiki/User:Tjlsangria/populateThanksLogParams.php

Change 311364 had a related patch set uploaded (by Tjlsangria):
Specify which revision was thanked in Special:Log/thanks

https://gerrit.wikimedia.org/r/311364

Tjlsangria added a comment.EditedSep 26 2016, 1:18 AM

Other useful parameters could include the prefixed page title and the revision ID presented as a clickable link to [[Special:Diff/xxx|revision xxx]].

As there is a patch available, should this task be reopened?

Mattflaschen-WMF renamed this task from Specify which edit was thanked in Special:Log/thanks, both for private and public records' sake to Specify which edit was thanked in Special:Log/thanks, both for private and public records' sake, if configured to do so.Sep 26 2016, 8:26 PM
Mattflaschen-WMF reopened this task as Open.
David_Hedlund added a comment.EditedApr 25 2017, 7:42 PM

Links to the revisions for Thanks are currently in

  • Special:Contributions/<user_name>
  • Special/Notifications

but not in

  • Special:Log/thanks

As I know dewiki, to deploy this there without community consensus will probably create a shitstorm. That's why here should be a setting to disable this.

Can you clarify this? If Alice thanks Bob for revision 123, Bob should be able to know all of that. Eve (any other user) should just be able to tell that Alice thanked Bob, but not for what (unless this is patch is implemented and it's configured to reveal that on a particular wiki).

Links to the revisions for Thanks are currently in

  • Special:Contributions/<user_name>

That is just a list of revisions, but it shouldn't allow Eve to tell which revisions Alice thanked Bob for.

  • Special/Notifications

This is private to Bob.

As I know dewiki, to deploy this there without community consensus will probably create a shitstorm. That's why here should be a setting to disable this.

I don't understand the thumbs down. The task specifically says it will only be done if configured to do so.

@Mattflaschen-WMF

That is just a list of revisions, but it shouldn't allow Eve to tell which revisions Alice thanked Bob for.

Correct, I stroked the text.

David_Hedlund added a comment.EditedApr 26 2017, 11:06 AM

I don't see what I Thanked for @Mattflaschen-WMF

A Thanks log entry for Target David Hedlund

2017-04-21T23:08:23 Testem (talk | contribs) thanked David Hedlund (talk | contribs)

But I don't know what I was thanked for. It should read:

2017-04-21T23:08:23 Testem (talk | contribs) thanked David Hedlund (talk | contribs) for your edit on 25I-NBOMe

@MZMcBride Can you please copy my concrete example to the top of this post?

You can of course modify if to another existing Thank log.

@David_Hedlund: Are you describing the behavior with or without the patch (https://gerrit.wikimedia.org/r/#/c/311364/)?

@kaldari As Wikipedia is right now, without the patch I guess.

Change 311364 abandoned by TTO:
Specify which revision was thanked in Special:Log/thanks

Reason:
Needs discussion on task. Patch owner is banned so cannot contribute to a discussion here.

https://gerrit.wikimedia.org/r/311364

happy5214 moved this task from Backlog to Thanks on the Pywikibot-Thanks board.
Dvorapa added a subscriber: Dvorapa.

Sorry for the noise

Dvorapa removed a subscriber: Dvorapa.Jun 3 2018, 2:52 PM
matej_suchanek updated the task description. (Show Details)
matej_suchanek removed a subscriber: wikibugs-l-list.