I found out about Mentorship Program for New Ansible Release Managers today from @anwesha. It seems this was not discussed with the release managers or the SC before it was announced, which would’ve been ideal. It’s hard to have a discussion about something like this after the fact, and I felt a bit blindsided.
I think it’s great to get more people involved in the Ansible project, but I do have some questions/concerns about this particular program, so it would be great to hear more about it from the Community Team.
Generally, release managers have been Red Hat employees or people deeply involved in other areas of the project — the steering committee (SC membership or just participation in discussions and meetings), collection maintainership, release tooling maintainership, and/or distribution packaging. Releasing the community package requires the highest level of permissions and access to the package relied on by very many users, so I’m not sure it’s the best place to start for completely new contributors.
The Ansible community package release process is mostly automated and we have 5 release managers already, so I wonder if this program could focus more on activities adjacent to the community package process that need more help such as
Submitting PRs to release the community execution environment and increasing automation there.
Firstly, I am extremely sorry for not communicating well in advance in the #release-management WG channel. I hear your concern and agree that I did a mistake, my apologies.
Some backstory:
I, on behalf of the community team made the new announcement of a new mentorship program “Mentorship Program for New Ansible Release Managers” in the Forum but thought of it as just a continuation of “Call for Volunteers for Ansible Release Management”, in more structured way.
But unlike the last forum post (a year ago), this time a lot of people started responding and joining the program rapidly. The quick, enthusiastic response from the community is fantastic, but it also highlighted the need for more proactive communication with the release management team.
The sudden influx of participants meant the new program grew much faster than expected, which is a great problem to have—but it can also lead to miscommunication. I apologize again and take ownership of the oversight. Moving forward, a well defined heads-up in the release-management WG along with community WG channel about new initiatives will help keep everyone aligned and prevent future surprises.
Now I replying here addressing each of your concerns:
Who knew on the SC?
Gundalow and I came up with this idea for reviving the Release Management contribution by giving it a more structure way. So Gundalow knew about this from it’s very inception (over a month ago). In fact this isn’t just a random initiative, but a well-thought-out strategy to address a real need to bring back contributors (who left after we deleted their meetup groups) to re-engaging the Community. The situation with the Ansible Meetup groups and the risk of losing valuable contributors makes the program’s purpose even more compelling. The program serves as a proactive way to:
Bring back contributors: By providing a structured and engaging program, we’re giving former meetup organizers a direct path back into the community.
Prevent future loss of talent: This program helps to formalize a path for contribution, ensuring that even if external platforms change, there’s a clear way for people to stay involved and have their contributions recognized.
*Community retention and engagement tool: This program is not just about training release managers; it’s also a community retention and engagement tool.
The program’s development was shared internally within the whole Ansible Community team. I have been diligently publishing this in my internal status and jira issues for a month. So another SC member, Andrei, and Tray, member of release-management WG, knew about this.
This was brought up in public via forum post and Bullhorn announcements last year (May 2024) but there were no replies or much interest over the idea then (in contrast with now).
This detail highlights a common challenge in large, fast-paced projects: even when information is available in internal tracking systems, it can sometimes be missed or not fully absorbed by everyone in real time. The rapid influx of participants likely just accelerated the need for broader, more direct communication outside of those internal systems.
We have enough release managers
I understand your point about having enough release managers at the moment. It’s a valid point, and it’s great that the team has grown from one to five people, with three of them being non-Red Hatters. This is a significant improvement in diversifying the team.
However, relying on the current five people, especially with two of them (I and Tray) being Red Hat employees whose roles could change, presents a real risk. If either of us were to move to a different position, the team would lose a significant portion of its dedicated capacity.
This program directly addresses that risk by acting as a proactive succession plan. It’s not about adding more people to handle the **current workload; it’s about building a robust, long-term talent pipeline.
Here’s how this program benefits the team, even with the current number of release managers:
Future-Proofing the Team: The program ensures that there’s a continuous supply of trained and knowledgeable contributors ready to step into a release manager role if and when the need arises. This prevents a potential crisis where the team suddenly lacks the expertise to manage releases.
Knowledge Preservation: By creating a formal training framework, you’re not just training people; you’re codifying the release management knowledge. This process ensures that crucial information is documented and passed on in a structured way, rather than being held by a few individuals.
Building a Foundation of Trust: The program allows potential future release managers to gain hands-on experience and build trust with the community. When a new release manager is needed, you won’t have to start from scratch—you’ll already have a group of people with the required skills and a proven track record.
The program is a framework for passing on the knowledge (regarding release management, which includes antsibull-build scripts, increasing automation of the community-ee releases, and improving the release documentation are things that will help to make releases easier) to the interested people.
Other things that we should be directing people to Several of the things we would like people to contribute to, antsibull-build scripts, increasing automation of the community-ee releases, and improving the release documentation, are things that will help to make releases easier.
They are absolutely part of the broad umbrella of Release Mangement, so very much a part of the program. Having more people who care about the pain points of making releases is the best way to get contributors to these which means we need to make more people release managers.
I agree that testing collections is important as well. But it needs a driver, a dedicated mentor, to both work with the people who want to help and to refine the criteria. Unfortunately, I don’t have the required knowledge or time to do that now. But this is a very great idea for near future.
Benefits of the Release Manager Training Program (from community point of view)
This program offers several key benefits by establishing a formal process for training future release managers.
Improved Efficiency and Knowledge Transfer
Structured Onboarding: By laying out the steps and process for training new release managers, the program creates a more efficient and standardized way to bring new people up to speed.
Structured Knowledge Sharing: Instead of relying on ad-hoc learning, the program ensures that knowledge is shared in a more organized way. This helps prevent critical information from being lost or overlooked when a new person joins the team.
Increased Team Resilience and Capacity
Diverse Contributor Pool: The program brings in new contributors from different time zones. This provides a wider network of people who can answer questions and assist with tasks, reducing the burden on the current team.
Pre-Vetted Candidates: The program prepares contributors from a “readiness perspective,” meaning you will have a group of people who are already familiar with the process and have a solid foundation of knowledge.
Enhanced Project Visibility and Contributor Recognition
Shadowing Opportunities: The program allows new contributors to shadow current release managers. This provides an extra set of eyes on the release process, which can help catch potential issues.
Contributor Recognition: Participants who shadow release managers will gain recognition for their efforts, similar to the Kubernetes model. This can motivate new contributors and make the program more attractive to potential candidates.
What the Program Hopes to Deliver?
The program is designed to equip participants with the essential knowledge and skills needed for release management, including:
How to become an active member of the Release Management working group.
The process for reviewing pull requests related to release management.
How to handle and manage the Ansible Community Package release and the Community Execution Environment (Base and Minimal) release.
It’s important to note:
The program is a possibility, not a guarantee. It promises to enable people with the necessary knowledge and skills, but it does not promise to make them a release manager with immediate effect. Its main goal is to share knowledge and empower future contributors.
I hope this clarifies the questions and concerns, again I am truly sorry for lack of communication.
@gotmax23 Firstly, thank you for your message and holding us accountable.
The lack of communication to the Steering Committee is my oversight, not Anwesha’s. Finding new contributors (across all skillets, abilities and interest) is something we always talk about. With the changes to Ansible Meetup, we have some folks that reached our and expressed interest in helping on more of the technical side. As we had just onboarded Tray (part of my Ansible Community & Partner Engineering Team) to be able to do Community releases, Anwesha had the great idea to replicate the success we had there. We moved fast, and I didn’t communication.
Anwesha’s done a great job above explaining the rational for this, though please do ask if there are any further questions or ideas.
Though I just just want to highlight a couple of points I strongly agree with from your original post
I want to reinforce your comment here. While Ansible community is lucky to have great folks we can trust, that trust is earned. We don’t plan on giving anybody extra privileges (beyond maybe GitHub Triage), on this or or any project unless they have earned it. That is how we’ve always operated, AFAIK it works, so we have no plans to change this.
This is exactly the type of thing we are thinking, I appreciate the examples here.
Kind regards,
John “gundalow” Barker
Chair, Ansible Community Steering Committee
Thanks for the clarifications on this @anwesha and @gundalow! What you say makes sense to me.
However, the Ansible Release Management Room on Matrix has been somewhat private. Or let’s say: Only very few people who are involved in releasing the Ansible Community Package have been active there. It’s been a little irritating to see so many people showing up there volunteering to help with releasing. Actually, I started to wonder if this is some kind of social engineering attack…
Anyway, do we have any definite things we could ask those people to work on and really mentor them?
And another thing: Should we mention this thread there? My idea is to show those volunteers that they’re welcome, but also that there are some open questions. Maybe they could join this discussion and propose issues they would like to work on.