# GitHub Pull Request Reviews as O-1A Judging Evidence: What Counts? On HBO's Silicon Valley, Pied Piper's coders discuss whose code is worthy of merging in entire episodes; that debate makes for a very relevant case study on an aspect of O-1A qualifying activity: whether pull request review can be used as "judgment of the work of others." USCIS has not issued a GitHub-specific update to the [O-1A](https://eb1aexperts.com/o-1avisa) regulations or established a new criterion for open source contributors. However, judging is a neutral concept when it comes to platforms: It does not refer to conferences, journal submissions or specific repositories in the regulation. Therefore, one may be able to argue that documented participation in pull request reviews constitutes qualifying activity if the record proves that the individual in question judged the work of others in his or her field or allied fields. This piece examines what exactly the regulation entails, how GitHub activity could be fit into the required frame and what engineers should document prior to making it a part of their immigration records. [**Check Your O-1A Eligibility**](https://eb1aexperts.com/?utm_source=social&utm_medium=hashnode&utm_campaign=blog) **The Open Source Judging Criterion, Explained** Two requirements are included in this criterion, namely, involvement through personally or panel-wise acting as a judge for somebody's work in the same or related field as compared to the field specified in the classification. Both do not mention anything about the platform, which means that one will have to explain the [GitHub](https://eb1aexperts.com/github-o-1a-judging-evidence-do-pr-reviews-qualify?utm_source) screenshots in terms of the criterion. The regulation does not say anything about the possibility to merge and reject contributions, nor the contributor having to be from outside the employer of the petitioning person. GitHub provides evidence regarding involvement in the form of review process described by the maintainer, [CONTRIBUTING.md](http://CONTRIBUTING.md) or CODEOWNERS files mentioning a reviewing position, or dated thread with technical evaluation. Unaffiliated contributor reviews are easier to classify as independent reviewing, although independence is not necessary for the latter, only peer review distinct from regular collaboration. ![](https://cdn.hashnode.com/uploads/covers/6a1d09ac4a5db3cb7e64d850/186c6ed4-7457-4a7d-b8b0-8a1d507c800b.png align="center")

Evidence Pattern

Assessment

Maintainer review of external PRs, with substantive comments and confirmed role

Potentially strong

Core-reviewer or technical-committee role, with documented history

Potentially strong if governance materials corroborate it

Internal peer review of colleagues' work

Context-dependent; needs proof it was distinct from collaboration

Collaborator status or a review invitation alone

Insufficient alone: access, not completed judging

Personal repository with no third-party submissions

Does not establish judging of others

Automated or formatting-only approvals

Likely weak; may not show real evaluation

