Proposal: trim and restrict the Ansible community package down to a Steering-Committee-selected set

Project Discussions
1

Hello everyone,

For people who don’t know, I’m Andrei, a Steering Committee member and a person who reviews all Ansible community package inclusion requests. To learn how the reviews are done, see ansible-inclusion/README.md.

In the susunola.tencentcloud inclusion thread, we see the first concrete case of what I think is a coming pattern: a collection with 1000+ plugins/modules, largely unreadable generated documentation, and 500+ sanity-test ignores to mask bugs and inclusion checklist violations and to make the CI green.

We -Steering Committee- didn’t build the inclusion workflow and policies around the AI-driven submission pace and volume that are built in a way to superficially pass the requirements.
Reviewer bandwidth was already a concern back in the community-topics repo discussion in 2022, before this kind of volume was even possible.

We’ve had this conversation before, in the Future of the Ansible Community package topic. I asked AI to get main tension points from those discussions:

  • the package was originally meant to be transitional and fade away as collections matured, not grow indefinitely (it went from 81 to 99 collections between 2.10 and v5 alone)
  • “raise the bar” versus “curate by usefulness × popularity ÷ size”
  • the real onboarding/docs value the bundling provides

So my concerns and main points are:

  • Do we really need to proceed within the current scheme bloating the package and docs.ansible.com with content I’d expect to be niche?
  • Reviewer bandwidth (“Use AI to review” kind of suggestions isn’t a good solution to this specific problem IMO).
  • It’s still not a problem to download any collections you need.
  • This topic is about the ansible community package that users install with pip install ansible. Anybody can build any alternative one and publish it on PyPI whether it’s ansible-databases, ansible-cloud, or ansible-kitchensink accepting whatever collections they want.
  • Introducing new requirements or forbidding AI-generated collections is not going to work IMO.

My proposal: To tackle the problem at the core, trim the community package down to ansible-core plus a set of collections explicitly selected by the Steering Committee. The specific set of collections and criteria aren’t to be decided in this topic. The goal is to discuss what we want the framework to look like and start the process which will require separate discussions around criteria, an initial set of collections, and concrete policy updates.

Anyone’s feedback on this proposal is much appreciated.
Then we could start a vote on moving toward it or keeping the approach as-is.
If this initiative is supported, I’ll volunteer to lead / contribute actively to the policy change effort.

5 Likes
2

Sounds like a good idea to me. I think we should have one/two places where:

  1. collection maintainers can apply for inclusion by trying to convince us why their collection would be a good fit for the Ansible package;
  2. users can request / vote for collections to be considered for inclusion.

It might also make sense to have a subgroup of the Steering Committee doing the selection, and the whole group only being involved in edge cases / when the subgroup cannot decide on something.

3

And another thought as a separate comment: we should handle (relatively) small community collections differently then non-community collections and large community collections. Otherwise, we would be unfair to folks who do the extra steps of creating a community collection for content, versus just trying to get their stuff into community.general (which will likely end up being included, at least unless we figure out a way to split a “somehow more commonly useful” part of c.g out into a new “community.core” collection).