Hi @Sgs @KStoller-WMF @DMburugu @Michael @Cyndymediawiksim, do you have any objections with declaring CommunityConfiguration to be stable?

Beta doesn't seem appropriate, I agree that it makes sense to mark CommunityConfiguration as stable.

We should definitely mark this as stable since we have enough production use cases which have had no issues over the past 6 months.

I do acknowledge there are development experience areas such as documentation that can be improved to better capture various ways of working and extending the internals of CC 2.0 though those can be worked on as improvements.

After a discussion with @Sgs, I've moving this into our Backlog with the expectation that we can make this change in March when we can devote more time on Community Configuration.

The definition for stable from extension status is a bit loose and does not use beta/production as a discriminator. These tasks seem relevant to what's mentioned there:

• T384184: Only use GrowthExperimentsServices::getWikiConfig to request configuration variables registered in community configuration, does the latest proposal entail a breaking change given MediaWikiConfigReader usage is already spread? (See usages )
• T371028: Migration Schemas to a non-latest version is broken is not warned in our docs and could be a miss-expectation

This doesn't feel accurate, as it is deployed to all Wikipedia projects already (and soon to be deployed to non-Wikipedias as well).

That seems to be true for some things that are seemingly in perpetual beta, e.g. OOJS-UI is still at 0.51.5. On the other hand, Codex is at 1.20.1.

For me, this would include deciding which classes should be considered stable and not be changing without being deprecated first. And those should probably be the only ones that should show up in our documentation.