Ansible community roadmap 2026

Project Discussions
, ,
1

Hi everyone,

Since the Contributor Summit at CfgMgmtCamp we’ve been working on defining our roadmap for 2026. We’ve gone through all our notes and have put together some high-level descriptions of what we’d like to achieve.

As we said at CfgMgmtCamp we want to openly commit to the work in our roadmap and hold ourselves accountable. We plan to do that through regular updates in the forum as well as by announcing progress in the Bullhorn.

Another thing to be clear about from the start is that this roadmap is a priority for us. However it’s a percentage of our work. For instance, there are plans to improve the Bullhorn newsletter, organize community events, and expand our Ansible meetup strategy that are not reflected here.

The Community and Partner Engineering (CPE) team is also part of the wider Ansible engineering team at Red Hat. There is other work that will come our way. Ideally we’ll be able to complete everything in this roadmap before we meet again at CfgMgmtCamp in 2027 but maybe some bits will still be in progress or not even started. Not to sound like a disclaimer, though, we just want to be honest that we might not achieve everything we set out to do. Although we’ve already been working on implementing some suggestions and pieces of work from CfgMgmtCamp, like the proposal to mandate collection testing against the devel branch.

With all that in mind, we’d appreciate it if you could review our roadmap and provide any additional feedback, concerns, or questions.

Goals

At this year’s Contributor Summit in Ghent, the CPE team described our high-level goals for 2026 as follows:

  • Focus on content quality. This goal is about helping to improve processes and tooling to develop and test collections as well as to reduce fragmentation.
  • Improve content discovery and user adoption. This goal is about helping users do things like find content more easily or quickly assess the health and quality of content.
  • Reduce maintainer burden. This goal is about making the lives of collection maintainers easier.
  • Act as open source champions. This goal is about creating opportunities for collaboration but also working with other engineering teams at Red Hat to more effectively participate in the community in a way that promotes transparency and demonstrates trust.

One other goal became really clear for us at CfgMgmtCamp too. Much thanks to Felix for capturing it precisely in his 2026 discussion posts in the forum.

  • Improve communication! This goal might actually fit under “act as open source champions” but it’s really important and worthy of special call out. There has been a lack of communication, or just bad communication, over the past while. However good communication is a cornerstone of a healthy community so we think that it is vital that we work to address that.

Increase forum participation and open technical discussion

Description

The CPE team will work with other Ansible at Red Hat engineering teams to increase participation on the forum and establish clear guidelines for open discussion related to technical decisions.

As an outcome of this epic, the CPE team will recommend guidelines and tooling that encourage public notifications about breaking changes, deprecations, and other important updates.

While many teams already communicate on the Ansible Forum, this work focuses on establishing earlier and more structured notification processes. This can include alerting the CPE team of upcoming changes so that we can proactively communicate those changes to the wider community. This also covers CPE’s ongoing work within the community to build expertise in collection maintainer roles and upstream processes.

Related information

Establishing an AI policy with the Ansible community

Description

The policy should address contribution review practices, attribution, quality expectations, and the responsible use of AI in the context of the Ansible community as well as for Ansible engineering teams at Red Hat.

Related information

Streamlining and opening up the certification and validation process

Description

This epic has two main objectives that overlap but are distinct. The first objective is to reduce friction for ISV partners who submit collections for certification. The second objective is to make the certification requirements and process transparent to the entire Ansible community.

Reducing friction for ISV partners covers the end-to-end partner journey from initial onboarding through the certification process and extends to the entire collection lifecycle, including releases and deprecation. Achieving this objective requires improvements to partner documentation and tooling.

Outcomes of this objective include the following:

  • Improving partner satisfaction and perceived value of the overall certification program.
  • Increasing collection approval rates which will free up CPE team capacity by removing manual bottlenecks.
  • Optimizing certification requirements so they are clear and consistently applied.

Increasing visibility and transparency of the certification process allows Ansible community members to review, provide input, and suggest improvements. Achieving this objective requires publishing partner documentation on docs.ansible.com as well as encouraging and facilitating participation on the community forum.

