###### tags: `CfgMgmtCamp 2026`

# Ansible Contributor Summit, CfgMgmtCamp 2026

This public HackMD is to allow everybody to make notes during Contributor Summit on Wednesday 5th Feb which takes places as part of Configuration Managemenent Camp in Ghent.

Useful links:

- HackMD notes for Monday & Tuesday: red.ht/ghent2026
- Short URL to notes for Monday & Tuesday's talks: https://red.ht/ansible-contributors-summit
- [Contributor Summit agenda in the forum](https://forum.ansible.com/t/cfgmgmtcamp-2026/44250)
- [Ansible Code of Conduct](https://docs.ansible.com/projects/ansible/latest/community/code_of_conduct.html)
- Live stream: [YouTube](https://youtube.com/live/I5-T-RuhJzY?feature=share)

# Ansible Community & Partner Engineering updates

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

## Discussions

What is involved in the Certified & Validated process
Is it manual or automated, can it be shared?

[ABU Validation Workflow PDF](https://connect.redhat.com/sites/default/files/2025-08/ABU%20_%20Validation%20workflow%20guide%20v2.0.pdf)

Idea:
Add Check to ensure that release is tagged, avoids problems with Ansible release.

## Ideas & Actions

- Certified collection workflow process. How does it work? Is it a manual or automated process? A mixture of both?
- 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.
- 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](https://github.com/ansible/ansible-content-actions)?
- Missing documentation around Zull use for publishing `community` namespace collections to Galaxy.
- Who is the Point of Contact for zull build isuses?
- [https://github.com/ansible-community/ansible.content_builder](https://github.com/ansible-community/ansible.content_builder) 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. Jeff: so there's already an issue, I've written down my thoughts in a post on it: https://github.com/ansible/ansible/issues/86233. It could very well be that there's more issues with the same basic idea, but this one was recent and popped up immediatly when I looked for it :-)

- [`ansible/galaxy`](https://github.com/ansible/galaxy/) repository should be archived. Pending moval 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`.

### Focus on content quality

### Improve content discovery and user adoption

- galaxy.ansible.com UX improvements:
- Ansible Collections - Last tested with Ansible Core version? Last linited via `ansible-lint`?
- Add `ansible-lint` results to collection overview.
- Exposing CI results from the collection repository to Galaxy.
- Scoring system?
- Favorite a collection 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](https://github.com/ansible-collections/collection_template/)?

### Act as open source champions

- Let the community know when it's not going well. If it breaks, it happens, we're working on it, expecting an ETA on fix, Root Cause Analysis would be nice etc.
- Signal to noise ratio, forum tag for `critical-service-status`. Using maybe [Gatus](https://github.com/TwiN/gatus) or [Uptime Kuma](https://github.com/louislam/uptime-kuma) for status page for docs.ansible.com, galaxy.ansible.com etc.

➡️ Forum Post: [Ansible Community Status page & Notifications](https://forum.ansible.com/t/ansible-community-status-page-notifications/45253)

### Other

- Security scanning / Static Application Security Testing, Software Composition Analysis scanning? Dependency vulnerabilities.

# Open Discussion: Good, bad and ugly

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

## Discussions

- 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 version of Python to be installed on the Managed Node.
- RHEL packaging the bindings for packaging multiple versions of Python, not just the system Python.
- Possible to target multiple versions of Python
- Ansible Core 2.21 - Tiny c types wrapper around libdnf and that is implemented into the Ansible DNF module.
- Still would need a supported Python version of the Mangaed Node (target).
- When is this going to be supported for certified content / system roles.
- To be determined.
- https://github.com/ansible/ansible/pull/86432

- Data Tagging: Changes to trust model and templating changes, boolean(ish) values are now disallowed. In general is a good thing because it makes templating more consist. 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](https://forum.ansible.com/t/inject-facts-as-vars-is-defaulting-to-false-in-2-24/44886)
- 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 collision. 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 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 when 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: Being able to disable specific ones. Making maybe 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 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 error as warnings.

## Ideas & Actions

- 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.
- Could this perhaps pattern perhaps be documented (in coarse detail, just to get the gist on how to approach this problem) somewhere in the module development docs?

# Bullhorn, Meetup, Release Calendar & Social Media

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

## Discussions

- Quarterly edition of the Bullhorn?
- Maybe pinning certain annoucements for a few weeks on the forum? Would that be too much? Maybe...
- Discussion annoucements 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 a 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?

- 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 certian 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 :heart:

- What Social Media platforms would you prefer for use:
- mastodon.social
- linkedin.com
- Metrics based on the type of platform.

- Release Calendar:
- Releasing Ansible Community package.
- Release mentorship program was introduced.
- Plan releases better.
- Give recognition to the release managers.
- Having a special release calendar in the forum.
- Better schedule. Dependent on the Ansible Core releases.
- Sometimes Ansible Core releases are moved, and then the community package finds out and then know that the Ansible Community package needs a release. Area for improvement: Ansible Core communication on release time so the Ansible Community package can be coordionated.
- Issue with some collections not following semver.
- Could there be potential for helping collection maintainers with auto bumping collection version based on commit messages? :thinking_face:
- Core is usually release Monday afternoon. Suggestion for a maybe a week between Ansible Core vs Ansible Community package releases?

## Ideas & Actions