Red CI, Clean Code: What Three Selenium PRs Taught Me About Contributor Attrition

When my last PR was not merged, I felt discouraged. If it had merged, I would have raised another one immediately. That is what a red CI badge does to a contributor, not just delay a merge, but interrupt the momentum that keeps people coming back.
When I analyzed the CI failure logs of three recent Selenium pull requests, I found the same pattern every time. PR #2589 replaced a lambda workaround with a purpose-built expected condition, only test_alerts.py , and four markdown files changed. CI failed in test_firefox.py and test_network.py. Files I never touched. PR #2671 bumped a JavaScript dependency from 8.19.0 to 8.21.0, only package-lock.json changed. CI failed in browsingContext.spec.js with timeout errors. PR #2666 bumped a YAML library from 4.1.0 to 4.2.0, again, only package-lock.json changed. The same browsingContext.spec.js timed out with the same error.
Three different PRs. Three different languages. Three different types of changes. One outcome: red CI on files nobody touched.
A new contributor, seeing that red badge, will assume their code is wrong. They will rewrite the correct code, trying to fix a problem they did not cause. Some will open a question. Many will quietly stop contributing before a reviewer can tell them the failures were already there.
What is missing is not better code. It is a simple guideline, one that does not currently exist in Selenium's contributor documentation, explaining how to read CI failures and distinguish pre-existing failures from your own mistakes in under five minutes.
This talk uses those three verified PRs to show what CI debt costs at the contributor level and what one addition to a contributor guide can do to stop the silent attrition it causes.

• What I found when I compared CI logs across three unrelated Selenium PRs, and what it reveals about pre-existing failures

• Why a new contributor cannot tell the difference between their mistake and infrastructure debt without reading hundreds of lines of logs

• A five-minute triage approach for reading CI failures that any contributor can apply before assuming their code is wrong

• Why CI signal quality is a contributor retention problems, not a tooling problem

• What one addition to a contributor guide would have changed my experience, and what it could change for every contributor who comes after