Dedicated category for Collection development?

As discussed in the Ansible Community Working Group meeting of 2024-05-22, I’m looking for feedback on creating a dedicated category for Collection developers, maintainers and contributors, so that we have a space to share and collaborate in a more cohesive way.

The current setup allows for people who are developing, maintaining or contributing to a collection to post to the Project Discussions category, which might be confusing for those expecting that category to be related to the different Ansible Projects in the ecosystem (ansible-core, AWX, galaxy-ng, devtools, etc.) instead of the collections.

A dedicated category would also help avoid another point of confusion on when to post to Get Help. Which should be reserved for “using a collection, not developing one”.

The category could be called “Collection Development” or “Collection Dev” for ex. and it could be a sub-category of Project Discussions.

Alternative ideas for naming and feedback on if it would be useful are welcome.

Call to action:

Do you think a Collection development category would help?
  • Yes! (add feedback in a comment)
  • No! (add feedback in a comment)
0 voters
1 Like

This seems a great idea to me, particularly if “Collection Development” encompasses “shared asset development”. Maybe I have unwarranted historical connotations, but “Collection Development” feels focused on packaging roles for sharing, either across internal projects or with other groups through Galaxy. In actual practice, most of what my group has packaged into collections has been plugins, specifically custom tests, filters, and modules. Not roles.

Case in point: Several months ago, @felixfontein pulled me out of several rabbit holes when I was attempting to share a majority of the python code implementation of a closely related custom (test, filter) pair. It turned out that sharing code between different plugin types is quite easy if they are packaged in a collection, but almost impossible as non-collection old school plugins. Most of those exchanges were private as I recall. Had a “Collection Development” category been available, it would have been a natural home for such exchanges of development and discovery, a record of which would have made a valuable and informative topic in that category. (Hey, thanks again, Felix.)

That’s a long-winded (as is my usual) way of enthusiastically saying, “Yes! Let’s do this.”

3 Likes

Yup, some level of separation when getting help is certainly going to improve the communication. Count me in.

1 Like

This is quite interesting, for me “Collection Development” was a synonym for “packaging modules and plugins” for quite some time (starting with the Ansible 10 split into ansible-base 2.10 + a set of collections), the aspect of adding roles only came later (for me). But this is the second time in two days that I see someone mentioning that for them collections are for most users/content creators more about roles than modules/plugins. It’s always great to see your assumptions challenged :slight_smile:

I would say that “Collection Development” will definitely be for both roles and modules/plugins - and also EDA plugins, which can also be in collections. And I also like the idea of having a separate category for this, since I think both Get Help and Project Discussions aren’t the best places for (many) questions about collection development.

2 Likes

I’m happy to see that there is support for the idea and there seems to be a need to fill.

Indeed it does. The idea is if it’s supported to be included in a collection, then it’s the right place. This could be playbooks, roles, plugins or tests. As noted in the collection structure docs.

If the exchange was in DMs here in the Forum, I might have good news: You can actually move the thread to the category… I think. We might need @gwmngilfen to confirm :smiley:

In my experience, Collections usually are a bundle of Roles for most of those who haven’t developed any Plugins yet. And the other way around for those who have :laughing:

3 Likes

I should say there’s more to “Collection Development” than just packaging. I think there are also more general questions about best practices, like when is it a good idea to move code to a module util. Or about depending on other collections. Or best practices on documentation.

I could go on, but I think it’s clear what I mean. I think such a category would be helpful. Especially since I see questions about collection development in the chat from time to time. Both the questions and the answers are kind of lost there for others. Having a category here in the forum about collection development and discussing those questions there would make it possible for people to find them easier and make them more accessible.

@gwmngilfen AFAIR you don’t want to have too many categories, but this one sounds a good idea to me. What do you think?

1 Like

I didn’t mean “packaging” in the sense of “using just for delivery”, but I meant that collections were mainly about plugins and modules for me, not about roles.

After looking over what we actually use from collections, I think you’re right. The interesting and most useful stuff is the plugins, not the roles.

We have a good handful of shared roles, and we were in the process of fabricobbling a poor man’s collection predux when the whole collections thing started to take off. That’s probably why my perception was skewed — because I was looking at it through the lens or how to use collections to solve our then common roles problem. [I’mma crawl back under my rock and finish my nap now.]

I think that a separate category on, generally, development of automation content is long overdue, so I suggest to call it “Automation Content Development” or something like that. (What if I have questions about making execution environments, e.g.?)

1 Like

“Automation Content Development” would intersect largely with “Get Help” I think, and also with “Collection Development”. This could be a bit too broad.

A seprate category for collection development is a great idea. It would centralize resources and discussions, making it easier for developers to collaborate and find solutions. This discussion and focus can bring more targeted improvements and innovations within Ansible.