It is difficult for people to distinguish between an invitation to review and completion of the review. One is required to be invited to review or collaborate in order to document that access occurred, not judgment or review. The very same point has been made by USCIS in regard to an official invitation to conduct a review. (Miller Mayer, AAO EB-1A decision review) **Who This Applies To** Historically, O-1A petitions from engineers were based on originality and importance because the judgment seemed tailored for the likes of journal editors and grant committees. Judging with documentation can become an additional criterion to the already existing seven criteria without substituting this method. It applies mostly to engineers who maintain or review externally in addition to their employers. In the case when an engineer maintains an internally developed library there would be nothing much to build from, as no external work needs to be judged. An engineer who reviews external contributions and/or is part of a rotating team of reviewers for a foundation would start from a better position, not because independence is needed but simply because it will be easier to document it as a process of judging. The distinction is a pattern of judging the work of others by the engineer with actual decision made each time. **Modernizing the Bar, Not Lowering It** Nothing reduces the standard here; if anything, it actually increases the standard of documentation, because stars, forks, and downloads do not in themselves prove a standard of judging, although they can back up an original contribution of great importance or a key role. A petition that relies solely on its popularity is no more persuasive today than it was in 2020; but a petition that rests on documentation proves that the standard was always designed to handle that situation. **Evidence Engineers Should Start Collecting** * Governance records indicating maintainer/core-reviewer designation: [CONTRIBUTING.md](http://CONTRIBUTING.md), CODEOWNERS, or foundation site mentioning such a designation. * Sample substantive reviews, not merge notifications: review comments, suggested changes, and rationale behind those. * Contributor identity for the reviewed contribution(s), especially if it is not the contributor's employer; not necessary but makes for a better judging of separate judging of something. * Proof of adoption beyond mere popularity: dependency graph, or CVE/security advisory mentioning that the contribution caught a flaw through the review. * Corroborating letter by project lead, foundation member, or another maintainer about the role. * Judging venues beyond just code reviews: hackathon judging panel, awards committee, accelerator judging panel. Several roles from different venues are better than many roles from a single venue. Dated, corroborated proof is better than screenshots, showing not only what happened but when and what role the petitioning individual played in it, even though there is no specific USCIS guidance about screenshots. **Beyond the Criterion: The Totality Standard** This particular judging criterion was created by the academic community – peer review, editorial boards, grant panels, competition juries. In software, there was no corresponding concept until fairly recently. This was one of the reasons for which the concept of original contribution and importance came to be a default technical approach. Open source governance developed an analogous system of judgment that consisted in a publicly verifiable timestamped evaluation of one engineer’s work by another based on the same criterion, but not bending of rules by USCIS. Meeting the judging criterion is merely a necessary condition, not a sufficient one. The O-1A visa category requires meeting at least three out of eight criteria and then a final determination of the merits in order to ascertain whether the individual enjoys sustained acclaim and is among the very small percentage of individuals in the field. (USCIS Policy Manual, Vol. 2, Part M, Chapter 4) **FAQs** **Is there an official USCIS "GitHub judging update"?** Not at all. There is no such regulation in USCIS’s policies that mentions GitHub, pull requests, or code reviews. The attorneys are currently using documentation related to GitHub review activities based on the current standard. **Who does this apply to most?** The engineers who have some kind of maintainer or core reviewer rights in those projects where third-party contributions are allowed. Only those people would benefit the most from it since other metrics will not help. **Does this lower the bar for O-1A or just modernize it?** The latter – the evidence is modernized, but not the bar. In other words, poor evidence, such as the number of stars, or an uncompleted invitation will always be poor evidence. Reviewing the works of unaffiliated contributors can serve as the basis for the evidence, but the petitioner will have to provide corroboration as well as a valid case that stands up under the merits determination. **What evidence should engineers start collecting now?** Documentation about governance showing the reviewer was authorized, substantive review comments, corroborating correspondence, and documentation that the contributor who did the review was unaffiliated at the time. By building it up gradually rather than retrospectively, this can provide better evidence. **Is this evidence type treated consistently across adjudicators?** It depends; as would be expected of a criterion applied to new evidence without a specific GitHub rule, consistency is variable. Cases where petitions rely on unclear evidence, incomplete invitations, or affiliated contributor reviews are more likely to result in an RFE. **The Bottom Line for Engineers** Engineers can avoid waiting for USCIS to put GitHub on its list of eligible platforms in its policy memo, which might never happen. The standard itself already allows for substantial, documented review of code, and all they have to do is document that. Those who aren’t sure whether their work as a maintainer or reviewer qualifies should get an evaluation of their case prior to filing. [EB1A Experts](https://eb1aexperts.com/contact-us?utm_source=social&utm_medium=hashnode&utm_campaign=blog#calendar) advises technical petitioners in how to approach this problem. [**Start Your O-1A Profile Evaluation**](https://eb1aexperts.com/contact-us?utm_source=social&utm_medium=hashnode&utm_campaign=blog#calendar) *Disclaimer: This content is for general informational purposes only and should not be considered legal advice. Immigration pathways vary by individual profile. Always consult an immigration professional before making decisions.*