Are We On The Same Page | Yoseph

Have you ever wondered if contributors and maintainers really see eye-to-eye in open-source projects?

Our recent research explored this very question: How aligned are contributors and maintainers in their perceptions of the code review process? The answers reveal subtle yet important differences that could shape the future of open-source collaboration.

For this study, we focused on the distinct roles of maintainers and contributors—maintainers review and approve contributions, while contributors submit code for review.

🎯 Purpose of the Research

Code reviews are not just technical checks—they’re also social interactions involving people with different backgrounds, goals, and priorities. We wanted to understand how much maintainers and contributors share the same expectations, and where gaps emerge that could lead to misunderstandings or perceptions of bias.

🔬 Methodology

We conducted surveys with 289 developers from 81 active GitHub projects, complemented by in-depth interviews with 23 contributors and maintainers. We also reviewed project documentation to see how well it reflected real-world practices.

📊 Key Findings

Both groups agreed that correctness and quality are essential for any successful code review. However, maintainers placed a much higher emphasis on how well contributions align with project goals—only 6.5% of contributors shared this view, compared to 15% of maintainers.

Contributors often overestimate the importance of novelty in their pull requests, while maintainers stress the need for a clear rationale explaining why a change is important and how it fits with project priorities. This mismatch can create friction and discourage future contributions if contributors don’t receive clear feedback.

Maintainers frequently struggle with limited time, leading to delayed reviews or incomplete feedback. Contributors sometimes perceive these delays or rejections as bias, especially when documentation isn’t clear about project goals and expectations.

One particularly interesting insight was the frequent misinterpretation of approach differences—such as coding style or preferred tools—as bias. In reality, these are often just differences in perspective, not unfair treatment.

We also found that familiarity bias—where maintainers favor known contributors—remains a challenge, discouraging newcomers and limiting the pool of contributors.

💡 Implications

These insights matter for everyone in open-source:

Contributors can help by not just highlighting what’s new in their pull requests, but also clearly explaining why their changes matter and how they fit within the broader project goals.
Maintainers can foster a more inclusive community by being aware of unconscious biases—like familiarity bias—and making an effort to welcome and support newcomers.
Researchers and tool builders can explore opportunities to design better tools that automate routine parts of the review process, freeing maintainers to focus on what really matters. Another avenue for research (which we’re currently exploring) is how tools that help developers comprehend large projects more easily could also speed up onboarding for new contributors and help graduate existing contributors into maintainer roles.

🧭 Limitations & Next Steps

Our findings are most relevant to large, active open-source projects. Smaller or more informal communities may have different dynamics. Future work will explore these differences and test tools to reduce bias and improve inclusivity.

🗣️ In Closing

We’d love to hear your thoughts. Have you noticed these challenges in your own projects? Let’s keep the conversation going and work together to make open-source communities more inclusive, innovative, and aligned.

You can read the full paper here. If you’re interested in follow-up projects based on these findings and other studies we’re conducting, check out the details on our group website. If any of these projects resonate with you, please get in touch with your feedback and help shape our work moving forward!