Hi OpenStack Community, I’m reaching out to you about some next steps after the metrics and survey analysis for the Flamingo cycle. As we’ve been diving into data[1] and feedback[2] to better understand challenges that contributors and maintainers in OpenStack are facing, we reached the stage to start working with teams on improvement ideas. A few challenges stood out for us, like mismatched expectations caused by incomplete communication or silence, or inconsistencies in where maintainers track priorities and progress and where contributors look for this information. While more people to do reviews and maintenance work is always in need, clear and proactive communication practices can improve maintainer and contributor experience across the board. Below is a summary of the key ideas that Jeremy started to share with teams, to start experimenting with: 1. Make Review Priorities Explicit, and Don’t Forget to Keep Them Up to Date While many teams already document and publicize their review priorities and decision-making processes, the last survey round showed that contributors are often not aware of where to look for this information. Since there’s no single entry point into the community, mentioning the processes and pointing at resources is often helpful, like linking to priority criteria in review comments so contributors understand where their change fits and how they can engage in reprioritization discussions. Transparency here reduces uncertainty and helps contributors plan effectively. In addition, even when a team has a clear process to define, document and track priorities, information can get lost between release cycles. Adding it to the end-of-release tasks to update progress on ongoing items and deal with the ones that didn’t conclude in the cycle ending can improve contributor experience and help with more accurate planning for the upcoming cycle. This also means to check on the incomplete items at the start of the next release cycle and factor in that ongoing work when calculating bandwidth and availability. 2. Proactively Communicate Reviewer Availability It’s very easy to assume that project maintainers are available to do reviews full time, even more seasoned contributors make this mistake from time to time. Clear communication can ease the pressure on maintainers. This can include signals about reviewer bandwidth, upcoming absences, or looking for people who can take on ongoing reviews for some time can significantly reduce ambiguity. When contributors understand expected wait times—and are encouraged to share their own availability—coordination improves and stalled reviews can decrease. 3. Use Clear, Accessible Language Given that English is not the primary language for much of our community, we should avoid excessive acronyms and team-specific jargon. Clear, plain language lowers barriers to entry and reduces avoidable misunderstandings. It also helps new and casual contributors to feel more included and can increase the probability of them sticking around. 4. Develop Contributor and Reviewer Checklists Once the release cycle gets busy, it’s easy to forget about some of the above mentioned new practices before they become a habit. To help overcome that, we are also working on simple checklists to guide reviewers when leaving comments on new or in-progress changes. These will serve as lightweight guardrails for both new and experienced contributors and maintainers to further improve efficiency without added complication or burden. 5. Provide Reusable Review Templates Some of the above practices can result in broader comments in reviews, which can feel like a burden to reviewers and maintainers. We are working on creating response templates for common review scenarios, which you can fine tune for your project and context and then copy and paste into ongoing reviews where applicable. Templates can increase efficiency while reducing the time spent on phrasing review comments and making sure all useful information and resources are shared. Some teams have already been following this practice, which we will use as inspiration. You can also think about templates as a way to get through your review checklist quicker. 6. Publish Case Studies of Successful Contribution Models and Practices Some project teams seem to handle pressure and incoming load better than others, which can serve as inspiration for others to figure out what practices and methods to implement. This also applies to companies who have their employees working upstream, as in some having better practices to support their people than others. We aim to collaborate with teams and companies and teams alike to capture practices that yield better productivity without burnout. Documenting what works as case studies can help project teams and companies to understand how to implement practices in their own context. While we work on refining improvement ideas and sharing additional details we welcome your feedback and help to let us know what worked for you, and what practice didn’t produce the outcome or improvement you and your team hoped for. Some project teams are also experimenting with AI, to use it to speed up code reviews and navigate their tasks easier and more efficiently. While these practices are not yet ready to share widely as standards, OpenInfra community managers are curious to learn about your experience so far! We will schedule a session for the upcoming PTG[3] in April to discuss ideas and next steps further. Best regards, Ildikó [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... [3] https://openinfra.org/ptg/