BetaFeatures: "Automatically enable ..." should actually automatically enable, not require visiting Special:Preferences
Open, HighPublic

Description

Refers to "Automatically enable all new beta features"

From bug T62748.

However, the current code will only enable the new betafeatures when the user visits Special:Preferences, or whenever the 'GetPreferences' hook is run (API's action=options I think).


Needs to handle metrics properly (see comments).

Idea:

  1. Keep track of date "Automatically enable..." was set to "yes" in a hidden preference/somewhere (when you turn this off, it clears the date and stores all the existing enabled Beta Features as explicitly on (since the default will then flip)).
  2. Store the date each beta feature was launched (may very by wiki) in config.
  3. Use UserGetDefaultOptions. If "Automatically enable" is on, set the default to "enabled" for any Beta Feature that was launched after the "checkbox yes date" (see #1). Otherwise, the default is "disabled". Either way, you can override the default by saving preferences at any time.

The old code should be removed, because it causes bugs like T164118: Can't turn off "New filters for edit review" if "Automatically enable all new beta features" is on.

Details

Reference
bz62815
bzimport raised the priority of this task from to High.
bzimport set Reference to bz62815.
bzimport added a subscriber: Unknown Object (MLST).

bump. Just realized this from the Hovercards rollout that this is broken, we should probably fix this, since we have a lot of bete features coming up soon

Once again, with HHVM, and soon with Form refresh, we're losing out on lots of people who said opt me in, but the function isn't working.

Idea:

  1. Keep track of date "Automatically enable..." was set to "yes" in a hidden preference/somewhere.
  2. Store the date each beta feature was launched (may very by wiki) in config.
  3. Enable Beta Feature for any feature that was launched after the checkbox yes date (and does not have an explicit setting in the database, so you can still turn it off if you want).

When you go to the actual preference page, the checkboxes should reflect the logic from #3.

Jdforrester-WMF moved this task from Backlog to Next-up on the BetaFeatures board.Dec 2 2014, 8:45 PM
Tgr added a subscriber: Tgr.Dec 22 2014, 8:30 PM
In T64815#668420, @Mattflaschen wrote:

Idea:

  1. Keep track of date "Automatically enable..." was set to "yes" in a hidden preference/somewhere.
  2. Store the date each beta feature was launched (may very by wiki) in config.
  3. Enable Beta Feature for any feature that was launched after the checkbox yes date (and does not have an explicit setting in the database, so you can still turn it off if you want).

That would mean users who enabled everything do not affect feature usage counts. It would also make something like T62012 much harder to implement.

As a horrible hack, one could set $wgDefaultUserOptions for each beta feature based on the auto-enable setting - 0 if it is off, 2 if it is on. That would make it possible to tell apart opted-in and defaulted-in users, and pave the path towards using tri-state checkboxes as well if we ever want to do that (generally a better way to handle on/off switches with a default state, IMO). The user would still have to visit Special:Preferences for the usage counts to be updated, though.

@Tgr that is less than idea, and not being able to measure usage counts, would be really problematic if we're using usage as a metric for feature readiness

Smart metrics would distinguish between:

  1. Active users who opted into a specific feature.
  2. Inactive users (haven't edited recently, maybe haven't even logged in recently) who opt-ed into a specific feature.
  3. Active users who opted into the general "automatic enable" and are thus using your feature (haven't specifically opted out of that individual feature)
  4. Inactive users who opted into the general "automatic enable" and are thus using your feature.

If they have automatic enable and are using the feature, that may just mean they haven't gone in and disabled the feature, not necessarily that they love it. However, it does indicate it's not problematic/disruptive enough for them to disable it, which is still positive.

However, I don't agree with @Tgr's statement, "That would mean users who enabled everything do not affect feature usage counts."

The top-line number of users using the feature is:

$total_using_feature_x = $total_explicitly_opted_into_feature_x + $total_users_with_automatic_enable_date_before_feature_x_launch_date_without_explicit_opt_out

Both of those figures are calculable:

$total_explicitly_opted_into_feature_x - This covers people with a 1 for that specific feature in the database. This is already kept track of. We just need to not increment this figure when someone is using a feature by virtue of "automatically enable".

$total_users_with_automatic_enable_date_before_feature_x_launch_date_without_explicit_opt_out - This can be calculated, either dynamically on every page view or on the job queue (not sure the performance requirements, but I know it can be done in SQL). It's basically a date comparison (a date for each user compared to a static date), plus a check that they don't have =0 for the feature (you can have automatically enable and still explicitly opt out to an individual feature).

In T64815#940393, @Tgr wrote:

As a horrible hack, one could set $wgDefaultUserOptions for each beta feature based on the auto-enable setting - 0 if it is off, 2 if it is on. That would make it possible to tell apart opted-in and defaulted-in users, and pave the path towards using tri-state checkboxes as well if we ever want to do that (generally a better way to handle on/off switches with a default state, IMO). The user would still have to visit Special:Preferences for the usage counts to be updated, though.

$wgDefaultUserOptions should not vary based on the current user's settings.

Quiddity updated the task description. (Show Details)Jun 14 2015, 7:12 PM
Quiddity set Security to None.

If this option was broken for a while, and suddenly started working at the launch of the next BF, I think editors may be surprised to really get a new feature now working for them, although they clearly expressed the choice to get it in the first place - it's just that not all the BF have the same visibility and impact on editors' habits.

Restricted Application added a subscriber: Luke081515. · View Herald TranscriptJan 19 2016, 3:01 PM
Mattflaschen-WMF updated the task description. (Show Details)
awight awarded a token.Aug 5 2017, 7:06 PM