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

Blocked on SuperHappyDevTime meeting

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.

RFC is available here T242835: RFC: Standard method for feature-management in skins/extensions - moving to ready for sign off

@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.

In T237635#5812751, @ovasileva wrote:

@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 please check the T244481: Provide basic FeatureManagement in Vector codebase

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.

"MFFooFeature": {
  "beta power_user": true
}

class PowerUserUserMode implements IUserMode {

  /* ... */

  public function isEnabled() {
    return $this->user->getEditCount() > 1000;
  }
}

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.

@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.

In T237635#5856174, @phuedx wrote:

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!