As of now, we use several different phrasings to label the set of users who have write access to CommunityConfiguration (as in, can actively change config, as opposed to merely reading it). This has caused misunderstanding and confusion in several places – most recently, the communication style from T363525: Community Configuration edit form: protected / read only view was disputed (during the Code Review process) by @Tacsipacsi.

After reviewing the existing documentation and messaging, there are a couple of different patterns present:

1. Giving a complete-ish list of groups with access: In some places (for example, the MW.org help page), we list a complete-ish list of groups with access. This is reasonably easy to read, but fairly difficult to maintain. The hard maintainness is already visible in the present page (as for example, Staff or Sysadmins can edit the configuration as well). Including the full list of groups is also repetitive when done in multiple places, and easily takes half a line. Furthermore, the list of groups is potentially different on each wiki, and this approach might not be easily viable in documentation pages.
2. Labelling everyone as administrators in favour of brevity: Considering all users with write access have certain administrative permissions, it might make sense to simply call them all "admins" (in the broader sense of that word). This approach is currently used on the [project page](https://www.mediawiki.org/wiki/Community_configuration.
3. Using a generic term: We can also use a generic term, such as privileged users, which is always accurate, but it does not include any useful information. The complete list of groups might be then mentioned in a single place (possibly from a "Get help" overlay in CommunityConfiguration itself), and users might be directed to that place to find more. This is what Special:EditGrowthConfig does.
4. Using a technical term: Last but not least, we can mention the actual technical permission (such as editinterface) which governs the access to the patch. This gives all necessary information to tech-savvy users, but is hard to understand for non-technical people (and otherwise equivalent to option 3).

Of course, it might make sense to adopt different communication styles in different pages, but considering this became an issue several times in the past, we should definitely approach the messaging in a more systematic pattern. When making a decision here, we need to weight truthfullness and understandability; we should also ensure that whatever approach we end up with will work with other stores than wikipage one (while we do not have any right now, one of key concepts of community configuration is modularity, as we do want to have the ability to change any of the modules without affecting the rest of the system, for whenever that becomes necessary).