$wgThanksConfirmationRequired should be a preference
Closed, DeclinedPublic

Assigned To
None
Priority
Low
Author
Jackmcbarn
Subscribers
Amire80, Legoktm, jayvdb and 7 others
Projects
Reference
bz59807
Description

Users should have a preference to control whether they wish to confirm sending thanks, rather than having $wgThanksConfirmationRequired control it for all users.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53879

bzimport added a project: Thanks.Via ConduitNov 22 2014, 2:28 AM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz59807.
Jackmcbarn created this task.Via LegacyJan 7 2014, 11:55 PM
bzimport added a comment.Via ConduitJan 8 2014, 12:52 AM

swalling wrote:

What if we just turn off the confirmation? Is it really so dangerous to thank someone with a standardized message that confirmation is required?

bzimport added a comment.Via ConduitJan 8 2014, 12:53 AM

swalling wrote:

I ask what I did in comment 1 because adding a preference to our already totally bloated preferences lists is undesirable.

Legoktm added a comment.Via ConduitJan 8 2014, 1:16 AM

(In reply to comment #1)

What if we just turn off the confirmation? Is it really so dangerous to thank
someone with a standardized message that confirmation is required?

I guess that should be discussed in a different bug then? Bug 47658 is what added it based on my quick skim.

I would recommend collecting some statistics to see how many people click on thanks and then hit no (accidental) versus number of people who hit yes (on purpose).

(In reply to comment #2)

I ask what I did in comment 1 because adding a preference to our already
totally bloated preferences lists is undesirable.

If there is a legitimate reason to add a preference, it shouldn't be dismissed because there are extensions/core which have added useless ones. That shouldn't stop us from holding it to higher standards though.

Eloquence added a comment.Via ConduitJan 8 2014, 1:45 AM

A proper "undo" feature would be the right way to do it. A bit tricky technically, but IMO far better than all the alternatives, so I think we should open a bug for that and close this one as WONTFIX.

Jackmcbarn added a comment.Via ConduitJan 8 2014, 2:17 AM

I can see users undoing other users' edits when they mean to undo their own thanks.

Dereckson added a comment.Via ConduitJan 8 2014, 2:24 PM

I concur with Jackmcbam.

Another risk: if you click on undo after the editor has received the notification, it would give the false feeling it has been cancelled when it weren't.

Dereckson added a comment.Via ConduitJan 8 2014, 2:24 PM

[ Not suitable for new developer, as there are implementation issues. Removing easy keyword. ]

MZMcBride added a comment.Via ConduitJan 8 2014, 10:30 PM

Dupe of bug 53879?

MZMcBride added a comment.Via ConduitJan 8 2014, 10:31 PM

Or bug 47658, as mentioned in comment 3.

Quiddity added a comment.Via ConduitJan 9 2014, 9:25 PM

Note, this is the (ongoing) Enwiki thread that led to this bug being filed: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Raging_thanking_dragon

Amire80 added a comment.Via ConduitJun 1 2014, 3:11 PM

Mmm... so is there any plan to do something about this? It would be really nice to skip the confirmation. The reasons in the English Wikipedia thread [1] seem rather weak to me. Thanking should be more streamlined.

[1] https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29/Archive_122#Raging_thanking_dragon

Quiddity added a comment.Via ConduitJun 1 2014, 5:54 PM

(In reply to Amir E. Aharoni from comment #11)

Mmm... so is there any plan to do something about this? It would be really
nice to skip the confirmation. The reasons in the English Wikipedia thread
[1] seem rather weak to me. Thanking should be more streamlined.

[1]
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29/
Archive_122#Raging_thanking_dragon

Those reasons were perhaps better described by Bartosz in bug 53879 (comment.5), and by MZ in bug 47658 (comment.0).

As Erik says above in this bug (comment.4), the ideal solution would be a proper "undo" feature for accidental Thanks.
The difficulty with that is, Thanks currently sends the message of appreciation *immediately*, by Echo *and by* Email (if enabled), hence developers would need to create some sort of delay system (30 or 60 seconds, were suggested elsewhere) in order for the "undo" feature to work as users want it to.
(I.e. We really can't send a 2nd email saying: "Ooops, Bob has 'unThanked' your edit, so please ignore the previous email!")
As Erik concludes, that should probably be a New Bug. Feel free to file it, and/or Patches Welcome!

Quiddity added a comment.Via ConduitAug 16 2014, 12:24 AM

(In reply to Erik Moeller from comment #4)

A proper "undo" feature would be the right way to do it. A bit tricky
technically, but IMO far better than all the alternatives, so I think we
should open a bug for that and close this one as WONTFIX.

I've filed bug 69636 ("Thanks: Implement an undo feature")

Legoktm added a comment.Via ConduitSep 4 2014, 8:39 PM

The confirmation step is now much less annoying due to jquery.confirmable. WONTFIXing because there's no way we're going to add a preference for it. General discussion about a confirmation step can be on bug 53879.

bzimport added a comment.Via ConduitSep 4 2014, 8:47 PM

swalling wrote:

(In reply to Kunal Mehta (Legoktm) from comment #14)

The confirmation step is now much less annoying due to jquery.confirmable.
WONTFIXing because there's no way we're going to add a preference for it.
General discussion about a confirmation step can be on bug 53879.

Thanks very much Kunal. I agree that this (plus considering bug 69636 as an alternative) is the right way to go.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.