How the research works

One question, three settings

What does an open-source review record (a pull-request status, a passing build, an approval, a disclosure line) actually establish, and what does it leave unknown?

• Language. A translation that passes continuous integration has not necessarily been read by anyone who reads the language. The localization gap is an infrastructure problem as much as a translation problem. Language inclusion workstream (opens in a new tab)
• Accessibility. Review volume is not review quality: in the seven accessibility pull requests studied, the most heavily reviewed tied for the lowest score. How the review rubric works (opens in a new tab)
• AI contributions. A disclosure line does not show what was verified. The policy catalogue records what projects actually require. 21 policies compared (opens in a new tab)

Evidence rules

1. Primary sources first: files, commits and timelines, then human review, then automation, then releases.
2. Bots are not counted as human reviewers, and a passing check is not assistive-technology or language verification.
3. People are described by their recorded role on the project (for example, collaborator or contributor), never by assumption.
4. Policies are quoted from the text a project adopted, not from proposals or reporting about them.
5. “Unknown” is a valid finding. Intent that isn’t on the record is not inferred.

What the samples can and cannot show

The samples are small and chosen on purpose: seven accessibility pull requests, six localization contributions, 21 AI contribution policies. They are selected because they show a process clearly, not because they are representative. Findings are patterns in these samples, never rates or rankings.

The work studies how review processes handle contributions. It does not judge the people involved.

Keeping claims current

• Dated. Every case study and catalogue entry states when it was last verified against its source.
• Checked weekly. Automated checks flag changes to the policy sources and new activity on the case-study threads, so they can be re-verified.
• Corrected in public. Corrections are logged in each repository, for example the language inclusion corrections log (opens in a new tab). Web pages are updated in place; published articles remain as published, and later corrections are recorded in the repository.
• AI assistance. I use AI tools to help structure writing and to check sources. Every factual claim is verified against primary sources, and the conclusions are my own.

Challenge the work

Disagreement is useful evidence. These open questions are the best place to start:

• Do the localization patterns match real translation-review practice? (opens in a new tab)
• Validate the accessibility review rubric (opens in a new tab)
• Is verification, not detection, the right primitive for AI contribution policy? (opens in a new tab)

Everything else that needs help is on the initiative’s how you can help page (opens in a new tab).