Talk:Community configuration

July 2023 - initial thoughts regarding Community configuration 2.0

The Growth team plans to create a Community Configuration 2.0, based on Special:EditGrowthConfig.

This new feature will allow local administrators to change settings for Wikimedia Foundation-designed features. This way, they can configure the different features to best suit their wiki’s specific needs. This strategy eliminates the technical barrier for admins, to customize local settings. This also encourages a more inclusive and collaborative product development process.

This configuration page is visible to anyone, but only a selected group of users can edit it and configure Growth features

But, there are currently two primary limitations to Community Configuration:

• Discoverability: Many Administrators are unaware of the existence of Community Configuration.
• Usage Scope: At present, only the Growth features can use Community Configuration.

We plan to integrate Community configuration into MediaWiki, as a default feature. Other Wikimedia Foundation teams and volunteer developers will be able to create Community configurable features. We expect this central place to be more discoverable.

Before the Growth team starts this project, we are seeking feedback, to guide our efforts in the right direction. We are particularly interested in your thoughts on the following:

1. How do you feel about more Wikimedia Foundation features that can be configured (enabled, disabled, edited) by Administrators?
   • Do you have any reservations or concerns about this idea?
2. What can we do to ensure that all Administrators are well-informed about Community Configuration?
3. How confident are Administrators in making changes using Community Configuration?
4. Based on your experience editing Special:EditGrowthConfig, are any parts of the procedure unclear or ambiguous?
5. Community Configuration should be visible to all. Should it only be modifiable by a select group of experienced Wikimedians?
6. Should all configuration options be only editable by Administrators and interface administrators?
   • Should we consider different user access levels for certain configuration options?
7. Out of curiosity, do you have any thoughts on how many edits would be made to this community configuration page each year?

Your insights will be invaluable in shaping the trajectory of this project. We look forward to your constructive feedback! Trizek (WMF) (talk) 16:49, 18 July 2023 (UTC)

I just wanted to add a note to mention that we posted this message on the Talk page of several admins who had recently edited Growth's Community Configuration via Special:EditGrowthConfig.

The Growth team reviewed all feedback, and compiled a short summary of feedback here: Community configuration 2.0#Wiki communities.

That being said, we of course welcome any further feedback anyone wants to add here.  :) Thanks! KStoller-WMF (talk) 22:32, 27 October 2023 (UTC)

Community Configuration 2.0 - setting project goals

Hello User:Novem_Linguae, User:Sohom_Datta, User:Pppery, User:Matěj_Suchánek, User:SD0001, and User:ArielGlenn! The Growth team will start work on the Community Configuration 2.0 project soon, and we would love to have your feedback about the goals the Growth team is setting.  Each of you have shown some level of interest in this project, by adding ideas or following the related Phabricator task: T323811, so hopefully this request for feedback doesn’t seem totally random! We are hoping to set this project's goals in collaboration with the community, so that's why I'm reaching out to you.

Unlike most projects the Growth team works on, we can’t A/B test Community Configuration in a meaningful way, and it’s a challenge to measure the success or impact of Community Configuration for a variety of reasons.  But clearly we need some specific goals for this project! Here are our draft goals:

1. By the end of March 2024, Growth features will utilize Community Configuration 2.0.
2. By the end of June 2024, at least one other WMF team in Product and Technology has either launched or is in the active development stage for a project that is using Community Configuration 2.0.
3. By the end of June 2024, Community Configuration 2.0 has been used to customize at least 20 wikis. In other words, editors with extended rights are aware of and utilize Community Configuration.
4. By the end of June 2024, initial guidelines for the types of functionality that should and should not be in Community Configuration, and types of user rights that can adjust Community Configuration, will be agreed on in consultation and collaboration with volunteers and interested product teams.

To be clear, these are the short-term goals that relate to just the next 10 months (and the current WMF annual plan).  Long term, we hope that Community Configuration supports a wide range of features, extensions, and use cases.  Also I should mention we will have a wider discussion with technical stakeholders soon to cover the actual technical implementation details (T344144), and we’ll share designs and prototypes soon, but first we want to finalize the project goals!

If you have the time, I’m interested in feedback on these questions:

• Do you have ideas for how we can ensure Community Configuration is a tool admins know about and utilize when needed?
• Are there any changes we should make to any of these goals?  Or are there additional project goals we should add?

Thank you in advance for any feedback!  And please ping any other volunteers that may be interested in providing feedback on this project, or post the link to this discussion in other channels that might include interested stakeholders.  Thank you! - KStoller-WMF (talk) 19:43, 22 September 2023 (UTC)

Do you have ideas for how we can ensure Community Configuration is a tool admins know about and utilize when needed?

Certain special pages/actions (Special:Upload, Special:MovePage, action=delete etc.) have links to MediaWiki pages defining <select> menu items if the current user is allowed to edit the MediaWiki page. Similar links could be added for Community Configuration 2.0 if it’s used to configure something that can provide a link (e.g. Special:HomePage and/or Special:MentorDashboard from Community Configuration 1.0 could have such a link); however, many of the things listed in T323811 don’t have room for these links (e.g. there’s no place for an extra link around the site logo).

