May 15 2020
Great work @phuedx
LGTM, Signing off
May 13 2020
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.
May 11 2020
Apr 13 2020
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
Apr 8 2020
Is there anything I can help with to push this RFC forward?
Mar 31 2020
Mar 23 2020
Mar 13 2020
Mar 3 2020
I'm more than happy to join any meetings, explain the idea behind Feature Management and try to answer all questions.
Mar 2 2020
@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 ).
Feb 28 2020
@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"
Feb 27 2020
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 ?
Feb 26 2020
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.
Feb 14 2020
Feb 11 2020
@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.
Feb 10 2020
Feb 8 2020
Feb 7 2020
@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:
Feb 6 2020
@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
Feb 4 2020
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.
Jan 31 2020
Jan 29 2020
@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?
Jan 24 2020
@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.
Jan 22 2020
Jan 21 2020
@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.
Jan 17 2020
The code for PrefUpdate lives in WikimediaEventsHooks::onUserSaveOptions file. To achieve this goal we need to:
Jan 16 2020
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:
Jan 15 2020
RFC is available here T242835: RFC: Standard method for feature-management in skins/extensions - moving to ready for sign off
Jan 13 2020
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.