CfgMgmtCamp 2026: Community and Contributor Summit

CfgMgmtCamp 2026: Community and Contributor Summit

This post is part of a series of talks presented at CfgMgmtCamp 2026. Please see CfgMgmtCamp for all other talks.

Ansible - State of the Community

Speakers: John “gundalow” Barker and Don Naro

Slides: Presentation

Video: YouTube

As one of the big events on the Ansible Community calendar, CfgMgmtCamp is an opportunity to get together and review how we’re doing as a community.

This talk is aimed at anyone with an interest in Ansible, as all voices are welcome in the discussion of how to shape the community in the coming year.

How we opened up Ansible’s documentation infrastructure to the community

Speaker: Don Naro

Slides: Presentation

Video: YouTube

The Ansible community team at Red Hat work to dismantle closed infrastructure and open up workloads and processes to community contributors.

Join me to hear how we moved from locked-down Jenkins jobs to transparent, community-managed GitHub workflows. I’ll share how we navigated the technical challenges of migrating a truly chonky Sphinx build process, preserved a decade of SEO authority, and scored some major quality improvements by providing contributor access.

It all started at an Ansible contributor summit at CfgMgmtCamp 2023 too! So please join me as I share what we learned about infrastructure, trust, and some unexpected ways investment in OSS can unlock community potential.

Talk Notes

Dependency challenges initially. Lost reasoning for why certain versions were pinned in requirements.txt files.

Dependency pinning strategy:

  • Keep production builds stable.
  • Create tested and relaxed dependencies.
  • Don’t force users to install pinned dependencies.
  • Bump dependencies automatically.

Using nox to help with test automation - linting documentation for any formatting issues.

Ansible documentation bot for engaging with the community contributing to documentation.

Implemented patchback for backporting certain pieces of documentation. Reducing manual maintainer burden.

Ansible Community & Partner Engineering updates

Speakers: Don Naro and John “gundalow” Barker

Slides: Presentation

Video: YouTube

Don and Gundalow share updates from the community and partner engineering team at Red Hat and delve into our plans for the year ahead.

Ahead of our Contributor Summit we announced on the forum that the Community and Partner Engineering team plan to collaboratively define some of the work to take on in the year ahead. The Ansible Community Engineering team at Red Hat has always strived to empower our contributors and help community developers and maintainers get things done.

We started the morning session with an overview of the Community and Partner Engineering team at Red Hat to give contributors a better understanding of the team and where we’ve got to now that it has been more than a year since we combined two Red Hat teams.

That led us into a conversation with folks both in the room and virtually around these high-level goals:

  • Focus on content quality
  • Improve content discovery and user adoption
  • Reduce maintainer burden
  • Act as open source champions (champions as in facilitators, not “winners”)

During this session the Community and Partner Engineering team gained some valuable insights from our community to help us shape our goals and define priorities. Over the coming weeks we’ll be sharing more of our plans on the forum as we digest all the feedback and thoughts we’ve gathered.

Talk Notes

  • Certified collection workflow process. How does it work? Is it a manual or automated process? A mixture of both?

    • ABU Validation Workflow PDF
    • Potential use of AI for helping with the reviews?
    • Collection tagging releases until its ready for release which has caused issues with Ansible Community package collection building.
    • Idea: Maybe add a new requirement to the certified collection process that requires a collection to be tagged?
  • Centralise GitHub Action workflows across different repositories into github.com/ansible-content-actions?

  • Missing documentation around Zuul CI used for publishing community namespace collections to Galaxy.

  • Who is the Point of Contact for Zuul CI build issues?

  • GitHub - ansible-community/ansible.content_builder: A collection to scaffold Ansible plugins. moving this functionality to the ansible-creator utility.

  • ansible-galaxy CLI tool with requirements.yml adding an update command or --update flag to update collections which do have updates available. Right now the only way to do this is to use the --force flag on install which causes all collections to be re-installed.

    • Raise an issue on ansible/ansible for ansible-galaxy for this issue.
  • ansible/galaxy repository should be archived. Pending removal of namespace requests to forum.ansible.com - Add to the repositories README.md file mentioning this to avoid confusion. Mention that the repository is not for the ansible-galaxy CLI either. That should be raised in ansible/ansible.

Improve content discovery and user adoption
  • galaxy.ansible.com UX improvements:
    • Ansible Collections - Last tested with Ansible Core version? Last linted via ansible-lint?
    • Add ansible-lint results to the collection overview.
    • Exposing CI results from the collection repository to Galaxy.
    • Scoring system?
    • Favorite collections on Galaxy to see your favorite collections on Galaxy homepage.
    • Can we add a count for how many people have clicked on the documentation? Usage / consumption statistics for collection maintainers to see.
    • A label on Galaxy that the collection is included in the Ansible Community package.
    • Filter for collections containing plugins or roles etc.
Reduce maintainer burden
  • argument_spec.yml potential review and maybe improvements?
  • Better documentation rendering for collections on Galaxy.
  • Community AI agent skills for helping with maintainer burdening tasks. Could these go into the collection_template?
Act as open source champions
Other
  • Security scanning / Static Application Security Testing, Software Composition Analysis scanning? (Dependency vulnerabilities).

Open Discussion: Good, bad and ugly

Speakers: Felix Fontein and Matt Davis

Forum Post: Problems in the Ansible world and how to improve on them

Video: YouTube

felixfontein and nitzmahone lead an open discussion about the state of things in Ansible and how we can improve.

Topics

Support for Python versions

Support for Python versions. Managing RHEL 8 / Alma 8 / Older Debian LTS version you might find out that the latest Ansible core versions are unusable because they require newer versions of Python to be installed on the Managed Node.

