… in order to structure i.e. searches in the forum?
Or are there just too many modules in order to maintain this well?
We could, although that might clutter things a lot, as you say. You can create tag hierarchies, so that you have to tag “module” before you can see all the module tags, which helps a bit.
The alternative is that forum regulars & mods have the power to make new tags as needed, so we can create them if we see certain things coming up often.
@Leo what do you think?
Hey there @dulhaver , we have been creating quite a few tags to keep things as consistent as possible (check Ansible for the full list), but having all the modules would be a huge amount of tags if we consider every collection (and that the 2.9 list is end of life).
What we have been thinking on is using the collection “namespace” (which sometimes matches the Working Group as well) in tandem with the collections tag where possible.
For example we could have posts tagged:
Collections and collection are an alias, so you can use any of those.
You can search for the combination by using the intersection search:
https://forum.ansible.com/tags/intersection/TAG1/TAG2
For ex:
https://forum.ansible.com/tags/intersection/collections/awx
Did you had any module in mind?
Think the collection, and collection name keeps things cleaner, and then maybe a CORE tag, for anything in core, that is not a collection. EACH module would be madness. especially with our move to collections.
nothing in particular. Was posting a Topu about an assert
issue and would have been tagging with assert whether that existed. That is how the Topic here came up
I don’t think having a tag for every module would be helpful, we would end up with thousands of tags. And then there are always new modules created, old ones deprecated or in some cases modules renamed. This would clutter things considerably.
I’m not even sure if having one tag per collection would be a good idea. Tags might even be useful for more than just one collection. For example, I think vmware should be used for both community.vmware and vmware.vmware_rest.
I think tags should be used to mark a more broad topic (like windows or kubernetes) and not bee too specific. There might be 1:1 relations between a tag and a collection, but this shouldn’t be a requirement.
If you want a tag for every module, then please first go to this list and read it out aloud. When (I’m tempted to write ‘if ever’) you finish, we can talk about it again
Even for ansible.builtin the list is already pretty long. We already have ~100 collections in Ansible, so just one tag per collection is already a long list. Tags for broad topics is a good thing, and maybe only create tags for more specialized ones if they would be used a lot.
Hey @sean_sullivan. the collection and collections are already aliased so that’s working already , and we have quite a few other tags aliased as well (not only for plural). We also have the ansible-core tag, which could currently apply for the bultin ones. More details below!
You can use a combination of collection, playbook and the ansible-core tags for that case.
Hey @mariolenz. That is the current approach. We are using “as generic as possible” tags to match collections namespaces, working groups or ecosystem projects. The vmware tag is valid for what you mention, and for ex. the awx tag applies to awx.awx
as well as to the AWX project.
The idea is to “combine” tags to be more specific. In awx case it could be together with a collections and playbook tag to denote an issue with said collection, OR with a dev (and/or project) to refer to the actual project development discussions. Add to this the category Get Help and Project Discussions to differentiate the type of post.
Agreed. We will have some extra/useless tags from time to time when the use and level of users increases, particularly in Get Help, but keeping an eye on the posts and their use will give us a better understanding of how to make the best out of them. For now we are tagging as part of the moderation and trying to keep it at a minimum plus on topic. I will create a topic later with the “initial” policy, but the tag list can be checked in real time here.