Last modified: 2014-09-04 20:47:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T61807, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 59807 - $wgThanksConfirmationRequired should be a preference
$wgThanksConfirmationRequired should be a preference
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
Thanks (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-07 23:55 UTC by Jackmcbarn
Modified: 2014-09-04 20:47 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jackmcbarn 2014-01-07 23:55:57 UTC
Users should have a preference to control whether they wish to confirm sending thanks, rather than having $wgThanksConfirmationRequired control it for all users.
Comment 1 Steven Walling 2014-01-08 00:52:56 UTC
What if we just turn off the confirmation? Is it really so dangerous to thank someone with a standardized message that confirmation is required?
Comment 2 Steven Walling 2014-01-08 00:53:22 UTC
I ask what I did in comment 1 because adding a preference to our already totally bloated preferences lists is undesirable.
Comment 3 Kunal Mehta (Legoktm) 2014-01-08 01:16:16 UTC
(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.
Comment 4 Erik Moeller 2014-01-08 01:45:55 UTC
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.
Comment 5 Jackmcbarn 2014-01-08 02:17:18 UTC
I can see users undoing other users' edits when they mean to undo their own thanks.
Comment 6 Dereckson 2014-01-08 14:24:19 UTC
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.
Comment 7 Dereckson 2014-01-08 14:24:52 UTC
[ Not suitable for new developer, as there are implementation issues. Removing easy keyword. ]
Comment 8 MZMcBride 2014-01-08 22:30:55 UTC
Dupe of bug 53879?
Comment 9 MZMcBride 2014-01-08 22:31:54 UTC
Or bug 47658, as mentioned in comment 3.
Comment 10 Quiddity 2014-01-09 21:25:38 UTC
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
Comment 11 Amir E. Aharoni 2014-06-01 15:11:25 UTC
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
Comment 12 Quiddity 2014-06-01 17:54:54 UTC
(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!
Comment 13 Quiddity 2014-08-16 00:24:31 UTC
(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")
Comment 14 Kunal Mehta (Legoktm) 2014-09-04 20:39:58 UTC
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.
Comment 15 Steven Walling 2014-09-04 20:47:57 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links