@polishdeveloper: Sorry for the lack of context for the change above. There were/are a lot of good questions about the design of the feature management system (FMS) that emerged during review. Given the need to land an FMS in Vector soon, I proposed that we land the simplest version of your proposal that we could all agree on. Included in my patch is a list of steps that gets us from point A to what's described in this task.

@Niedzielski IIRC you said that you had experience with QAing EventLogging on the Beta Cluster and that you'd be willing to help @Edtadros QA this.

I'll add notes for @Edtadros.

@Edtadros: I can confirm that the patch has been deployed to all wikis.

☝️ @Jdlrobson I've left a question about the deprecation notice for wgMinervaCustomLogos not being shown in one scenario.

Prioritising this as Low as it's not work that must be done as part of Desktop Improvements.

CC Performance-Team. Whenever you can, I'd appreciate a review of this approach.

We estimated this as a large because there was some debate about how/where the CSS for the button should live.

Firstly, apologies for the late comment here.

Unlicking this 🍪 as T242381: Add a Vector skin version preference and T244481: Provide basic FeatureManagement in Vector codebase need attention.

In T244614#5885697, @Jdlrobson wrote:

<snip /> at least I'm not sure how to QA this other than verify the link is removed from the output HTML when it hits production

Neither config variable removed in https://gerrit.wikimedia.org/r/571560 are used anywhere other than WMF production 👍

In T196159#5885148, @Edtadros wrote:

@phuedx Can you confirm that the code has been removed in production as well please?

I'm moving this into Needs Code Review after a discussion with @ovasileva.

In T242381#5883635, @Niedzielski wrote:

• Questions to bounce with @phuedx:
  • Do you think I should add support for a "useskinversion" query parameter? This would kind of give us the ability to have URLs that are fully skin + version aware which I think would be very useful and may help with testing too. If so, should that be in the feature manager task, a new task, or somewhere else?

There's a minor nit from @Volker_E on https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/Vector/+/571841/.

I recommended that @Edtadros move this to Needs More Work as:

@Edtadros: To confirm, I can verify that the code has been removed from the codebase. That removal will be deployed to all Wikipedias tomorrow (Thursday, 13th February).

Per T214641#5861539, this is a technical change that has affected the UX of the categories overlay. It should go through design review.

Sorry for the noise @alexhollender!

Moved to Needs More Work as https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/MinervaNeue/+/551670/ is currently V-1.

As discussed:

If you don't mind, I'll address your minor points first followed by your major points.

Hey @nray! Is there anything else that needs review?

My recommendation is option 3 from T243281#5860154. I see the performance impact and incidental complexity being far outweighed by the UX of the button being usable for everyone immediately. In the common/best case, instrumentation is also free.

I mention "array manipulation" above as a negative. To clarify, I mean that since the sidebar is internally represented as an array (strictly, an array with keys that are strings… map-ish), we must manipulate it directly in a hook handler. For those playing along, we're binding to two protocols: the hook (when and how it's run); and the keys of the array that represents the sidebar. However, I believe that at least the former's modification/deprecation are governed by MediaWiki's deprecation policy and that the latter woud be unlikely to change as it's the name of a system message.

Things we know:

hasSet( $setName, IContextSource ) to check if has access (granted and/or enabled by himself ) to given set

@Edtadros: I'm not sure how to handle removal of code. If you'd like to talk about it for 10 minutes, then LMK. Would

☝️ The above could be deployed during the morning or evening SWAT deployment windows.

Once code is removed, please add a note on the Schema:Print documentation page and also mark the schema as inactive. Just add status=inactive to schema definition

In T237635#5856174, @phuedx wrote:

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

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.

In T238029#5819088, @SBisson wrote:

A very special thanks to @phuedx for reviewing and merging the patch!!

As discussed, this isn't blocked on T210106: Provide a reusable getEditCountBucket function for analytics purposes.

The suggested fix is inline (pun intended) with the treatment for the desktop diff 👍

As I said during my review, we should standardise on quoting styles for the *stories.js* files rather than allow a free-for-all. Storybook stories are no different from the other parts of the codebase.

FWIW I support this request.

Related to this, on https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileDiff/411429 the move paragraph doesn't seem to match the mocks in T197491 anymore.

@Jdlrobson: Can this be tested on the beta cluster?

@Jdlrobson: There's an open question on https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/MinervaNeue/+/566105/ from both @nray and me.

I submitted the above change as a proof of concept for an approach that would allow us to centralise the user edit count bucketer in WikimediaEvents while not requiring that repositories bind to some API (requiring a hard dependency).

The Readers Web side of the conversation has been revived since we opened T243071: Update PrefUpdate schema to include edit count . I submitted the above change as a proof of concept for an approach that would allow us to centralise the user edit count bucketer in WikimediaEvents while not requiring that repositories bind to some API (requiring a hard dependency).

I think there's a solid case for migrating the user edit count bucketing code from the clients (see below) to the server. I think that there's a case to be made for putting User#getEditCountBucket in Core, WikimediaEvents, and EventLogging.

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

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.