[Epic] Allow thanks of log entry
Open, NormalPublic

Tokens
"Like" token, awarded by Mahir256."Like" token, awarded by ToBeFree."Party Time" token, awarded by RandomDSdevel."Like" token, awarded by Vachovec1."Like" token, awarded by Reception123."Barnstar" token, awarded by Tbayer."Like" token, awarded by Liuxinyu970226."Like" token, awarded by Jenks24."Like" token, awarded by He7d3r."Love" token, awarded by MGChecker."Like" token, awarded by Morten_Haan."Love" token, awarded by Luke081515.
Assigned To
Authored By
duplicatebug, Dec 14 2013

Description

This task is for adding thanks links on Special:Log and friends, for certain whitelisted log types.

Status:

Log typeExample linkThanks link added?
abusefilterEdit filter modification log
articlefeedbackv5❌ Discontinued
blockBlock log
campusEducation Program campus volunteer log
closeflow-close-topic & flow-restore-topic✅ Can be thanked from special:log page, but are not listed by selves
contentmodelContentmodel change log
courseEducation Program course log
deleteDeletion log
eparticle❌ See T50495: [[Special:Log/eparticle]] does not exist
gather❌ Discontinued
gblblockGlobal block log
gblrenameGlobal rename log
gblrightsGlobal rights log and(?!) Global IP block log
globalauthGlobal account log
gwtoolsetGWToolset log
importImport log
institutionEducation Program institution log
instructorEducation Program instructor log
liquidthreadsThreaded discussion log❌ Discontinued
lockStructured discussions topic resolve/unresolve logT191482: Add thanks for resolving StructuredDiscussions topics?
managetagsTag management log
massmessageMass message log
mergeMerge log
moodbar❌ Discontinued
moveMove log
mwoauthconsumerOAuth consumer log
newusersUser creation log❌ It would confuse newcomers. they already get an auto-welcome notification at home-wiki
newsletterNewsletter issue log
notifytranslatorsTranslation notifications log
onlineEducation Program Online volunteer log
pagelangPage language change log
pagetranslationPage translation log
pagetriage-curationPage curation log
pagetriage-deletionDeletion tag log
patrolPatrol log❌ Reasons outlined in T60485#4125590
protectProtection log
renameuserUser rename log
reviewReview log
rightsUser rights log
spamblacklistSpam blacklist log
stablePending changes log
studentEducation Program student log
suppress❌ Private
tagTag log
thanksThanks log❌ Recursive/confusing/creates obligations of reciprocity
timedmediahandlerTimedMediaHandler log
titleblacklistTitle blacklist log (admin only)
translationreviewTranslation review log
uploadUpload log
usermergeUser merge log

Development tickets:

  1. T186763: Add thank link to the end of log entries which have associated revisions
  2. T186855: Add support for log-thanks to the Thanks API
  3. T186920: Update Special:Thanks to support log-thanks
  4. T186921: Update ext.thanks.revthank module to support log-thanks
  5. T187485: Add thanks link to log entries on Special:Log that are supported by the new log-thank API

Details

Reference
bz58485

Related Objects

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

It sounds like a log type (and not subtype) blacklist is still the easiest thing then.

I don't think we need to do the complicated thing of being able to thank from both places and then determine if an action has already been thanked elsewhere. Sounds tricky! :-)

Johan added a subscriber: Johan.Feb 1 2018, 10:04 PM

The problem arises, I imagine, when someone wants to thank in one place and doesn't realise it's done in another, if it's not obvious why a few actions are not thankable.

For upload, move and protect logs, you can actually display the "thanks" button next to the log entry, but make it submit a "revthank" for the associated revision.

The associated revision ID is stored in the logging.log_params database field, under the 'associated_rev_id' key, and you can access it using DatabaseLogEntry::getAssociatedRevId() (looks like you want to use the 'LogEventsListLineEnding' hook, which conveniently gives you a DatabaseLogEntry object).

Note that very old log entries will not have the associated rev id – we only started storing it in 2015 or so. I think it's fine to not allow thanks for these old log entries.

This comment was removed by MGChecker.

It sounds like a log type (and not subtype) blacklist is still the easiest thing then.

In my opinion, both should be possible: Blacklist whole log_types and distinct log_actions. This way, you have more flexiblity for different log concepts extensions use. And patrol is a log_type that needs the distinction in core, even if it's blocked by T136493 for now.

I don't think we need to do the complicated thing of being able to thank from both places and then determine if an action has already been thanked elsewhere. Sounds tricky! :-)

We need to develop a concept how to handle this, even if my proposal ist too complex.

kaldari updated the task description. (Show Details)Feb 6 2018, 11:21 PM
TBolliger assigned this task to Niharika.
TBolliger added a subscriber: Niharika.

Notes from discussions today:

  • In the coming weeks, we'll build in the ability to thank for the 'no brainer' log items
  • We will then post the list of the remaining log items on-wiki and ask users for input if we should add support for thanking them.
  • Later, based on community discussion, we can add functionality to thank for other log entry types.

@Niharika will own this as PM.

TBolliger renamed this task from Allow thanks of log entry to [Epic] Allow thanks of log entry.Feb 7 2018, 12:13 AM

Change 408500 had a related patch set uploaded (by Samwilson; owner: Samwilson):
[mediawiki/extensions/Thanks@master] [WiP don't review]

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

Niharika updated the task description. (Show Details)Feb 7 2018, 9:59 PM
Quiddity updated the task description. (Show Details)Feb 8 2018, 3:01 AM
Quiddity updated the task description. (Show Details)Feb 8 2018, 3:04 AM

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).

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"

TBolliger updated the task description. (Show Details)Feb 8 2018, 6:54 PM
MGChecker added a comment.EditedFeb 8 2018, 7:58 PM

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

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.

Niharika updated the task description. (Show Details)Feb 8 2018, 9:26 PM

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.

Niharika updated the task description. (Show Details)Feb 21 2018, 12:11 AM
Isarra added a subscriber: Isarra.Mar 2 2018, 5:00 PM

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.

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)

Izno added a subscriber: Izno.Mar 26 2018, 1:58 PM

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.

Niharika added a comment.EditedApr 10 2018, 12:34 AM

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)
Krinkle added a subscriber: Krinkle.EditedApr 11 2018, 2:46 AM
  • "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?

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 .

Niharika updated the task description. (Show Details)Apr 11 2018, 7:51 PM
JJMC89 updated the task description. (Show Details)Apr 11 2018, 7:56 PM

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.

  • "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.

Niharika updated the task description. (Show Details)Apr 11 2018, 8:10 PM
Quiddity updated the task description. (Show Details)Apr 11 2018, 9:38 PM
Izno added a comment.EditedApr 11 2018, 10:17 PM

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)

  • "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?

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.

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.

Niharika updated the task description. (Show Details)Apr 12 2018, 12:36 AM
Krinkle updated the task description. (Show Details)EditedApr 12 2018, 12:37 AM
Krinkle updated the task description. (Show Details)

(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

matmarex removed a subscriber: matmarex.Apr 12 2018, 3:13 PM

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).

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").

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.

Restricted Application added a project: Growth-Team. · View Herald TranscriptSep 3 2018, 9:07 AM

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.

SBisson moved this task from Inbox to External on the Growth-Team board.Sep 7 2018, 3:18 PM