Of course, having them listed at Special:SpecialPages is a must-have, although I’m not sure how many admins check back regularly to see if there’s something new there, and it’s also already a bit crowded. —Tacsipacsi (talk) 11:34, 24 September 2023 (UTC)

Thank you, @Tacsipacsi, this is a great feedback. These ideas all seem like logical ways to help surface the availability of Community configuration! KStoller-WMF (talk) 19:14, 13 October 2023 (UTC)

@Novem Linguae, @Sohom Datta, @Pppery, @Matěj_Suchánek, @SD0001, @ArielGlenn, @Tacsipacsi:

Accordion design for Community Configuration 2.0

Here are some initial design ideas for how we could make the new Community Configuration 2.0 form more scalable and user-friendly. For comparison, the current form is here: Special:EditGrowthConfig.

Dashboard design for Community Configuration 2.0

A few things worth mentioning:

• These designs are using the GrowthExperiments extension configuration options as an example. We will likely still need a Special page or separate dashboard to easily access any configuration page as Community Configuration is adopted more widely.
• That header image is a placeholder and will eventually be replaced with an image that better represents Community Configuration.

If you have a moment, I would love to hear feedback on:

1. Which design do you prefer, the Accordion approach or the Dashboard approach?
2. Do you have any feedback about the onboarding at top? Do you think there are other questions we should attempt to answer in that section?
3. We will be conducting a few prototype walk-throughs with interactive versions of these designs. Are you interested in being part of one of those walk-throughs? (It would be a private, 1-on-1 chat with a fantastic design researcher who works with the Growth team).

Thanks in advance for anyone who has feedback on these designs or the project goals I mentioned above! — KStoller-WMF (talk) 19:43, 13 October 2023 (UTC)

I visually like the accordion better, but I like that the dashboard design highlights more information without clicking anywhere, so all in all, I prefer the dashboard. —Tacsipacsi (talk) 06:41, 16 October 2023 (UTC)

1. I slightly prefer accordion. One is able to scan it linearly instead of in a zigzag pattern. I'd recommend "expand all" and "collapse all" links at the top in case folks want to view everything or do a ctrl-F search.
2. I would recommend removing the giant image from the onboarding. That is taking up a lot of screen real estate. I'd slightly prefer removing the 3 sales pitch tiles, or replacing them less with sales pitch stuff and more with practical tips, although if these stayed I could live with it :)
3. Not at this time. Busy with day job for awhile, low bandwidth. Happy to respond to pings though.

–Novem Linguae (talk) 14:39, 16 October 2023 (UTC)

• Definitely the accordion, while the dashboard style might expose more information, most of the time, the usecase will be to modify one specific section/setting and having a lot of information in this context can be both overwhelming and introduce more chances of errenously modifying unrelated data. A interface to search for specific configurations would be a great addition.
• I agree with @Novem Linguae here, the giant graphic isn't really required and is somewhat misleading in that it shows a theme of communication rather than a theme of customizing technical configurations for one's wiki. That being said, besides the first tile (which does seems sales pitchy), the second and third tile are good advice and should be kept. In fact, I would suggest tightening up the wording of the second tile to make it clear that consensus and previewing are not optional, but rather a necessity when making these kinds of user-facing configuration changes.
• I would be up for that post next week :)
• Additional feedback: I think two things that I would wanted to have seen are:

• The ability/requirement of providing a reason/link to consensus for each such setting change.
• A clear way of denoting which editor last changed these settings (and when+why)

Sohom Datta (talk) 11:28, 20 October 2023 (UTC)

Thank you for the feedback, Sohom Datta, Novem Linguae, and Tacsipacsi!

I agree that the header image needs to be smaller or removed entirely (the current image is just meant to be a placeholder, so it especially seems out of place). Do you think we should consider having a smaller image that represents the feature that the configuration page relates to, rather than a Community Configuration-specific image? For example, perhaps Edit Check and other VisualEditor features that are configurable would have the VisualEditor logo in the header. Does that seem more applicable, or still like a waste of space?

@Sohom Datta, your feedback about the onboarding tiles was almost exactly what I discussed with Growth's designer yesterday, so I'm glad to hear I'm on the right track. We'll work on revising that first onboarding language to make sure it's helpful and not just "selling" the feature. Let me know if there is any other vital bit of onboarding that you think all viewers of the page should know. I wonder if we should include something that clarifies that the page is visible to everyone, but only editable by admins?

The new Community Configuration form will have an edit summary, and I think we should include language to encourage admins to link to the discussion where consensus was reached about making the change. I'll follow up with our designer about that.

A full edit history will be available to clearly show who made a change, when the change was made, and hopefully the edit summary will include the why. But I think we could improve the design by ensuring there is an easy way to view the last edit and navigate to the full edit history. I'll make sure we update designs to include that.

Currently Special:EditGrowthConfig includes a short summary at top, that looks something like:

MediaWiki:GrowthExperimentsConfig.json: Last updated by [username] [timestamp] [(diff)].

I think we could improve the layout to differentiate that info from the rest of the form, but I agree that something like that is needed.

Thanks again everyone for the feedback! We won't start engineering work on the Community Configuration form for another few weeks, so there is still plenty of time for anyone to chime in with further feedback. Thanks! KStoller-WMF (talk) 22:48, 20 October 2023 (UTC)

@KStoller-WMF: I agree that the image should be removed. Even if it was relevant, it still wasted vertical space on a page that could get quite long even without this extra placeholder. The only pages having placeholder images on WMF wikis are empty pages like the empty talk page experience of DiscussionTools – on empty pages, screen real estate is not that expensive. —Tacsipacsi (talk) 13:12, 24 October 2023 (UTC)

I agree the image on the top is a bit too much, but it definitely would be interesting to have smaller images denoting the extension/feature somewhere inside the accordion context (maybe something like the way images are shown for specific BetaFeatures?) Sohom Datta (talk) 06:55, 25 October 2023 (UTC)

That big images wouldn’t work with an accordion layout, but small icons would and would be useful. However, it may difficult to come up with an icon – how difficult also depends on whether the 2.0 page would be one single special page for everything, or separate pages (whether with different names or using a subpages) per extension/feature. Given how many options GrowthExperiments already has, I wouldn’t include even more options from other extensions there. If the accordion sections correspond to subfeatures of an extension/feature, that would probably make even harder to come up with icons.

KStoller-WMF, has it been decided whether there will be one huge page or multiple pages? If not, that would also be an interesting topic to discuss. —Tacsipacsi (talk) 15:45, 26 October 2023 (UTC)

@Tacsipacsi I don't think one huge page would scale well, so I'm definitely envisioning multiple pages.

Nothing is final, but my current thinking if that there will be some sort of main Community Configuration page that lists all of the features that utilize Community Configuration. Perhaps something simple, similar to Special:SpecialPages, but with more information about each listed configuration page. And then each feature (or group of related features) have a separate configuration page.

Does that sound like the right approach? KStoller-WMF (talk) 17:57, 26 October 2023 (UTC)

@KStoller-WMF: It sounds like a right approach. However, maybe not the “rightest” – while GrowthExperiments has a lot of options, many extensions will probably have only one or two, putting these on separate pages could also hurt usability. Maybe the perfect solution is a mix of the two: the main Community Configuration page isn’t simply a list of links, but a page where extensions with few options can be configured directly, while the separate configuration pages for extensions with many options are linked to. —Tacsipacsi (talk) 21:12, 26 October 2023 (UTC)

Thanks, that's a great point. OK, we'll take this into consideration and I'll have further designs to share in the future. KStoller-WMF (talk) 22:33, 27 October 2023 (UTC)

Hello! I finally got to the feedback. 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 :) Iniquity (talk) 04:50, 12 December 2023 (UTC)

Thanks, @Iniquity, that sounds very similar to what I've been thinking as well. I've added your feedback to the associated design task: T350201#9401677 (and Growth's designer will also be reviewing all of the other feedback in this thread as part of the task). KStoller-WMF (talk) 23:37, 12 December 2023 (UTC)

Third-party wikis

@KStoller-WMF: Why did you change “any wiki that installs the Community Configuration extension” to “any Wikimedia project that installs the Community Configuration extension”? What about third-party wikis, can’t they also install the extension? It also makes little sens to talk about Wikimedia projects that install the Community Configuration extension because (I assume) it will be installed on all Wikimedia projects. —Tacsipacsi (talk) 07:16, 18 October 2023 (UTC)

@Tacsipacsi Thanks for catching that, I think I better rephrase that. My coworker suggested a change in language to add clarity, but I can see how my revision is actually even more confusing.

Our intention is to eventually make Community Configuration an integral part of Wikimedia projects. In other words, our goal is to scale the extension up to all Wikimedia projects. Having Community configuration enabled everywhere would make it easy to integrate with, as you could rely on the extension always being available in a Wikimedia context. This would also allow engineers to maintain only one way of handling configuration.

Community Configuration will also be an extension that is usable by other third-party wikis as well. We hope that eventually, if this project is successful, that the Community Configuration extension will be a standard bundled extension. In other words, it won't technically be part of MediaWiki Core, but it will essentially become "core" functionality.

Sorry for the confusing edit! Does that make sense? Any concerns with that approach? We are still early in this project, and the Growth team is just starting a pre-mortem review of project risks, so definitely feel free to voice any concerns! KStoller-WMF (talk) 23:59, 20 October 2023 (UTC)

@KStoller-WMF: I agree with this approach, but I think the previous wording better represents this. —Tacsipacsi (talk) 13:15, 24 October 2023 (UTC)

I updated the answer and added a bit more info: diff. Thanks again for pointing out the confusing language. KStoller-WMF (talk) 21:11, 24 October 2023 (UTC)