I mentioned this topic in the Matrix room for the Ansible Community Working Group and it was brought up that the Forum might be a better place to have the discussion and I agree.
It is widely known among Ansible developers, contributors and users that “Ansible” can mean many things, depending on the context. However, this is not evident to all users.
To name a few examples of what “Ansible” might refer to:
ansible-core (formerly ansible and ansible-base as well)
Red Hat Ansible Automation Platform (AAP)
Ansible Community Package (ansible-core + selected collections = also known as “Batteries Included Ansible”).
Ansible the language (YAML)
Ansible as the “upstream Ecosystem”, when refering to all the projects (ansible-core, Ansible AWX, Ansible Galaxy, Ansible Lint, Ansible Builder, etc.)
Given that the Ansible Forum is a space for everyone and everything Ansible-related, perhaps it’s time to standardize naming conventions in announcements so that everyone understands what is being referred to.
The idea is to set a common nomenclature, maybe using the glossary, for the Ecosystem Releases category, The Bullhorn Newsletter and documentation for example, among other spaces we notice consistency is required.
We have seen the standalone “Ansible” be used in several places. Should we be more specific? Have you been confused by a deprecation notice, release announcement or something else? Any other thoughts are welcome!
I have to say that “Ansible the language” never crossed my way up until now. But I often use “Ansible (community) package” to make clear I’m talking about this. Although not consistently.
Generally, I agree that it might be a good idea to have some guidelines or maybe even policies about this to avoid confusion. Like, for example, always use Ansible Comunity Package / ACP instead of just Ansible. Even if the package on PyPI ist just ansible.
Might be a lot of work to amend all the docs, but we have to start somewhere. And this means to standardize naming conventions in announcements and possibly elsewhere.
I do/did a lot of onboarding for new users, and when refering to YAML when introducing it, you usually need to make it clear it’s “Ansible YAML” and not any YAML (like K8s for ex. for those using it)
I agree on the acronyms, I’m not a fan either, but, considering Ansible Community Package is quite long, it’s not a bad idea to use it as “Ansible Community Package (ACP)” and later refer to ACP within a longer text for ex., that doesn’t mean we need to refer to “just” ACP and assume everyone knows what it is.
Naming is hard, but If we want to avoid confusion we need to come up with descriptive (albeit long) name, or something “very original” like Elbisna.
Ansible package still suffers from the original issue of “being too generic” in my opinion. Having a specific name for the Ansible Community Package allows to avoid mistaking it with other parts of the project. If you talk about an “Ansible package” with different people (AAP users, pip users, distro users) they will all have their own interpretation. Is the package refering to the RPM? to the PyPi package? to the deb?
RHAAP: Although I have seen it, 99% of the time people refer to it as AAP. I would keep it that way, we don’t need to replace an defacto acronym, and if we need to be specific we can mention Red Hat AAP for ex.
Ansible ecosystem is the same. Ecosystem is a loaded term sadly. It can refer to the “Collections”, it can refer to all the “upstream projects”, it can refer to the AAP Partners and certified content…
And this is not only a PyPi thing. Distributions and “community repos” (EPEL, PPA) also package it with that name. Should we propose that to be changed as well?
I agree it will be a long haul, and also we need to start somewhere if we are to do it.
Yes, sounds reasonable. This would be the approach I would also suggest.
Don’t get me wrong, I really do not propose or suggest to change the name of the package at all. There’s already enough confusion, we shouldn’t make this worse.
We’ve recently had a big discussion about what the ansible package is, should be, and their alternatives. Every time that comes up, the general consensus is that the status quo should be maintained, though the “alternatives” might not be dismissed either (such as making a smaller variant with only “certified” collections). Renaming the package would go against that consensus.
I like this term. It’s like a gestures at everything term for Ansible. It’s anything and everything related to Ansible, especially if it’s from or distributed by Red Hat.
FYI, Red Hat doesn’t recognise AAP as an official abbreviation.
In the platform docs, the full name (Red Hat Ansible Automation Platform) or short name (Ansible Automation Platform) must be used throughout.
It doesn’t help readability, in my opinion.
internet search for Ansible ACP (yes I know it’ doesn’t exist yet) shows up a LOT of Red Hat AAP stuff. Suggests if we use that acronym, we’d start colliding more with the products. (Searching just Ansible pulls up mostly community stuff).
If we start using things like ACP 10.0.1, yes it’s easy to type, but google won’t find it. We have 10+ years of google search reputation on Ansible (which is why Red Hat products have a hard time showing up before Ansible community stuff).
