Page MenuHomePhabricator

New WMF-deployed extensions should honor the "Exclude me from feature experiments" user preference
Closed, DeclinedPublic

Description

The current trend seems to be making MediaWiki software/Wikimedia Foundation websites more newbie-friendly, which is what I'm all for, but it should not interfere with power users' options.

Good recent examples of this are the PostEdit and Universal Language Selector extensions, both of which are deployed on MediaWiki.org at least (where I'm an admin) and both of which cannot be turned off without CSS/JS hackery. This in unacceptable in my opinion.

We have the "Exclude me from feature experiments" user preference, originally introduced by the WikiEditor extension, which at the time was a part of the UsabilityInitiative extension (which in turn no longer exists), so it would be nice if new extensions could honor this preference. Cache fragmentation is more than likely happening for power users with heavily customized preferences, so that's not a valid excuse in this case.


Version: unspecified
Severity: normal
Whiteboard: aklapper-moreinfo
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=46306

Details

Reference
bz45964

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:34 AM
bzimport set Reference to bz45964.

This bug also especially applies to enwp and anywhere else experiments are common, as such experiments are precisely what a user would expect such a preference to affect, along with the sort of thing that Jack brings up.

ULS is not an experiment, FWIW.

swalling wrote:

PostEdit is not a feature experiment any longer either. It's been deployed to quite a few projects in a permanent way.

When my team runs real feature experiments that hit experienced users, like the A/B test of Extension:LastModified we did some time ago, we do respect the opt-outs of the "Exclude me from feature experiments" preference. However, I'm not going to use that preference to suppress PostEdit or any other permanent product that I'm responsible for.

If it is specifically PostEdit that annoys you, and you think you can make a case where the majority of power users want to have PostEdit off, then we can talk about whether we should do that. But that's a separate bug than requesting dumping a bunch of disconnected "newbie" features under the label experimental.

(In reply to comment #0)

Good recent examples are PostEdit and Universal Language Selector

(In reply to comment #2)

ULS is not an experiment, FWIW.

(In reply to comment #3)

PostEdit is not a feature experiment any longer either.

Jack / Isarra: Any other examples of extensions than PostEdit and ULS?

Andre: Beyond what are apparently some aspects of Echo, nothing comes to mind, so perhaps it's better now than it has been.

And Steven, I see what you're saying, but please consider being more careful about your wording in the future, as wording things so personally like that can come across as somewhat condescending. Jack wanted to tell you some interesting things as a result and I wouldn't have stopped him, but he is fortunately better at restraining himself than I am at times.

(In reply to comment #0)

The current trend seems to be making MediaWiki software/Wikimedia Foundation
websites more newbie-friendly, which is what I'm all for, but it should not
interfere with power users' options.

Good recent examples of this are the PostEdit and Universal Language Selector
extensions, both of which are deployed on MediaWiki.org at least (where I'm
an admin) and both of which cannot be turned off without CSS/JS hackery. This
in unacceptable in my opinion.

Power users should not find it especially difficult to add a line to their Common.css user stylesheet, but I accept that they should not have to poke around code to figure out which rule to add. I made sure the requisite CSS code is featured prominently on the extension's page on mediawiki.org:

http://www.mediawiki.org/wiki/Extension:PostEdit#Disabling

I understand why you might think this is an inferior solution. The addition of an explicit preference doubles as a kind of implicit acknowledgement that the feature in question could be obtrusive or annoying to established users, and thus it expresses civility and respect, whereas a workaround does not.

But in this particular case, the change required is really very small, and probably does not take up much more time than hunting around for a preference. So I hope you will find it an adequate solution, if an imperfect one.

OK, I haven't heard back, so I'm closing this.

WONTFIX has the unfortunate tendency to come across as inflammatory or dismissive, so let me reiterate that I see this report as legitimate and useful.