Is there anything I can work on as a non-tech person, to help move this idea forward? Or are there meaningful subtasks, so that we can perhaps break it up into easier pieces?

I believe @jeremyb is going to take a shot at implementing this.

I guess the idea is to dynamically set i.e. wgWikiProjects? Because we definitely don't want to have to maintain a $wg variable. Creating new WikiProjects should not require developer intervention.

I still wonder about the performance impact versus benefits. What is setting wgWikiProjects – the server or the CentralNotice code? If the former, this will presumably get set for all users. Everything accessible via mw.config.get increases the size of the JS payload. if only a small percentage of those users are making use of the $wg variables, it may put into question whether it's really worth it. Remember that at scale, a tiny bit of JS is amplified times however many millions… this can mean huge data transfer rates at scale that result in real-world CO2 emissions, etc.

But I see Lego is endorsing this so I assume he's thought it through and deemed this not a problem :)

Am I missing something, surely a config variable for WikiProjects would only take a byte or two, and wouldn't have to be updated very often at all?

Sorry for the newbie-style question; when you say "increases the size of the JS payload" are we concerned with processing time or amount of data? I'm wondering if some sort of hash or abbreviation would be helpful - I'm not entirely sure that the impact of a collision would be that high?

Also, how to interpret "only a small percentage of those users are making use of the $wg variables" seems variable - the use case I was told about was to display targeted banners for people viewing pages associated with certain projects - arguably the benefit would be not spamming the majority of users with banners that they don't care about. However, at most times there aren't targeted banners like that - but maybe it is a compelling use case?

I assume there's no reasonable way to set a flag in an actual withproject that would somehow propagate a special flag up via $wg?

It'd be nice to come up with a solution that requires the least maintenance from anybody (i.e. not a hack).

Just listing a couple hepful use cases I can think of in my world:

• Through CentralNotice, this could be particularly helpful for photo campaigns like Wiki Loves Monuments. With a number of photo campaigns happening throughout the year, some users have complained that the banners promoting these photo campaigns are too frequent (and I believe photo campaign banner visibility has been reduced in the last few years because of it). Being able to target topic areas could be beneficial (e.g. increasing visibility of Wiki Loves Monuments US banners to articles under WikiProject National Register of Historic Places).
• Some citation highlighting tools (e.g. Headbomb's UPSD or my own Cite Unseen) mark up citations based on their reliability. Some WikiProjects have their own lists of what sources are reliable or unreliable (e.g. WikiProject Video Games). It's potentially useful for these tools to know when an article falls under a WikiProject so that its respective source reliability list can be applied.

In T374761#10219429, @MusikAnimal wrote:

I guess the idea is to dynamically set i.e. wgWikiProjects? Because we definitely don't want to have to maintain a $wg variable. Creating new WikiProjects should not require developer intervention.

What is setting wgWikiProjects – the server or the CentralNotice code? If the former, this will presumably get set for all users. Everything accessible via mw.config.get increases the size of the JS payload.

My proposal is to set via the server, I assume a hook in PageAssesments extension just queries the table (wrapped via a cache I assume) and then adds it to the page variables.

if only a small percentage of those users are making use of the $wg variables, it may put into question whether it's really worth it. Remember that at scale, a tiny bit of JS is amplified times however many millions… this can mean huge data transfer rates at scale that result in real-world CO2 emissions, etc.

I'd argue:

• The increase is quite small.
• With better CDN infra and generally better internet infrastructure these days, we can allow this, it'd be quite small compared to streaming, tiktok or any other major player.
• This can simplify a lot of gadgets and frontend code so instead of looking up the projects via API calls or other gymnastics, it just reads it directly.
• This would unblock a lot of innovation in this area, some have been mentioned here but I think there will be more.

In T374761#10603337, @Ladsgroup wrote:

In T374761#10219429, @MusikAnimal wrote:

if only a small percentage of those users are making use of the $wg variables, it may put into question whether it's really worth it. Remember that at scale, a tiny bit of JS is amplified times however many millions… this can mean huge data transfer rates at scale that result in real-world CO2 emissions, etc.

I'd argue:

• The increase is quite small.
• With better CDN infra and generally better internet infrastructure these days, we can allow this, it'd be quite small compared to streaming, tiktok or any other major player.
• This can simplify a lot of gadgets and frontend code so instead of looking up the projects via API calls or other gymnastics, it just reads it directly.
• This would unblock a lot of innovation in this area, some have been mentioned here but I think there will be more.

If we've got you and Lego endorsing it, by all means disregard my concerns :)

I don't have time to work on this task but I'm happy to assist with code review.