Last modified: 2014-09-18 19:26:34 UTC
Splitting this out from bug 47658 comment 13: 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.
The Log entry was designed specifically to not include the edit. That allows the substance of the thanks to remain private while still providing a public record of the action in the event of someone using it for spamming.
Yeah, I was just poking at this. https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Thanks.git;a=blob;f=ApiThank.php;h=23f72b77df74cd5f4369ed1b4ec03e31902b052c;hb=HEAD#l65 --- // Log it if we're supposed to log it if ( $wgThanksLogging ) { $logEntry = new ManualLogEntry( 'thanks', 'thank' ); $logEntry->setPerformer( $agent ); $target = User::newFromId( $recipient )->getUserPage(); $logEntry->setTarget( $target ); $logid = $logEntry->insert(); } --- That appears to be the relevant code to update the logging table. https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Thanks.git;a=blob;f=ThanksLogFormatter.php;h=b55c2b2da0cb77c8a3acc01adc7dba111f536ab6;hb=HEAD --- <?php /** * This class formats log entries for thanks */ class ThanksLogFormatter extends LogFormatter { protected function getMessageParameters() { $params = parent::getMessageParameters(); // Convert target from a pageLink to a userLink since the target is // actually a user, not a page. $recipient = User::newFromName( $this->entry->getTarget()->getText(), false ); $params[2] = Message::rawParam( $this->makeUserLink( $recipient ) ); return $params; } public function getPreloadTitles() { // Add the recipient's user talk page to LinkBatch return array( Title::makeTitle( NS_USER_TALK, $this->entry->getTarget()->getText() ) ); } } --- This is the code that outputs the log entries at [[Special:Log/thanks]]. So... this would be a trivial change, iff the data were being logged. (In reply to comment #1) > The Log entry was designed specifically to not include the edit. That allows > the substance of the thanks to remain private while still providing a public > record of the action in the event of someone using it for spamming. Yeah... I didn't even realize thanks were publicly logged until today. I tend to agree that some discretion might be appropriate here. This bug may ultimately be a wontfix, but it'll be helpful to have a record of the design decision.
(In reply to comment #1) > The Log entry was designed specifically to not include the edit. That allows > the substance of the thanks to remain private while still providing a public > record of the action in the event of someone using it for spamming. I'm not sure I follow the usefulness of that Ryan... I would think it would be more useful to have the edit in the log because once it scrolls off your notification flyout/page, how else are you going to remember what it was? Also, having it public in the log (which I'm sure few will find) will make it easy to validate claims of people sarcastically thanking people in an attempt to harass them.
>I would think it would be more useful to have the edit in the log because once >it scrolls off your notification flyout/page, how else are you going to >remember what it was? Thanks are intended to be ephemeral. I wouldn't expect someone to go trawling through the logs to find old thanks for themselves. That's not the intended use of the logging. >Also, having it public in the log (which I'm sure few will find) will make it >easy to validate claims of people sarcastically thanking people in an attempt >to harass them. This seems like a more realistic use case and one that is probably worth discussing. Although I think there are far more effective ways to harass people on Wikipedia, it is a possible issue. My personal opinion would be to wait and see if this actually emerges as an issue before changing the log entries. I can also imagine cases where not including the edit may actually reduce conflict. For example, if you want to thank an editor for reverting a persistent vandal or POV-pusher, or you want to thank an admin who warned an editor who was harassing you. Just some things to think about.
The contents of an on-wiki communication should never be kept confidential. Keeping "the substance of the thanks private" is inappropriate.
(In reply to comment #5) > The contents of an on-wiki communication should never be kept confidential. > Keeping "the substance of the thanks private" is inappropriate. So we should also remove the 'email' feature? Here's my thinking here; what we're trying to avoid is a situation where the thanks button can in some way undermine consensus, or be used as a vector for it - we don't need (as you've pointed out, Kww) a situation where an editor justifies themselves based on thirty people hitting 'thank' on their edit. 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.
(In reply to comment #6) > (In reply to comment #5) > > The contents of an on-wiki communication should never be kept confidential. > > Keeping "the substance of the thanks private" is inappropriate. > > So we should also remove the 'email' feature? email would not be an on-wiki communication, therefor it is allowed to be private and you know that wasn't what kww said. > Here's my thinking here; what we're trying to avoid is a situation where the > thanks button can in some way undermine consensus, or be used as a vector for > it - we don't need (as you've pointed out, Kww) a situation where an editor > justifies themselves based on thirty people hitting 'thank' on their edit. > > 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. It also increase the likelihood of people abusing the feature to harass people by intentionally thanking and reverting multiple edits and offering the harassed no way of substantiating the claim and defending themselves. I see both side of the argument. What if.... We try and work out a middle ground that will address both concerns. By this I mean add the revision link to be only capable of being seen by people with a certain flag. I would think that it would be appropriate for the following groups to have the flag in this order of importance overseers, bureaucrats, administrators, and possibly reviewers. Doable?
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > The contents of an on-wiki communication should never be kept confidential. > > > Keeping "the substance of the thanks private" is inappropriate. > > > > So we should also remove the 'email' feature? > > email would not be an on-wiki communication, therefor it is allowed to be > private and you know that wasn't what kww said. > > > Here's my thinking here; what we're trying to avoid is a situation where the > > thanks button can in some way undermine consensus, or be used as a vector for > > it - we don't need (as you've pointed out, Kww) a situation where an editor > > justifies themselves based on thirty people hitting 'thank' on their edit. > > > > 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. > > It also increase the likelihood of people abusing the feature to harass > people > by intentionally thanking and reverting multiple edits and offering the > harassed no way of substantiating the claim and defending themselves. > Except there's a rate limit, and if someone was to repeatedly thank a user that they were reverting the edits of I think /someone/ would twig. UserA thanks UserB many times. We can see this. UserA reverts UserB's edits many times. We can see this. It doesn't take linking the two together to notice that UserA is probably being a complete arse.
(In reply to comment #6) > (In reply to comment #5) > > The contents of an on-wiki communication should never be kept confidential. > > Keeping "the substance of the thanks private" is inappropriate. > > So we should also remove the 'email' feature? Removing e-mail as a feature wouldn't bother me much. It seems to be used primarily as a method of stealth canvassing. The only people that actually require private communication about Wikipedia matters are checkusers, and they have a list.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #5) > > > > The contents of an on-wiki communication should never be kept confidential. > > > > Keeping "the substance of the thanks private" is inappropriate. > > > > > > So we should also remove the 'email' feature? > > > > email would not be an on-wiki communication, therefor it is allowed to be > > private and you know that wasn't what kww said. > > > > > Here's my thinking here; what we're trying to avoid is a situation where the > > > thanks button can in some way undermine consensus, or be used as a vector for > > > it - we don't need (as you've pointed out, Kww) a situation where an editor > > > justifies themselves based on thirty people hitting 'thank' on their edit. > > > > > > 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. > > > > It also increase the likelihood of people abusing the feature to harass > > people > > by intentionally thanking and reverting multiple edits and offering the > > harassed no way of substantiating the claim and defending themselves. > > > Except there's a rate limit, and if someone was to repeatedly thank a user > that > they were reverting the edits of I think /someone/ would twig. > > UserA thanks UserB many times. We can see this. UserA reverts UserB's edits > many times. We can see this. It doesn't take linking the two together to > notice > that UserA is probably being a complete arse. Except User A has a plausible deniability of saying I thanked for DFG and reverted TYU.
> I see both side of the argument. What if.... We try and work out a middle > ground that will address both concerns. By this I mean add the revision link > to be only capable of being seen by people with a certain flag. I would > think > that it would be appropriate for the following groups to have the flag in > this > order of importance overseers, bureaucrats, administrators, and possibly > reviewers. Doable? I suspect that Epipalegic and the rest of the "evil admins controlling Wikipedia" crew would have a field day. I once saw an editor claim that the reason admins speedy-deleted so many articles was so that we could keep the good content a secret from the rank-and-file. I still think the best way to deal with this problem is to pull the feature entirely, but if we have to have it, it should be kept transparent.
(In reply to comment #10) > (In reply to comment #8) > > (In reply to comment #7) > > > (In reply to comment #6) > > > > (In reply to comment #5) > > > > > The contents of an on-wiki communication should never be kept confidential. > > > > > Keeping "the substance of the thanks private" is inappropriate. > > > > > > > > So we should also remove the 'email' feature? > > > > > > email would not be an on-wiki communication, therefor it is allowed to be > > > private and you know that wasn't what kww said. > > > > > > > Here's my thinking here; what we're trying to avoid is a situation where the > > > > thanks button can in some way undermine consensus, or be used as a vector for > > > > it - we don't need (as you've pointed out, Kww) a situation where an editor > > > > justifies themselves based on thirty people hitting 'thank' on their edit. > > > > > > > > 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. > > > > > > It also increase the likelihood of people abusing the feature to harass > > > people > > > by intentionally thanking and reverting multiple edits and offering the > > > harassed no way of substantiating the claim and defending themselves. > > > > > Except there's a rate limit, and if someone was to repeatedly thank a user > > that > > they were reverting the edits of I think /someone/ would twig. > > > > UserA thanks UserB many times. We can see this. UserA reverts UserB's edits > > many times. We can see this. It doesn't take linking the two together to > > notice > > that UserA is probably being a complete arse. > > Except User A has a plausible deniability of saying I thanked for DFG and > reverted TYU. Sure, but users with a large number of edits that justify reverts are unlikely to be users with a large number of edits worth thanking.
WONTFIXing to be clear. The negatives of surfacing this far outweigh the positives.
*** Bug 53171 has been marked as a duplicate of this bug. ***
*** Bug 54748 has been marked as a duplicate of this bug. ***
REOPEN for basic accountability needs. 19.34 < jdlrobson> are we able to detect the difference between a sarcastic thank and a genuine thank? 19.34 < jdlrobson> something like Abusefilter The lack of basic accountability measures in the extension generates distrust in the tool as a whole. Bug 54983 comment 3 shows that communities want users to be held accountable for their thanking. Also, the log is almost completely meaningless and frustrating as of now, because each entry gives absolutely 0 context. Logs like patrol, pagetranslation, translationnotifications do this without problems, let's not make a fuss about such a simple and obvious request please.
I've not seen distrust generated; I would suggest that fixing this bug would lead to greater problems in the opposite direction (thanks being used for polling or endorsements, for example). I agree, we shouldn't make a fuss - we should just close it. Again.
Sorry, this needs to be left open for discussion.
I'm here from the duplicate in comment 15. There are all sorts of usage patterns that could occur with this tool, good and bad, and providing a partial log is worse than useless; it's actually bad. It encourages baseless guessing (and curiosity over and above the usual), and actually makes life harder for anyone trying to genuinely identify use of the tool. Either make the data generated by the thanking tool totally private, like Special:EmailUser (which I happen to agree with Kww could be removed entirely), or make it entirely public, just like all other on-wiki activities. This halfway house is of benefit to nobody.
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.
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. :)
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.
(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.
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 [details] 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.
*** 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"?
(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).
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.
(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.