Outcomes of this objective include the following:

  • Increasing trust in the certification requirements and process through open participation that leverages the deep expertise of the Ansible community.
  • Increasing the quality of certified and validated content for Red Hat customers.

Creating an Ansible community status page

Description

Address the reliability, observability, and documentation of the critical infrastructure that underpins the community ecosystem. Create a public status page for monitoring community infrastructure and resources (such as Galaxy service health, bots etc).

Related information

Improving lifecycle management for certified and validated content

Description

Certified and validated collections need to have clearer lifecycles defined that outline the deprecation cycles and how they reach EOL. Additionally, we should have clearly documented procedures on how we handle deprecations and what happens to collections when they reach EOL.

There have been recent changes to collections that Red Hat has offered up to the community, such as openvswitch.openvswitch and cisco.asa. The process for deprecating and removing these collections from Automation Hub seems unclear and somewhat ad hoc.

There should be a well-defined, publicly available, process for deprecating and removing certified and validated collections. The current workflow guide has a section on Lifecycle and version support. This outlines requirements for maintaining certification but it does not outline the deprecation process.

In the event that Red Hat offers collections up for community maintainers, there should also be a well-defined process before collections are removed from Automation Hub. This process must also include specific guidance on openly communicating the changes with both Red Hat customers and community users of Galaxy. The process should also provide safeguards against deprecated and out of date content remaining on Galaxy while being removed from Automation Hub.

Related information

Developing a unified strategy for collection testing

Description

Establish a single, authoritative collection testing strategy that resolves the current confusion caused by multiple overlapping tools and redundant GitHub Actions (GHA) workflows spread across community repositories. This effort covers defining the recommended approach and consolidating reusable GHA workflows into a canonical repository.

As an outcome this effort will reduce maintenance burden, add clarity for partners and community maintainers, and result in content quality improvements across the Ansible ecosystem.

Related information

Using Read the Docs to improve collection discoverability and docs rendering

Description

One of the motivations for collection maintainers to distribute via the community package is the ability to publish collection documentation on docs.ansible.com. Prior to the Read the Docs migration the community package was the only path available to achieve that. Now that all community docs are hosted on Read the Docs, it is possible for collection maintainers to publish as a subproject.

In parallel with the improvements to community publishing, the community docsite project offers a path to improve the content discoverability and documentation rendering issues on Ansible Galaxy. It is difficult for users to find or filter automation content. There are no clear indicators for content health or quality. Galaxy has documentation rendering issues that pose a significant maintainer burden.

Here are some of the activities we’ll undertake to complete this work:

  • Create wireframes or design for the collections page as well as a collections “spotlight” band on the landing page.
  • Investigate publishing subprojects, either as a combined subproject or as independent subprojects.
  • Investigate minimum requirements and governance for collection publishing.
  • Investigate quality indicators and collection health levels.
  • Create a docsite POC with search capabilities and quality indicators that also validate things like role_arg spec rendering
  • Work with the community to establish a path to community publishing for collection maintainers

Related information

Improving collection publishing to Galaxy

Description

Given the attendance from a wide range of collection developers and maintainers, a recurring theme at CfgMgmtCamp is reliability and performance of services for publishing collections to Galaxy. The primary means for publishing collections is Zuul, which the community perceive as neglected due to being unreliable and slow.

This effort is going to focus on modernizing or replacing Zuul and improving performance for community developers and maintainers. We’ll also work on achieving per-repository Galaxy token granularity as a security and operational improvement.

Related information

Helping Ansible projects adapt to and support CRA compliance

Description

The European Union (EU) is enacting the Cyber Resilience Act (CRA) that establishes a mandatory cybersecurity framework. Red Hat is expanding its community stewardship obligations under the CRA, which will improve the security posture of Ansible community projects through project documentation (such as SECURIY.md files) and tooling (security and vulnerability scanning). The Community and Partner Engineering (CPE) team is currently working with other Red Hat supported communities in the implementation of guidelines, policies, and procedures. This effort will continue over the next few months as we clarify details and start introducing changes and improvements to align with the CRA.

Related information

4 Likes
The Bullhorn #221