Just adding a note more community feedback was added here:

It seems to me that the two designs need to be combined. Dashboard design is for the start page, and Accordion design is for when you go to manage a single extension

I'm adding designs here, but I don't think I'll close this task since we're back from holidays and can get an overall team opinion (+ one point on the Acceptance Criteria list is still not crossed out). Some things we may want to think about before resolving this:

• Which one of the two options for configuring a single feature do we want to implement?
• Do we think organizing by feature can work? Is this too WMF-centred? If yes, what are some other patterns by which we can organize this (e.g. activity: Editing, Reading?)?

Which one of the two options for configuring a single feature do we want to implement?

I think we need anchor links so it's easy to link to a specific section within the form. If that's not logical to do within the Accordion design, then I have a slight preference for the ToC design.

For either design I think there should be a Help link that navigates to:
https://www.mediawiki.org/wiki/Special:MyLanguage/Community_configuration_2.0
That way there is a clear place to learn more or ask questions.

Do we think organizing by feature can work? Is this too WMF-centred? If yes, what are some other patterns by which we can organize this (e.g. activity: Editing, Reading?)?

We might want to eventually organize into sections that are more user-centered, but perhaps that isn't needed for the initial release as there are unlikely to be more than a few menu options?

I added T354390: Community Configuration 2.0 dashboard as the follow-up engineering task for the dashboard view. Feel free to add/adjust the details and attach images to the task once the Figma designs are finalized.

In T350201#9430764, @KStoller-WMF wrote:

Do we think organizing by feature can work? Is this too WMF-centred? If yes, what are some other patterns by which we can organize this (e.g. activity: Editing, Reading?)?

We might want to eventually organize into sections that are more user-centered, but perhaps that isn't needed for the initial release as there are unlikely to be more than a few menu options?

One inconsistency in the current design is that "Growth features" stands for several features while the rest of elements (eg Edit check) are mapping to a single one. If the top taxonomy level is a single feature we should be listing Mentorship, Help Panel, Newcomer tasks, etc. We need to clarify what do we want each item in the list to represent, a feature or a group of features? We could also use the extension name as an entry point and mix or list out all configurable features from that extension.

Thanks, @Sgs, I discussed with Martin today and passed along feedback to @JFernandez-WMF via Figma. I'm suggesting the dashboard should be more feature-centric than extension-centric.

Growth features are all so interconnected, that it's still a bit of a judgment call about how to break them up, but I've suggested:

Mentorship (which will include Personalized Praise)
Homepage (which will include Help Panel)
Suggested Edits (which will include Leveling up)

Does that seem reasonable, or do you think we should break up features even further?

In T350201#9444032, @KStoller-WMF wrote:

Does that seem reasonable, or do you think we should break up features even further?

It seems reasonable, maybe Help panel could be factored out since users can enabled it without having the Homepage enabled.