Ansible 2.9 Templating Changes (data tagging)
  • Data Tagging: Changes to trust model and templating changes, boolean(ish) values are now disallowed. In general it is a good thing because it makes templating more consistent. More consistent typing.
    • Huge feature and seemed like it was not tested very well. Red Hat maintained collections which were broken, long talk against pre-releases. Example: ansible.netcommon was broken and required changes in core but core was already released so it was a bad experience for the community. ansible.netcommon is now testing against devel now.
    • Introduce a requirement to test against the devel branch? ACTION: Discussion with the Ansible Steering Committee.
INJECT_FACTS_AS_VARS
  • Forum Post
  • Being changed without communication as to why this is happening. Better communication for breaking changes. Changed due to a security problem and can cause variable collisions. Was pending data tagging being implemented to make this change.
  • ACTION: Follow up with Nitz to see which embedded docs/troubleshooting pages are still in ansible-core and ensure they still work (grep for docs URLs in core)
    • Might need a short URL for permalink errors
    • Maybe docs should also link to Forum
    • Discussion area for the core team to communicate changes? ansible-core tag and announcement maybe?
Collection maintainers when deprecating content
  • Collection maintainers when deprecating content in their collection to make sure you link to these issues and pull requests. In the changelog fragment link to the PR for more context for the users. Use deprecation messages so when a user running ansible-playbook can have a message for more context as to why it’s being removed.
    • Record Architectural Decision Records in the collection so that if someone wants to go through and find out why something was deprecated they can read about that and why it was changed.
    • Subdomain for redirects. Having these redirects stored in a GitHub repository and could be contributed by the community. Submit a PR to add a new redirect so it doesn’t matter if the documentation is moved it doesn’t matter. It will link to the correct location.
    • Forum tag for these kind of specific discussions.
    • Where could these kind of documents be stored? In the collection itself? Could there be a standard around this inside collections? Like in the meta/ directory with a specific file name.
    • Concern: If we make it too complicated for collection maintainers it won’t get used. Need to carefully consider the solutions.
Warnings & Deprecation Messages
  • Warnings & Deprecation messages: Being able to disable specific ones. Maybe making certain ones errors rather than warnings.
    • 2.19 standardised the error and warning controls in Ansible Core. Assign IDs to the warnings and collections could do the same for their modules. Hopefully some new features are upcoming in new Ansible Core versions.
    • Being able to get a count of the number of deprecation warnings have occurred.
    • Error as warning, warning as error in Ansible Core 2.19.
    • Capture warnings and correlate them to tasks. Accessible in task results, or register a variable. Improvement for integration testing, can check that a warning has occurred now.
      • ACTION: Contact nitz if they could create a forum post about this warnings and errors as warnings.
Ideas & followups
  • Does it fix the issue with newer versions of Ansible Core not supporting RHEL 8 for example?
    • Yes, this is a pattern that the core team is trying out and if successful could be implemented by collection maintainers too.

As a user:

As a collection maintainer and developer:

Bullhorn, Meetup, Release Calendar & Social Media

Speakers: Anwesha Das and John “gundalow” Barker

Slides: Presentation

Video: YouTube

@anwesha and @gundalow discuss Bullhorn improvements, release calendar sync, meetup strategy, and other topics related to communication and promotion of the Ansible community.

Talk Notes

Bullhorn
  • Quarterly edition of the Bullhorn?
    • Maybe pinning certain announcements for a few weeks on the forum? Would that be too much? Maybe…
  • Discussion announcements are very useful in the bullhorn.
  • Major releases / changes to Ansible Core, having those posts included in the bullhorn are very useful.
  • Matrix barrier for entry for the bullhorn:
    • Forum - Discourse to Matrix bridge. Open Source project.
    • Forum - Email to Matrix bridge. Open Source project.
      • Email to an email address & then arrives in Matrix and then could be included in the bullhorn.
    • Forum Event for that specific edition of the bullhorn and then all replies to that event are added to that edition.
    • Ansible Collections - GitHub releases - Subscribe to releases only and have those notifications be included in the bullhorn?
  • :right_arrow: Forum Post: Bullhorn content quality improvement proposals
Ansible Meetups
  • Meetups - Ansible is now on Meetup Pro

    • Ansible Community meetup repository: https://github.com/ansible-community/meetup
    • Ansible Meetup Toolkit: https://docs.ansible.com/projects/meetup/en/latest/
    • Having a repository / speakers directory where folks can add themselves as being interested in speaking at Meetups on certain topics? Would this help meetup organizers find speakers?
      • What is the level of expertise that you want to hand out to the attendees?
      • Some way of when folks sign up to meetups we can gauge the kind of talks wanted.
        • Helping meetup organisers know the expertise level of participants to know what kind of talks are needed.
      • Maybe having a speakers directory on the forum?
    • Library of Community talks which could be used?
      • Which format for the speaker content should be used? PowerPoint, Latex, Google Slides etc.
      • Probably not PDF because then the content could not be editable.
    • Uploading speaker content without any license. Do we need to have a common license for content?
    • Ensure if a meetup takes place then please make sure that information about the meetup is posted on the forum.
  • :right_arrow: Forum Post: https://forum.ansible.com/t/github-repo-for-slides-for-meetups/45281

The exploitation paradox in open source

Speaker: Richard Fontana

Slides: Presentation

Video: YouTube

Open source has always balanced freedom and power. Each era, from the rise of Linux to the cloud to generative AI, reveals the same flaw and the same strength: ideals built to maximize liberty inevitably create new leverage points. This talk traces that recurring pattern and argues that open source’s periodic crises are not failures but feedback loops, teaching us how to keep freedom alive in changing infrastructures.


Check out the other sessions at CfgMgmtCamp 2026 using the links below:

Here are links to all the talks on YouTube as well as related forum discussions:

2 Likes