In T60485#3954779, @Quiddity wrote:

I've added a bunch of log-types that were missing or new. (My previous list didn't include Enwiki-specific items. I think I assumed someone would make or link a more thorough list using the code? I don't know if there are still any missing. I checked Meta, Commons, Wikidata, Enwiki, Enwikisource, Enwiktionary, Incubator).

I've linked them all to active examples for easy context.

I'll note there were concerns further above (T60485#2249703) about thanking for block log entries. I suggest removing those 3 types from the "Do allow" list, and mark them as "needs discussion" (block, global block, global IP block).

Thank you! Yes, let's create a section for "needs discussion"

I think we shouldn't do any private logs like checkuser-log or suppressionlog.

In T60485#3956517, @MGChecker wrote:

I think we shouldn't do any private logs like checkuser-log or suppressionlog.

Good point about private logs.

We are going to make all logs opt-in, instead of opt-out, so this should not be a problem.

In T60485#3956517, @MGChecker wrote:

I think we shouldn't do any private logs like checkuser-log or suppressionlog.

What's the reasoning behind that? Thanks log doesn't expose why the thanks was done.

First of all, it makes this whole thing more complicated. You have to check the accessibility of the log for a given user before delivering a thanks he commited. (Well, you don't have to, as you're technically aren't disclosing any private information, but this leads me to the second point.)

Furtermore, it will be confusing for users to get thanks for actions with high privacy concerns. They might be unsure if there can be any disclosure of associated information. And there are some ideas to provide more information in the thanks log. This would be much more complicated to handle if we allow thanks for restricted logs.

Last but not least, it will cause some actions only thankable by some users, which isn't the case now. It might be a personal hunch, but it feels like this is against the principle of this feature.

Will the exceptions be configurable? Some wikis will have different appropriate uses or only want more simple/common options to be thankable, whereas others may actually want to thank even the most frivolous things. Especially the most frivolous things.

In T60485#4018364, @Isarra wrote:

Will the exceptions be configurable? Some wikis will have different appropriate uses or only want more simple/common options to be thankable, whereas others may actually want to thank even the most frivolous things. Especially the most frivolous things.

That's not in the current plan. We were aiming to have a single whitelist of types of logs which will be thankable on all wikis. Our current criteria for having a log in the list is that thanking for that doesn't come across as harmful/doesn't encourage negative behavior. This is why "block" related logs are not in the whitelist. Pretty much everything else is allowed.

(sorry for the delayed response)

With that^, I think we've come to an end with this project. Woohoo!
The new thanks links will show up this week if the trains runs fine.

We do have some subtasks so I'm not going to close this ticket for now.

Here's all of the log types in the database for enwiki:

MariaDB [enwiki_p]> SELECT DISTINCT log_type FROM logging;
+---------------------+
| log_type            |
+---------------------+
| abusefilter         |
| articlefeedbackv5   |
| block               |
| campus              |
| close               |
| contentmodel        |
| course              |
| delete              |
| eparticle           |
| gather              |
| gblblock            |
| gblrights           |
| globalauth          |
| import              |
| institution         |
| instructor          |
| lock                |
| managetags          |
| massmessage         |
| merge               |
| moodbar             |
| move                |
| newusers            |
| online              |
| pagetriage-curation |
| pagetriage-deletion |
| patrol              |
| protect             |
| renameuser          |
| review              |
| rights              |
| stable              |
| student             |
| tag                 |
| thanks              |
| timedmediahandler   |
| upload              |
| usermerge           |
+---------------------+
38 rows in set (0.24 sec)

• "Global account log"

Might I suggest moving "Global account log" to "not/needs discussion". It seems to be very similar to the block and global block logs, which seem equally controversial. Or was this intentionally whitelisted?

• "Mass message log"

This seems fine, but we may want to limit initial roll-out to just the subtype for massmessage/send (Submission). The other subtypes represent internal system failures, and personal opt-outs; which probably should not be thank-able.

• "Patrol log"

Patrolling a revision is a fairly complex user action. It is significantly different from other review actions (like for translation and FlaggedRevs) because a reviewer will "patrol" both good and bad edits. It has no absolute meaning beyond that the revision "has been dealt with". It probably should not be thank-able?

Perhaps move to "Not" or "Unexamined" for now (matching "Page curation", "Pending changes", "Review log").

• "Protection log"

May want to place under "Not", given this also creates a revision (just like "Move log"), which is more visible and already thank-able.

Actually, I was about to suggest that the users should be somehow notified that thanks for the "Move" and "Upload" logs are disabled as the corresponding revisions are already thankable. Then, I noticed that the "Move" logs are currently thankable. Is this intentional making the task description stale OR is the task description still valid and the "Move" logs are thankable by accident?

In T60485#4122820, @Kaartic wrote:

Actually, I was about to suggest that the users should be somehow notified that thanks for the "Move" and "Upload" logs are disabled as the corresponding revisions are already thankable. Then, I noticed that the "Move" logs are currently thankable. Is this intentional making the task description stale OR is the task description still valid and the "Move" logs are thankable by accident?

If a log item has an associated revision, we place a 'thank' link to trigger thanks for the revision (work was done in T186763: Add thank link to the end of log entries which have associated revisions .

Okay, so I cleaned up the task description. Many props to @Quiddity for taking the painstaking effort to document it all in the first place.
The list of log types comes from meta, enwiki, mediawiki and commons. I'm bound to have missed some, so please add them if you find any.

In T60485#4122188, @Krinkle wrote:

• "Global account log"

Might I suggest moving "Global account log" to "not/needs discussion". It seems to be very similar to the block and global block logs, which seem equally controversial. Or was this intentionally whitelisted?

Yeah, it's not thankable. The description was out of date.

• "Mass message log"

This seems fine, but we may want to limit initial roll-out to just the subtype for massmessage/send (Submission). The other subtypes represent internal system failures, and personal opt-outs; which probably should not be thank-able.

Good point. We currently do not filter by subtypes anywhere but we'd probably have to do that (see T191599 too).

• "Patrol log"

Patrolling a revision is a fairly complex user action. It is significantly different from other review actions (like for translation and FlaggedRevs) because a reviewer will "patrol" both good and bad edits. It has no absolute meaning beyond that the revision "has been dealt with". It probably should not be thank-able?

I'm trying to understand this a bit. I assume when someone thanks someone for patrolling an edit, they are thanking them for taking the time and effort to deal with it. Why do you think it should not be thankable? I don't imagine people use thanks a lot for patrol actions but I don't see what's harmful if we do allow them to be thanked.

• "Protection log"

May want to place under "Not", given this also creates a revision (just like "Move log"), which is more visible and already thank-able.

We decided to add thank links for log entries which create revisions too to avoid confusing people when they see thanks links on the edit history page but not on special:log. See T186763: Add thank link to the end of log entries which have associated revisions . We currently do not de-duplicate these so people can thank for the same edit from multiple places.

Thanks @JJMC89!

Since the education program extension is going away on Wikimedia wikis, does it make sense to track that in this task (which I would guess is mostly pointed at Wikimedia wikis due solely to scope)? (wrt eparticle log)

In T60485#4124763, @Niharika wrote:

In T60485#4122188, @Krinkle wrote:

• "Patrol log"

Patrolling a revision is a fairly complex user action. It is significantly different from other review actions (like for translation and FlaggedRevs) because a reviewer will "patrol" both good and bad edits. It has no absolute meaning beyond that the revision "has been dealt with". It probably should not be thank-able?

I'm trying to understand this a bit. I assume when someone thanks someone for patrolling an edit, they are thanking them for taking the time and effort to deal with it. Why do you think it should not be thankable? I don't imagine people use thanks a lot for patrol actions but I don't see what's harmful if we do allow them to be thanked.

With FlaggedRevs or Translation, the review (or "approval") action is both a positive contribution to "the site", and a positive signal to the author of the now-approved content.

With patrol, the second isn't always the case. Patrol merely indicates it was "dealt with". Somewhat similar to "marking as read" in your e-mail inbox (or archive/delete, depending on your style). Patrol can mean one of three things (based on my own experience):

• In the case of vandalism, one will likely undo or rollback the edit. Once done, the edit will also be patrolled, otherwise it remains in the unpatrolled queue. For convenience, rollback even patrols the reverted edit(s) automatically. And, rollback operates on all edits by the same author in sequence (1 new revision that reverts N bad revisions, but also N patrol entries). In this case, the thank-ability of the patrol log could also become an abuse vector between vandal and patroller.
• In the case of reviewing multiple changes at once (e.g. from your watchlist, compare 50 or so changes to the same page from when I last saw it), I will typically make one big follow-up edit, and then mark them all as patrolled. In this case, the review happened in impersonal way, and there is actually a good chance that the individual text added by an edit was never visible to me, not even in the overall diff; for example, if the added text was since changed or removed. As such, the action performed by the patroller does not correlate to the multitude of internal entries found in the patrol log.
• In the case of marking as patrolled a positive contribution, thanking could be useful in theory, but I see it more as confusing. This because patrolling is not a step to publication. (Unlike FlaggedRevs and Translate.) Patrolling happens post-publish. It is merely to detect clean-up afterwards. In probably 90% of cases, I press "mark as patrolled" in under a second and move on the the edit because it was already live, it doesn't approve anything.

• "Protection log"

May want to place under "Not", given this also creates a revision (just like "Move log"), which is more visible and already thank-able.

We decided to add thank links for log entries which create revisions too to avoid confusing people when they see thanks links on the edit history page but not on special:log. See T186763: Add thank link to the end of log entries which have associated revisions . We currently do not de-duplicate these so people can thank for the same edit from multiple places.

Sounds good. What do you mean by not de-duplicating, though? Do you mean the user interface, or the database rows? I assume that log entries with revisions are thank-able in the user interface in a way that internally they end up thanking the associated revision, not the log entry. As such, not allowing the same event to be thanked by both means, is that right?

In T60485#4125180, @Izno wrote:

Since the education program extension is going away on Wikimedia wikis, does it make sense to track that in this task (which I would guess is mostly pointed at Wikimedia wikis due solely to scope)? (wrt eparticle log)

I wanted to make an exhaustive list for now so if someone asks for a log type to be thank-able, we can point them here.

In T60485#4125590, @Krinkle wrote:

With FlaggedRevs or Translation, the review (or "approval") action is both a positive contribution to "the site", and a positive signal to the author of the now-approved content.

With patrol, the second isn't always the case. Patrol merely indicates it was "dealt with". Somewhat similar to "marking as read" in your e-mail inbox (or archive/delete, depending on your style). Patrol can mean one of three things (based on my own experience):

• In the case of vandalism, one will likely undo or rollback the edit. Once done, the edit will also be patrolled, otherwise it remains in the unpatrolled queue. For convenience, rollback even patrols the reverted edit(s) automatically. And, rollback operates on all edits by the same author in sequence (1 new revision that reverts N bad revisions, but also N patrol entries). In this case, the thank-ability of the patrol log could also become an abuse vector between vandal and patroller.
• In the case of reviewing multiple changes at once (e.g. from your watchlist, compare 50 or so changes to the same page from when I last saw it), I will typically make one big follow-up edit, and then mark them all as patrolled. In this case, the review happened in impersonal way, and there is actually a good chance that the individual text added by an edit was never visible to me, not even in the overall diff; for example, if the added text was since changed or removed. As such, the action performed by the patroller does not correlate to the multitude of internal entries found in the patrol log.
• In the case of marking as patrolled a positive contribution, thanking could be useful in theory, but I see it more as confusing. This because patrolling is not a step to publication. (Unlike FlaggedRevs and Translate.) Patrolling happens post-publish. It is merely to detect clean-up afterwards. In probably 90% of cases, I press "mark as patrolled" in under a second and move on the the edit because it was already live, it doesn't approve anything.

Thanks for the detailed answer. It makes more sense now. I will make a patch to make patrol entries as non-thank-able.

Sounds good. What do you mean by not de-duplicating, though? Do you mean the user interface, or the database rows? I assume that log entries with revisions are thank-able in the user interface in a way that internally they end up thanking the associated revision, not the log entry. As such, not allowing the same event to be thanked by both means, is that right?

Oops, sorry, you're right. I had a fuzzy memory of an earlier conversation about this which was wrong. It works the way you describe, The same event is not thank-able from multiple places.

(Lack of edit conflict detection in Phabricator remains unfortunate.)

@Niharika Thanks. I had actually mis-verified the theory using "import" logs, but looks like those have a separate issue. Filed at T192043.

Yeah, we should switch to using MediaWiki. :P

Change 425729 had a related patch set uploaded (by Niharika29; owner: Niharika29):
[mediawiki/extensions/Thanks@master] Disable thanks for patrol log entries per discussion

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

In T60485#4123775, @TBolliger wrote:

If a log item has an associated revision, we place a 'thank' link to trigger thanks for the revision (work was done in T186763: Add thank link to the end of log entries which have associated revisions .

OK. IIUC, then why are the 'upload' logs not thankable? I thought they were not in the whitelist as they "create a revision".

I understand the reasoning to disallow 'thanks' for some logs (such as User creation log and Thanks log, because it can be confusing). But I see no reasoning to disallow 'thanks' for these log types:

• abusefilter
• gblrename
• renameuser
• stable (for the pending changes log).

In T60485#2249703, @MGChecker wrote:

My preferred use case would be thanking file uploads. Furthermore, I would like to use it to thank sysops if I ask them to use their rights to do something for me, so deletion, rights and protect log would be nice options too.
If I think about ist, maybe thanks for blocks should only be an option since a block is a really destrucitve action. I imagine really weird situations about users thaning sysops because they blocked another user thex don't like...

I do not understand the hesitations about the log type "block" (and "gblblock" and "gblrights" and "globalauth").
A block can be seen as a "destructive action". But a deletion can be seen as a "destructive action" too. And these two actions can also be seen as "positive actions", because they protect the Wikimedia projects.
I suppose that the hesitations should be about consensual/contentious actions, instead of positive/destructive actions. But all the actions can be considered contentious (by some users): there are contentious blocks, contentious deletions, contentious moves, contentious protections, etc.
I think that most of the actions are not contentious, and that most of the contentious actions do not lead to harassment/trolling, and that the sysops have the necessary experience to handle these situations. So I think that we should assume good faith (of the contributors who just want to thank the sysops) and allow 'thanks' for the log type "block" (and "gblblock" and "gblrights" and "globalauth").

In T60485#2249703, @MGChecker wrote:

My preferred use case would be thanking file uploads. Furthermore, I would like to use it to thank sysops if I ask them to use their rights to do something for me, so deletion, rights and protect log would be nice options too.
If I think about ist, maybe thanks for blocks should only be an option since a block is a really destrucitve action. I imagine really weird situations about users thaning sysops because they blocked another user thex don't like...

What "weird situations" are you supposing?
Let's suppose that Foo and Bar hate each other, and each one has a "fan club of contributors", and Foo opens a request against Bar, and the sysop Baz blocks Bar due to the request. What kind of harassment/trolling (in the block log) are you supposing? The "Foo hooligans" would thank Baz in the block log? The "Bar hooligans" would dishonestly thank Baz in the block log?

In this example, I was unable to thank for the edit of a topic summary of a structured discussion. I do not see the associated log type in the description of this task.

I wanted to thank today a global sysop for two blocks he's made saving the wiki from a vandalism spree and I saw that thanks in block log doesn't work. Any reason for that? Thanks.

In T60485#4552807, @MarcoAurelio wrote:

I wanted to thank today a global sysop for two blocks he's made saving the wiki from a vandalism spree and I saw that thanks in block log doesn't work. Any reason for that? Thanks.

For the first round of this project we opted to make the 'safe' logs thankable. Although thanks are private, blocks can be contentious, emotional, or difficult. Opening another avenue for communication about them could potentially make the process of discussing these difficult blocks more complicated.

That said, most blocks are straightforward so allowing 'thanks' would probably be fine.

Change 501522 had a related patch set uploaded (by Matěj Suchánek; owner: Matěj Suchánek):
[mediawiki/extensions/Thanks@master] Enable thanks from pagelang and upload log

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

I will note that the patch to disable thanks for patrol logs has never been merged, and therefore thanking for them is enabled, contrary to this task's description:

patrol	Patrol log	❌ Reasons outlined in T60485#4125590 (Patch-For-Review)

[mediawiki/extensions/Thanks@master] Disable thanks for patrol log entries per discussion
https://gerrit.wikimedia.org/r/425729

I think this is harmless, and the feature is used (although very sparingly), at least on en.wp where I checked – this query finds 25 such thanks log entries:

select *
from log_search
left join logging as thanked_log
on substring(ls_value, 5) = log_id
where ls_field='thankid'
and left(ls_value, 4) = 'log-'
and log_type='patrol'

But if you decide to actually disable them, please also reply on T52867 (which requested this feature) and decline it.

Change 425729 abandoned by Thiemo Kreuz (WMDE):
[mediawiki/extensions/Thanks@master] Disable thanks for patrol log entries per discussion

Reason:
Trivial patch from 3 years ago. Can easily be recreated or reopened if it's still needed.

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