Hi Everyone,
Jeremy mentioned the Forum session on this topic, which was scheduled for Tuesday (September 3) week at the OpenInfra Summit Asia. I moderated the session on behalf of Jeremy, and reaching out here to share a recap.
We had a great conversation with people who were able to join the discussion at the Forum session. Below is a brief summary of what the group talked about, which included sharing experiences and brainstorming about ideas to reduce current challenges that people are facing, both newcomers as well as casual and established contributors. Our conversation touched on three main areas, which were challenges, solution ideas and next steps.
Challenges - We have less active developers and maintainers * Vendor companies have been the main group of organizations who invested in OpenStack development upstream, but those investments have reduced by today * Operators, who are around, have less capacity to work upstream, and their focus is more on bug fixing than adding new features - False assumptions * Maintainers have full-time allocation to work on OpenStack * Code review is the only way, outside of code contributions, for companies to provide meaningful help to the community - Project team priorities need to be more clear, and project management type of work is required to use the teams’ bandwidth more efficiently * Sometimes the process is in place, but not visible for people who are not engaged on IRC, etc - Even in case of established contributors, they often need to ping people on an ongoing basis to get their reviews to move forward, this method does not scale
Solution ideas - Education on open source investment and forms of involvement needs to continue * Companies still spend big chunks of money on proprietary SW development, they need to understand the reasons and benefits to also invest in working on open source projects they rely on, such as OpenStack - Documented and visible processes * OpenStack project teams need to revisit their processes to make sure that the contributors are spending their time and efforts efficiently * When processes exist they also need to be discoverable by everyone, without the need to talk to an established contributor or maintainer - Code review is not the only area where maintainers need help. When an individual or comany, like an operator, has expertise in particular features or areas of the code, their input is needed and desired when changes are made to those parts of the code. - Tooling is not the solution to many of the challenges, so we need to focus on solving the social issues
Next steps - Documentation and making existing processes visible, folks from the Nova team made a commitment to update their existing documentatoion to make it up to date and contain their current processes on how they do project management for the team * The Nova team also started to track bug fixes as part of their process to track changes and have the ability to prioritize, in recognition how that is an area where operators often get involved - Start small and replicate practices that works in the wider community * When project teams find ways that help their work, the community should consider exploring and adopting those techniques more widely
For more detailed notes, please check the etherpad we used for the session: https://etherpad.opendev.org/p/r.914969755fedc5c6fa58d7e9881ffa66
Those who attended the Forum session, please chime in with any further thoughts and notes on anything that I missed to mention, and to continue the conversation.
Those of you who did not have the opportunity to participate in the Forum session, what from the above summary and notes on the etherpad do you resonate with? Which experiences do you have as well and what solution ideas have you tried already?
Best Regards, Ildikó
———
Ildikó Váncsa Director of Community Open Infrastructure Foundation
On Aug 29, 2024, at 4:18 AM, Jeremy Stanley fungi@yuggoth.org wrote:
On 2024-08-21 15:18:12 +0000 (+0000), Jeremy Stanley wrote: [...]
The most common themes reported by those struggling to contribute are not related to tooling or workflow confusion, but instead seem to come down to basic communication challenges.
[...]
Last week, Jens mentioned this article in IRC:
https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/code-review-antipatte...
Coincidentally published the same day I posted the first message in this thread, it's an amusing semi-satirical look at many of the same challenges our community has also identified. A quick summary of the author's points (though I strongly encourage you to check out the full article if you have time):
- Batch up review feedback and try not to "move goalposts" by
repeatedly coming up with new problems in subsequent reviews that you could have found the first time through (i.e. don't just stop reviewing on the first issue you find).
- Don't demand a change author include unrelated fixes to nearby
code (pointing it out as optional in case they want to tackle it if they have time is fine, just be clear it's not a requirement of approval).
- Try to reach a consensus of opinion with other reviewers on the
same changes/project, and avoid jerking the author around by changing your own opinion on things.
- If a proposed implementation is unsuitable, be clear about what
kind of alternative implementation would be suitable.
- Lead with the most important problems in a change, not the trivial
ones.
- When reviewing individual changes that are part of a larger
approved specification, try to focus on whether those changes implement the spec as written regardless of whether you agree with choices the project has made within the spec (if you disagree, get the spec changed or amended first).
- Extremes of opinion can always be found to reject a change, so
look for a position of compromise when possible.
- Be cautious and deliberate about shifts of expectation over time,
since authors are prone to replicate patterns from prior changes and existing code.
I think articles like this help to confirm we're on the right track, and I find it a reassuring reminder that these are challenges pretty much all communities struggle with. We're not alone. If we can come up with viable approaches for improving the situation, we'll be helping not just our own community, but open source software projects everywhere.
Also, a quick reminder: If you'll be in Suwon for OpenInfra Summit Asia or Indianapolis for OpenInfra Days North America, come to the forum session (Bridging the Gap: Community and Contributing Orgs). Whether or not you're available for the in-person sessions, replies to this mailing list thread can help refine the community's approach to contributor communications so we can start to get some of these things documented in relevant places (Contributor Guide, Project Team Guide, et cetera). -- Jeremy Stanley