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.