My patch from bug 12211 implements this.

Fixed in r37263.

Reverted by Brion in r32278.

argh, 37278

Reassigned to vasilvv

Adding a gadget and activating it by default is a known source of problems. Somtimes it even breaks the clear intent of users, notably when the functionality breaks or invades their privacy.

For example, some gadgets have been activated in discussion pages that automated sending emails to users to inform them that a page "of interest" had been changed. This option was activated by default, and many users have complained that they now received tons of emails, just because in the past they had worked on many pages, even though they had set all their other preferences to NOT send them any email, but instead made their user page on all wikis to inform other users that they could be contacted in the Talk page of their "home" wiki. This activation caused MediaWiki sites to be reported as really SPAMMING (which it really was: the effect of enabling this option by default was completely equivalent to forcing users to subscribe to a new mailing list without their consent, assuming that they could "opt out" something that is not as easy as you think because the preferences panel is sometimes not usable when it is displayed by default in a language or script that they can't easily decipher and where even the language default is not so easy to locate and change).

Remember this: activating by default a new function that changes the behavior of the site MUST NOT be activated by default, unless there's a clear decision that the new behavior is MANDATORY FOR ALL (in which case there's not even the need for this option), or if the fact of not activating it for all will cause problems for working and supporting users that have not activated it.

Please let users decide by themselves which option they want, but in all cases, do not change the behavior for all users that already have an account where the option was not set.

There is preliminary consensus to turn on the RefTools gadget by default on en.wiki:
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Proposal_-_Turn_on_RefTools_gadget_by_default
Before I take this proposal to a wider audience, I wanted to decide how it would be implemented technically. If this bug is unlikely to be resolved soon, I may pursue the Common.js route instead. Thoughts?

(In reply to comment #7)

There is preliminary consensus to turn on the RefTools gadget by default on
en.wiki:
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Proposal_-_Turn_on_RefTools_gadget_by_default
Before I take this proposal to a wider audience, I wanted to decide how it
would be implemented technically. If this bug is unlikely to be resolved soon,
I may pursue the Common.js route instead. Thoughts?

You may want to look in the workaround used for Edittools on Wikimedia Commons. See "setup: function ()" of [[commons:MediaWiki:Edittools.js]] and [[commons:MediaWiki:Gadget-OldEdittools.js]].

• Bug 27460 has been marked as a duplicate of this bug. ***

(In reply to bug 27771 comment #9)

(In reply to bug 27771 comment #8)

Load by default: pending (bug 13742)

I can do it in 15 minutes, however I need wider discussion.

I'm not sure how the previous implementation was done, but I think such an option should use something like wgDefaultUserOptions (in other words: It would be on by default, and loaded for all anonymous users), but registered users can still go to Special:Preferences and untick the checkbox.

@Krinkle: the idea is to have only SPECIFIC gadgets to be turned on by default after they come to a RELEASE status (and not an experimental status), as if it was a new gadget. All gadgets should go though the experimental status before being released, and in that state they MUST be off by default. This means that the decision to make a gadget ON by default will chnage the user settings that have been activated/deactivated explicitly by some experimenters. As a consequence, there cannnot be a global setting enabling/disabling all gadgets at once for their default setting, given that each gadget (experimental or not) stores its own ON/OFF preference. Making one gadget ON by default can only result of a prior discussion reaching to a concensus (it can be motivated also by the fac that disabling it provides worse results on the site content administration, or too many common errors by users ; enabling it by default should have the effect of simpliying the work from most users).
If you enable a gadget by default, it must also be well maintained across MediaWiki versions: this involves additional work for MediaWiki developers, or at least from administrators of wikis of the WMF before deploying a new version there.
If the change is motivated by a policy, why a gadget ? the only good reason for not implementing it by default is that the gadget may be specific to some wiki sites, and not workable for others, and the policy results from a local concensus and does not necessarily match the policy use elsewhere. It can help recucing the dependencies between MediaWiki developers and site owners thart have installed and are maintaining their own local wiki.

My vision of this bug:

Pros:

• Less chaotic than Common.js dynamically loading stuff.
• Faster loading, provided that gadget's JS is ResourceLoader-compatible.
• Unlike global scripts, gadgets can be disabled by users who don't like them.

Cons:

• Butthurt "omg they enabled that preference for me and haven't even asked ME!!1oneone"
• This system is seemingly easy which may provoke clueless admins to wreck havoc.

There are two use cases for this bug:

1. Gadgets that are especially useful to newbies, but not as useful to established users. For example a license-picking wizard on Commons (doesn't exist yet). In this case, by the time a user learns about the Gadget and how to turn it on, they are probably too advanced to need it anymore.

2. Gadgets that are so useful to a project that the community wants them to be used universally (or nearly so). For example, RefToolbar on en.wiki (which was moved from a Gadget to Common.js).

My idea of how this would work is that:

• Gadget definitions (at MediaWiki:Gadgets-definition) would accept a 3rd parameter for 'default state' which could be set to true or false (empty = false)
• default gadgets would load for all anonymous users
• all new registered users would have them turned on in their prefs by default
• if an established user clicks "Restore all default settings" they would get the gadget turned on
• if the gadget is brand new (and doesn't yet have a saved ON/OFF state) it would default to ON for everyone
• the only way to mass-switch existing users' prefs would be to delete the existing gadget and relaunch it under a new name with the 'default' param set to true from the start (per the mechanism above)

This would make it impossible for admins to accidentally mass-switch everyone's gadget prefs and cause massive wikidrama, since there would have to be a conscious effort to re-launch the gadget for use case #2. It would also allow us to fulfill use case #1 without pissing off existing users by bombarding them with newbie gadgets that they have to turn off.

I think my outline above would eliminate both of Max's cons while still keeping all the pros. Do others agree that this would be a good implementation path?

The WMF Community department wants to start developing some "newbie gadgets" to address the newbie experience problem mentioned in the March 2011 update (http://strategy.wikimedia.org/wiki/March_2011_Update). Since this is a blocker, bumping priority to High.

The Dark Side I sense in this, but let's try...

Done in r85902. Would be great if someone re-checked this, I'm a bit dizzy from all those checkboxes.