In T323811#9100916, @Soda wrote:

It would be interesting to look into integrating this into certain areas of ProofreadPage (maybe Pagelist widget ?) :)

Thanks for the additional ideas, @Soda. I've added ProofreadPage to the list of possible usecases.

Any extension that depends on local templates would be a good candidate. For example, Move-Files-To-Commons (currently FileImporter loads data from mw:Extension:FileImporter/Data subpages; with Community configuration 2.0, FileImporter would need to load data from FileExporter, and FileExporter would need to implement community configuration).

WikiLove customization could also be easier if one didn’t have to write JS code but could use a user-friendly interface.

Another use case: T330354: [Goal] Build the Metrics Platform control plane

Design doc

cc @cjming @phuedx @WDoranWMF @Milimetric @mforns

In T323811#9281708, @Ottomata wrote:

Another use case: T330354: [Goal] Build the Metrics Platform control plane

Thanks! I've added this idea to the list of use cases in the task description.

There should be a review of all existing configuration options with a default presumption they be included in community configuration, unless there is a clear reason why an Administrator carrying out community consensus cannot or should not be able to directly access that configuration item.

This would have avoided many instances of friction and distrust between the WMF and community in the past, and it would go a long way towards building trust and collaboration for the future. I don't want to get sidetracked on past incidents, but community configuration would have been infinitely preferable to needing to escalate an issue to the Executive director and weeks of drama and multiple communities to writing hacks to the site-wide-javascript, just to make an UNDISPUTED-FIX to a simple configuration item which the Foundation itself says was changed in error.

For configuration items with binary or enumerated options (i.e. excluding free text values), it would be good if the configuration page showed how many wikis were configured each way. The administrator should be able to see if he attempting to switch away from the dominant configuration, which should usually only be done for good reason with careful consideration. And if I can wish for additional info, I'd like to also see that info but weighted by active editors on each wiki. If the dozen largest wikis are using a certain configuration option, then that is almost certainly the "dominant" or "most appropriate" option unless the other option is beneficial specifically for small wikis.

In T323811#9497668, @Alsee wrote:

There should be a review of all existing configuration options with a default presumption they be included in community configuration, unless there is a clear reason why an Administrator carrying out community consensus cannot or should not be able to directly access that configuration item.

This would have avoided many instances of friction and distrust between the WMF and community in the past, and it would go a long way towards building trust and collaboration for the future. I don't want to get sidetracked on past incidents, but community configuration would have been infinitely preferable to needing to escalate an issue to the Executive director and weeks of drama and multiple communities to writing hacks to the site-wide-javascript, just to make an UNDISPUTED-FIX to a simple configuration item which the Foundation itself says was changed in error.

Thank you for the feedback, @Alsee ! I hope that Community Configuration can be used to shift more configuration control to communities, and I totally agree that if implemented sensibly it could help reduce the friction between WMF and communities.

The Growth team (the WMF team that focuses on building features to help onboard new editors) is committed to making Community Configuration available for wider use. We've found the Growth version of Community Configuration (Special:EditGrowthConfig) to be very powerful and appreciated by communities, so we are working to make it available for other MediaWiki developers. We also plan to work with a few other WMF teams to help them get started and ensure the guidelines and developer documentation are easy to understand.
The current scope of this Epic does not include a review of all existing configuration options. That would truly be a huge project, and we want to start small, with the possibility to expand in the future

For configuration items with binary or enumerated options (i.e. excluding free text values), it would be good if the configuration page showed how many wikis were configured each way.

This is an excellent insight! We actually had a similar idea mocked up for the Community Configuration dashboard originally. We realized it might not scale well for the dashboard view, but perhaps it makes sense for the individual Community Configuration form. I'll follow up with the Growth team designer to see if this is something we could incorporate.

The administrator should be able to see if he attempting to switch away from the dominant configuration, which should usually only be done for good reason with careful consideration.

I guess one concern I have is that if communities are reluctant to enable features that are not enabled on many wikis, that might lead to a future in which communities are reluctant to ever enable a new feature. How can we ensure Community Configuration isn't used to totally resist innovation and change?

Do you still want to use opis/json-schema (if it's upgraded)?

WikiLambda has stopped using it, so that removes the blocker to upgrading...

But if you don't want to use it (at least, not any time soon), we can drop it from vendor...