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.

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.

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.

Change 749866 had a related patch set uploaded (by Func; author: Func):

[mediawiki/extensions/BetaFeatures@master] [WIP] Change auto-enroll logic to soft enroll which don't need database write

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

Change 784777 had a related patch set uploaded (by Seb35; author: Seb35):

[mediawiki/extensions/BetaFeatures@master] Change auto-enroll logic to soft enroll which don't need database write

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