Page MenuHomePhabricator

[SPIKE] What should feature management look like in desktop improvements?
Closed, ResolvedPublicSpike

Description

Background

We would like to be able to release individual feature for the desktop improvements project sequentially. We would also like the ability to feature flag each feature in order to make iteration easier and to make it possible to do a/b testing on selected features

Requirements

  • A/B testing
  • Retaining certain feature flags (does not need to be per-feature)
  • Ability to deploy per wiki
  • Ability to opt-out
  • Continued maintenance of legacy vector skin

Note: future ability to split into basic and advanced modes
Note: feature flag retention is so that we can maintain the ability to release portions to different wikis. By the end of the project, all feature flags will be removed. We are not expecting different configurations per wiki.

States

copying the table from the parent epic:

Feature StatusOpt-out buttonSetting
Anon, test wikionnonenone
Logged-in, test wikionyes, button in sidebarlegacy vector toggle turned off
Anon, non-test wikioffnonenone
Logged-in, non-test wikioffnonelegacy vector toggle turned on

Acceptance Criteria

Research, consult the team, and create a suggested structure for feature management in desktop improvements (must support A/B testing, SSR PHP + HTML + CSS + JS paths)
Investigate the following:

  • How do we separate code in vector?
  • Would this have any relation to BetaFeatures

Notes/questions from offsite

  • How can we grow the set of test wikis continuously? Who do we need to talk to in order for that to happen?
  • We should have a strategy on how to remove feature flags along with criteria for flag removal

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 7 2019, 12:35 PM
ovasileva triaged this task as High priority.Nov 7 2019, 12:35 PM
Masumrezarock100 changed the subtype of this task from "Task" to "Spike".Nov 7 2019, 12:54 PM
pmiazga claimed this task.Dec 3 2019, 6:10 PM
ovasileva updated the task description. (Show Details)Dec 4 2019, 1:47 PM
ovasileva updated the task description. (Show Details)
ovasileva updated the task description. (Show Details)
ovasileva updated the task description. (Show Details)Dec 4 2019, 1:50 PM
ovasileva updated the task description. (Show Details)Dec 4 2019, 1:59 PM

@pmiazga - added some of the relevant notes from the offsite conversation

Blocked on SuperHappyDevTime meeting

ovasileva updated the task description. (Show Details)Dec 4 2019, 6:33 PM
ovasileva updated the task description. (Show Details)

As a result of this spike we decided to submit an RFC. We would like to implement the Feature Management system in MediaWiki core as it's feels like a core feature that is required by multiple projects/teams.

  • MobileFrontend and Minerva uses the bespoke Feature Management system
  • Growth team is juggling multiple config flags and Feature Management could help simplify their system
  • Vector is another place where we want to enable/disable features in groups, thus Feature Management system looks like a best approach.

The spike can be closed once the RFC is posted.

@pmiazga - noting that we decided to create a separate task to track feature management within vector in the time between now and when the RfC is resolved.

phuedx claimed this task.Jan 20 2020, 6:06 PM

@pmiazga - noting that we decided to create a separate task to track feature management within vector in the time between now and when the RfC is resolved.

@polishdeveloper: Is there such a task?

@polishdeveloper: I'm happy to help out with this prior to the EOM January deadline.

phuedx added a comment.Feb 6 2020, 2:10 PM

I agree with @Niedzielski that the feature flagging system implemented in MobileFrontend should be ported to Vector immediately and refined as necessary whilst we're implementing features in Vector – @Niedzielski: Do correct me if I'm misrepresenting you here. I'll create a task that covers exactly that and no more /cc @ovasileva.

The following are a handful of things that I'd like to address soon after the port:

  • Remove the notion of groups from the system. AFAICT Feature#getGroup is only ever invoked in a unit test. Therefore, it only serves to increase entropy
  • Features are disabled by default by convention (and by construction). MobileFrontend's configuration can/should be tidied up

Separately, I'd like to consider implementing a human-readable syntax for configuring compound user modes in configuration, e.g.

extension.json
"MFFooFeature": {
  "beta power_user": true
}
PowerUserUserMode.php
class PowerUserUserMode implements IUserMode {

  /* ... */

  public function isEnabled() {
    return $this->user->getEditCount() > 1000;
  }
}
phuedx removed phuedx as the assignee of this task.Feb 6 2020, 2:12 PM
phuedx added a subscriber: phuedx.
nray added a comment.EditedFeb 6 2020, 4:53 PM

Remove the notion of groups from the system. AFAICT Feature#getGroup is only ever invoked in a unit test. Therefore, it only serves to increase entropy

I agree with removing getGroup from the IFeature interface as well as the getNameKey and getDescriptionKey methods (and the $group constructor arg). AFAICT these are only used for features that are displayed to the user on the SpecialMobileOptions` page but I think there are plenty of features that don't meet that criteria.

polishdeveloper added a comment.EditedFeb 6 2020, 4:53 PM

@phuedx, The Feature interface shouldn't define more things, definitely things that shouldn't be there are:

  • getGroup() - it is used to group MobileFrontend, Minerva, other features, no idea why we did that, it's used for translations now
  • getNameKey() - is using getName() and getGroup() do create a Feature name key for translations, used on MobileOptions to show each feature name, but most probably won't be used in DIP
  • getDescriptionKey() - similar to getNameKey(), but this one provides a short description of feature.

I would drop all three methods from Feature interface, and in cases where we need translations, we could provide some Adapter, sth like FMS/Language::getFeatureNameKey and FMS/Language::getFeatureDescriptionKey.

About the human readable syntax - it's teasing, but let me warn you that if we do that path, we will lose the magic of array merging, if a feature is enabled for wikipedias, then if you define a new key for example in plwiki, you'll have to define all features once again, where in the array approach, you just override the one you want.

phuedx added a comment.Feb 6 2020, 5:58 PM

I'll create a task that covers exactly that and no more /cc @ovasileva.

T244481: Provide basic FeatureManagement in Vector codebase is that task. Thanks @polishdeveloper!

phuedx closed this task as Resolved.Feb 6 2020, 5:58 PM
phuedx claimed this task.