Page MenuHomePhabricator

BetaFeatures: Show a count of users who have enabled and then disabled a given Beta Feature
Open, MediumPublicFeature

Description

5,169 users have enabled this feature. <-- current

5,169 users have enabled this feature.<-- proposed
7,830 users have tried this feature.

Allow users to see how many users total have tried out a beta feature (turned on, then disabled.)


Version: unspecified
Severity: enhancement

Details

Reference
bz60012

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:51 AM
bzimport set Reference to bz60012.
bzimport added a subscriber: Unknown Object (MLST).

We do not currently have these numbers, will require a schema change.

For more detail: Add a column to the user counts table and just add one to it whenever someone enables a feature. No other computation necessary.

You should probably have a conditional SQL statement that sets the initial value to the current value of the people who have it enabled.

If the same user enabled and disabled over and over we'd want this not to affect the "tried" value

Agh.

OK, in that case we may need a separate table. I don't like that option, though...updating a different set of counts with yet another job sounds like it would be nasty.

I'll +1 that change but I'll want review from someone more tied into performance etc.

Any way we do this, a schema change is needed.

My idea: set a "sticky" preference when a user enables a beta feature ("$key-set"), but don't remove it when the user changes the option. Then we just count the number of people with that set and store it in another column in the table.

We'd also need a maintenance script to set all the rows for people who currently have a BF turned on (can't get data for people who already turned it off).

(In reply to comment #5)

We'd also need a maintenance script to set all the rows for people who
currently have a BF turned on (can't get data for people who already turned
it off).

We could probably retrieve the information from the preference changes EventLogging system if we wanted to…

anboia wrote:

(In reply to Kunal Mehta (Legoktm) from comment #5)

My idea: set a "sticky" preference when a user enables a beta feature
("$key-set"), but don't remove it when the user changes the option. Then we
just count the number of people with that set and store it in another column
in the table.

When a user enables a beta feature, this feature is added on the 'user_properties' table, but when the user disable that feature, it is not removed from the table, just change its value (up_value) from 1 to 0.. which means that all we have to do is the same we do to count enabled features.
Instead of 'where up_value=1' should use 'where up_value=0' on the select command, but I'm not sure if there is a way to take this two values(enabled, disabled) in one select command(with maybe a join) or another way..

We'd also need a maintenance script to set all the rows for people who
currently have a BF turned on (can't get data for people who already turned
it off).

this mean we 'can get data for people who already turned it off'...

anboia wrote:

can I work on this?

Of course - no need to ask. :)
Sharing an early patch on Gerrit for review is welcome!

(In reply to Andre Saboia from comment #7)

(In reply to Kunal Mehta (Legoktm) from comment #5)

My idea: set a "sticky" preference when a user enables a beta feature
("$key-set"), but don't remove it when the user changes the option. Then we
just count the number of people with that set and store it in another column
in the table.

When a user enables a beta feature, this feature is added on the
'user_properties' table, but when the user disable that feature, it is not
removed from the table, just change its value (up_value) from 1 to 0.. which
means that all we have to do is the same we do to count enabled features.
Instead of 'where up_value=1' should use 'where up_value=0' on the select
command, but I'm not sure if there is a way to take this two values(enabled,
disabled) in one select command(with maybe a join) or another way..

Are you sure that's true? MediaWiki rather aggressively removes unnecessary data from this table, including preference values that are identical to defaults.

anboia wrote:

(In reply to Bartosz Dziewoński from comment #10)

Are you sure that's true? MediaWiki rather aggressively removes unnecessary
data from this table, including preference values that are identical to
defaults.

yeah, now I see.. I'm not sure.. I think, for some reason, this was happening only with the multimedia-viewer extension.

This needs to clearly specify how this feature request relates to "Automatically enable all new beta features" (which currently does not do what it says on the tin; see T64815: BetaFeatures: "Automatically enable ..." should actually automatically enable, not require visiting Special:Preferences).

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 12:23 PM