ossWhat do you think is the most typical reason for delays in pull request reviews? A study at Google confirms that it’s the size—the more changes, the slower the review. Another study shows that it’s the emotional tone—anger and dominance expressed in comments are linked to a lower likelihood of a pull request being merged. A more recent study finds that it’s the author’s reputation: we merge PRs faster if we know the author. All of the above is true. In our projects, though, what often slows down PR reviews is the message: “CI failures are not related to my changes!”
Here’s how it happens: You fork a repo. You make changes to fix a bug or introduce a new feature. You commit them and push. You submit a pull request. You realize that some GitHub CI jobs fail. You read the logs. You don’t see any relevance between the error messages and your edits. You post a comment: “CI failures are not related to my changes!” You expect us to merge your pull request.
Why shouldn’t we?
We don’t merge them. We ask you to step back—to the point before you started making changes. Don’t make them yet. Instead, check the build status of the repository. Pay attention to all CI jobs, not just the one running Maven. They all must be green. Only when all jobs are green should you start editing the code. If any job is red, report a bug and wait until the team gets everything passing.
Why? Because we try to reduce the effort required to fix the build. The more changes we pile onto a broken build, the higher the cost of cleaning it up. When the build is broken, we accept no new changes—except those that fix the build.
What if the team takes too long to fix it? What if the build never becomes green? Still—you wait. You don’t submit a pull request to a repository with a broken build.
You may fix the build yourself. If you do, submit it in a separate pull request. Don’t mix build-fixing changes with any other edits.
