Reviewed and merged, @Jdlrobson can you take over?

@Jdlrobson can you add QA steps?

thank you

@Yash4357 Your core patch got merged. Are you interested improving the MobileFrontend by using this interface?

I'll look into it today. Sorry to keep you waiting

Pushed the smallest/simplest change to get this task done. Menu handling still requires some small refactoring but that can be a part of different task.

Yes, definitely. Happy to help. Thank you for the ping @Jdlrobson .

I see some action in phab, give me this week to push what I have so far.

It looks like there is lots of old/outdated documentation as most of the stuff was migrated to MinervaNeue and MobileFrontend is currently not involved in building Menu for minerva.
https://doc.wikimedia.org/mediawiki-core/master/php/MobileMenuHook_8php.html -> is missing as we do not have interface for that MobileMenu, it's part of Minerva, not core.

data-mw="interface" definitely should stay. And on top of that we should use something else instead of #pt-logout, also I don't see real value in wrapping elements menu elements with additional wrappers, so we would have to search for element that has both classname and data-mw element. Something like .menu a[data-mw=interface][class*=menu__item--logout] should do the job. I'll create a patch.

Ok, so a short summary of my struggles

I'm still going to push the fix for that, but after ~4 months not working on MediaWiki code literally nothing works and the only solution is to drop entire repo and start it from scratch again. I struggled to get my env working again with everything what I had on the weekend but after couple hours I surrended.

let me pick that, it should be simple and straightforward ;)

I vote for 1 - Minerva being compatible with what core/vector provides. Adding support for MenuEntries shouldn't be a problem ( id's are already supported, you can pass those as an attribute when creating a component).

The PDF print service is not aware of any user/user preferences. It prints all articles as anon user. Therefore - when a logged in user asks to print page with some special option, then it's exactly as @Jdlrobson says:

Proton uses puppeteer node library to tell chrome (that is running in headless mode) to do things. What we currently do is that we tell chrome to open a Wikipedia page, and call window.print() and print to PDF. It behaves almost the same way as someone going to Wikipedia on their desktop and clicking "Print" and then pick "PDF" as output. It doesn't use Parsoid output (at least at the time of implementation) as there were differences in styles for mobile pages.

Great work @phuedx

LGTM, Signing off

I'm on it, I should sign it off by end of today - so far it looks good but I want to verify couple more things.

Just to make this topic easier to process - what we want to achieve is easily accessible "Feature Toggles" that can be used anywhere in the MediaWiki land. For more information please read https://martinfowler.com/articles/feature-toggles.html

I can work on it

Is there anything I can help with to push this RFC forward?

I'm more than happy to join any meetings, explain the idea behind Feature Management and try to answer all questions.

@Jdlrobson - pmiazga was the account I was using earlier, now it's @polishdeveloper :). Also, I'll create another task for other skins plus changes required in mwcore ( adding deprecation for $data property in QuickTemplate ).

@Jdlrobson - yeah, we could add a default value of empty string. The only concern I have is that if someone makes a typo and tries to text( 'unknown' ) it would still work but with empty string - this can cause problems when debugging stuff. Maybe we could do sth like that"

Thank you @MarcoAurelio. Just to verify, am I getting +2 rights for both MWCore and extensions/skins or do I have to submit another ticket and specify the list of skins/extensions I'm working on ?

yes, but I don't think it should go to Backlog, as backlog is mostly for code-related tasks and this one is about permissions/way to access slack.

I would go even further, and I would make:

@Aklapper sorry, but I have no idea on how to tag this task, could you help?

@Tgr yes, so in this idea you would have - the UserMode called ( GrowthCommunityMemeber ).
Then you would have multiple features, that are not available to any mode, only to growthCommunityMemeber. Once User opts into growthCommunityMember (or someone opt's that person) user will get all features available on that mode.

@Jdlrobson why not use hooks? It doesn't introduce tech deb, you define new Hook called sth like PopupsInitialization, and allow other extensions to listen to that hook and returm false. See https://phabricator.wikimedia.org/T236097#5809640
IMHO it's much cleaner approach and it doesn't introduce any tech debt. What more, if there is any other Popups like extension, it will be also able to easily disable PagePreviews so it doesn't conflict.

@phuedx yeah, I agree, the ISet is pretty problematic, I spent some time ago thinking on it, and my idea is that we could define sets of features per context. So for example, the mode could be:

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

@phuedx please check the T244481: Provide basic FeatureManagement in Vector codebase

I'm not sure, pmiazga account has many permissions and I if I remember right I was using the PMiazga (WMF) mediawiki account, it's just easier to grant only contributor permissions to the new account.

@Krinkle I'd like to follow-up on what I wrote earlier. I checked with Readers Web, and we agreed that we currently maintain the Feature Management in MobileFrontend. We're going to do something similar in Vector, therefore we will have to maintain it also in Vector. Therefore there is no difference for us between maintaining it in MobileFrontend/Vector or maintaining it in the MediaWiki Core.

@Jdlrobson can you add QA steps and move it to needs QA?

@Krinkle I don't think there is a roadmap/stewardship in place for this project. We found a need for such solution, I also did a quick research and looks like other teams are facing similar problems as we start to feature flag and A/B test many things. This is an idea to centralize the common requirement we, Readers Web have (maintaining multiple modes) and make it handy for other teams. I can definitely help with maintaining such project in my volunteer time.

@phuedx I already tried to do that and there was lack of agreement on where to put the getEditCountBucket method. Please check T210106: Provide a reusable getEditCountBucket function for analytics purposes, there is a patch that adds this function on the JS side, but we abandoned that work.

The code for PrefUpdate lives in WikimediaEventsHooks::onUserSaveOptions file. To achieve this goal we need to:

• edit the Schema:PrefUpdate wiki page and add edit count bucket
• (SEE NOTE BELOW) edit the WikimediaEventsHooks and bump the schema revision
• edit the $commonData array and add new editCount bucket

On the backend side we could use the Hooks system to allow other extensions to disable PagePreviews. The code would look like sth like that:

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

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.