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:
- 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)).
- Store the date each beta feature was launched (may very by wiki) in config.
- 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
Subject Repo Branch Lines +/- Change auto-enroll logic to soft enroll which don't need database write • Mattflaschen-WMF added a comment.Oct 3 2014, 4:41 AMComment ActionsIdea:
- Keep track of date "Automatically enable..." was set to "yes" in a hidden preference/somewhere.
- Store the date each beta feature was launched (may very by wiki) in config.
- 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).
Comment Actions
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.
• Mattflaschen-WMF added a comment.Jan 13 2015, 2:49 AMComment ActionsSmart metrics would distinguish between:
- Active users who opted into a specific feature.
- Inactive users (haven't edited recently, maybe haven't even logged in recently) who opt-ed into a specific feature.
- Active users who opted into the general "automatic enable" and are thus using your feature (haven't specifically opted out of that individual feature)
- 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).
$wgDefaultUserOptions should not vary based on the current user's settings.
- Reference
- bz62815
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Change auto-enroll logic to soft enroll which don't need database write | • Mattflaschen-WMF added a comment.Oct 3 2014, 4:41 AM Comment ActionsIdea:
Comment Actions 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. • Mattflaschen-WMF added a comment.Jan 13 2015, 2:49 AM Comment ActionsSmart metrics would distinguish between:
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). $wgDefaultUserOptions should not vary based on the current user's settings. |
)){kind=link}