The world’s software depends on open source projects, so it’s important that open source maintainers can spend their time productively. We’re excited to share new features aimed at increasing the quality of contributions and helping maintainers focus on what matters most to the success of their projects.
First, we’ve heard from many maintainers that they love collaborating with external contributors, but spammy pull request approvals and requested changes are frustratingly common.
To address this, we’ve added code review limits. Maintainers can now limit who can approve and request changes on pull requests. At the repository level, a maintainer can limit approvals and requested changes to only those users who they have explicitly granted read or higher access as follows:
- To enable code review limits for a repository, go to the repository’s Settings page and select Moderation settings from the left menu.
- Click Code review limits and then check the Limit to users explicitly granted read or higher access box.
Maintainers can also enable code review limits across all repositories associated with their user or organization account. To do so from the user or organization settings page, follow these steps:
- Under Moderation settings, click Code review limits.
- Click the Limit reviews on all repositories button.
After a maintainer has enabled code review limits for a repository, when a user without explicit access starts a pull request review, they won’t be allowed to approve or request changes, and a tooltip will explain why. They’ll still be able to leave a comment.
This feature started as an internal hackathon project by a small group of motivated members of our Communities team, who maintain a number of our open-source projects, including the community-curated content on our Explore pages. In under three days, the team identified spammy approvals and requested changes as a problem they wanted to address, built the first version of code review limits, and filmed a demo. After some iteration, polish, and internal testing, we’re excited to make code review limits available to all maintainers.
Second, we’ve heard that the GitHub mobile app is a fantastic tool for triaging notifications, but we’ve also heard that it’s difficult to use the app to act on spammy issues and pull requests. When you see a spammy issue or pull request pop up in your mobile notifications, you can now easily close the issue and block the user from your organization right from your phone.
These two new features help maintainers focus on meaningful contributions, but they’re not the only ways we’ve recently focused on quality-of-life improvements for open source communities. This year, we’ve made progress on several broader initiatives to improve the experience for open source maintainers:
- Issue Forms: Ensuring that users provide enough context in new issues can be challenging. With issue forms (currently in beta), you can create issue templates with form fields, including required fields, that can make issues more actionable.
- GitHub Discussions: Recently out of beta, GitHub Discussions gives open source communities a space to come together, converse, and help one another. Discussions help you reduce the volume of issues and enable your communities to better self-serve their needs.
- GitHub Sponsors: By allowing companies and developers to invest in the projects they depend on, GitHub Sponsors makes open source more sustainable. With recently launched custom amounts and one-time payments, there are even more ways to support maintainers.
We’ve been working hard to improve the experience of maintainers on GitHub, and we hope each of these features will continue to make open source communities stronger, healthier, and more sustainable.