chore: adding guidance for workless charms for repository naming

[deusebio]

As discussed among Charm Engineering managers, we'd like to soften the guidance on using the -operator suffix for workless charm to favor a less verbose, convoluted naming using multiple suffix stacking.

Preview

[james-garner-canonical]

Thanks for opening a PR, avoiding convoluted suffix stacking sounds great to us. Having conventional repository names is handy for discovery, so what do you think about enumerating the suffixes here? Besides 'operator' and 'integrator', I guess there's also 'configurator'. Are there more we should document?

I think this can replace the guidance we documented originally, perhaps like this:

Suggested change

	Name the repository using the pattern ``<charm name>-operator`` for a single
	charm, or ``<base charm name>-operators`` when the repository will hold
	multiple related charms. For the charm name, see [](#decide-your-charms-name).
	The suffix `-operator` applies only to charms that manage workloads and operate a particular software. Do not use "-operator" suffix for workless charm (e.g. integrator charms) that do not manage any workload for avoiding suffix stacking and favoring a leaner naming, such as `data-integrator` instead of `data-integrator-operator`.
	Name the repository using the pattern ``<charm name>-operator`` for a single charm managing a workload. Workloadless charms managing integration with another charm should use the suffix ``integrator`` instead. Charms managing configuration for another charm should use ``configurator``. Monorepos containing multiple related charms should instead use a plural suffix, like ``operators``. For the charm name, see [](#decide-your-charms-name).

[deusebio]

reads good!

[MattiaSarti]

As confirmed by @james-garner-canonical, we could avoid this ambiguity by:

Suggested change

Name the repository using the pattern ``<charm name>-operator`` for a single charm managing a workload. Workloadless charms managing integration with another charm should use the suffix ``integrator`` instead. Charms managing configuration for another charm should use ``configurator``. Monorepos containing multiple related charms should instead use a plural suffix, like ``operators``. For the charm name, see [](#decide-your-charms-name).

Name the repository using the pattern ``<charm name>-operator`` for a single charm managing a workload. Workloadless charms managing integration with another charm should use the suffix ``integrator`` instead. Workloadless charms managing configuration for another charm should use ``configurator``. Monorepos containing multiple related charms should instead use a plural suffix, like ``operators``. For the charm name, see [](#decide-your-charms-name).

[tonyandrewmeyer]

I suggest we break this out and also tidy up the plural case at the same time.

Suggested change

	Name the repository using the pattern ``<charm name>-operator`` for a single charm managing a workload. Workloadless charms managing integration with another charm should use the suffix ``integrator`` instead. Charms managing configuration for another charm should use ``configurator``. Monorepos containing multiple related charms should instead use a plural suffix, like ``operators``. For the charm name, see [](#decide-your-charms-name).
	The name of a repository containing a single charm should start with the name of the charm, and then add an "-operator" (workload charm), "-integrator" (workload-less charm managing integrations with another charm), or "-configurator" (workload-less charm managing configuration of another charm) suffix, unless the charm name already contains the suffix.
	Repositories that contain multiple charms or one or more charms and other artefacts (like Rocks) will need to use other naming patterns.
	For the charm name, see [](#decide-your-charms-name).

And then I think we should expand the examples section below to include at least one of each of these cases, for real repositories that we think use the right pattern.

[MattiaSarti]

suggestion: I would also mention the distinction between normal operators, whose repository suffixes are not included in charm names, and integrators and configurators, whose charm suffixes are often (but not always, hence the necessary disambiguation) also included in charm names, instead - for example: kubeflow-dashboard-operator vs data-kubeflow-integrator

[tonyandrewmeyer]

We will also need to update docs/howto/manage-charms.rst:17-18 in charmcraft, and also the check in charmhub-listing-review.

[deusebio]

Yes, the comments here make sense. Also following the discussion on Matrix, I'm going to bring up the conversation about "integrator" vs "configurator" in the charm engineering meeting later today, such that we gather whether anyone has strong ideas on this.

Once we have clarity/decisions on the integrator vs configurator discussion, I'll them post the update here and on Matrix and address the comments.

[dwilding]

Thank you @deusebio. Aside from the question of integrator vs configurator, I would like to adjust the way this info is documented. In part to avoid the best practice note having too many details.

Here's a diff of the structure I have in mind:
deusebio/operator@wip-repo-naming-workless-charms...dwilding:operator:expand-naming-guidance

Happy to leave suggestions here later, or make changes directly - whichever works for you.