Evidence Building
How to Build the Judging Criterion from Open-Source Project Maintainership and Code Review Service
Open-source maintainership and standards body review work count as judging under the O-1A criteria, but they require specific documentation to satisfy USCIS. Here is what records to assemble, how to frame maintainership as peer evaluation, and which review activities USCIS regularly discounts.
The judging criterion and technology professionals
The judging criterion under 8 C.F.R. § 214.2(o)(3)(iii)(A)(3) was designed with traditional academic peer review in mind — the kind of formal manuscript review conducted by journals and grant panels. For scientists, the pathway is well-understood: collect invitation letters from journal editors, document grant panel service, and present the record as evidence that recognized authorities in the field sought the petitioner's expert evaluation. For technology professionals applying for O-1A status, however, the natural forms of peer evaluation look different. Open-source project maintainership, technical code review on major repositories, and participation in standards body review processes are the field's functional equivalents of academic peer review, but they require careful framing to satisfy the regulatory criterion.
USCIS adjudicators reviewing technology O-1A petitions regularly encounter this translation problem. The regulation's text speaks of judging the work of others, but it does not specify that the judging must occur within a formal academic or institutional context. AAO non-precedent decisions have accepted a range of judging formats, including technical evaluation panels for industry competitions, external code audits for significant open-source projects, and invited technical reviews for standards development organizations. The petition strategy is to identify the technology professional's specific judging activities, determine how closely each maps to the regulatory model, and present the record with expert framing that explains the field's peer evaluation practices to adjudicators who may not be familiar with them.
The practical challenge is that open-source maintainership and code review are often informal — they are conducted through public platforms without formal invitation letters, titles, or institutional documentation. A maintainer of a major open-source library who evaluates and accepts or rejects hundreds of code contributions per year is performing a technically demanding expert evaluation function, but the documentation of that service does not resemble the letterhead-stamped invitation from a journal editor that USCIS is accustomed to seeing. Building the judging criterion from this record requires a specific documentation strategy rather than a simple collection of platform activity records.
What the regulation actually requires
The full text of the criterion under 8 C.F.R. § 214.2(o)(3)(iii)(A)(3) provides: evidence of the alien's participation, either individually or on a panel, as a judge of the work of others in the same or an allied field of specialization for which classification is sought. The key components are: participation as a judge, which implies a systematic evaluative function; of the work of others, meaning the beneficiary's role is evaluative rather than collaborative; in the same or an allied field, which establishes the relevance connection; and for which classification is sought, which ties the judging evidence to the beneficiary's claimed area of extraordinary ability.
USCIS's Policy Manual clarifies that the criterion requires evidence of actual participation, not merely availability or capacity to serve as a judge. A letter from an organization stating that the beneficiary is qualified to review work in the field, without documenting actual completed reviews, does not satisfy the criterion. The evidence must show that the beneficiary has actually evaluated others' work in a way that involves expert judgment about quality, correctness, or significance. Pull request reviews on a major open-source repository, where the maintainer assesses whether contributed code meets the project's standards, is an evaluative act that involves expert judgment — but the petition must present evidence that the reviews actually occurred and that the maintainer's role involved genuine discretionary evaluation.
The question of whether the judging was voluntary or paid, invited or initiative-taken, does not appear in the regulatory text. USCIS has accepted both paid and unpaid review service in approved petitions, and the AAO has not required that judging be formally solicited in all cases. What matters is whether the evaluation function is documented, whether it involves expert judgment, and whether the field would recognize the evaluation role as significant. A repository with 50,000 active users where the petitioner has served as a core maintainer for three years presents a qualitatively different record than maintainership of a repository with a handful of users — field significance must be established, not assumed.
Evidence that routinely satisfies this criterion
The strongest open-source judging evidence combines documentation of the repository's significance with records of the petitioner's actual review activity. A contribution history showing hundreds of pull request reviews, combined with a declaration from the project's founding team describing the petitioner's role in technical evaluation, creates a two-part record that directly addresses the regulatory criterion: participation documented by contribution records, evaluative authority explained by expert declaration, work of others established by contributed code records, and field relevance established by the repository's subject matter and adoption evidence. The project's documentation should establish its significance — download statistics, adoption by named commercial organizations, coverage in technical press — to confirm that the beneficiary's gatekeeping role carries field-level significance.
Technical review service for standards organizations provides particularly strong evidence because the formal invitation structure is clearer. The IETF, W3C, ISO/IEC JTC 1 working groups, and IEEE standards committees all involve formal review processes in which named experts are invited to evaluate proposed technical standards. A participation record in these bodies — including meeting minutes, working document contributions, or formal ballot records — documents judging activity in a format that USCIS finds immediately recognizable. The standards body context also establishes that the invitation was based on the petitioner's recognized expertise, addressing the implicit credentialing question that maintainership records alone may leave open.
Internal code review records from employment can supplement open-source records where the petitioner has served in a formal technical review function at a major technology organization. A senior engineer designated as the technical reviewer for a critical infrastructure component, or a principal engineer who served on an internal architecture review board, has performed documented expert evaluation of others' technical work. These records come from employer documentation — internal process records, role descriptions, or declarations from engineering managers — and should be accompanied by expert context explaining the significance of the review function within the specific technical domain.
Evidence USCIS regularly discounts
Generic contribution records without supporting context are regularly discounted. A profile showing thousands of commits and pull request reviews on many repositories does not, by itself, satisfy the criterion — the record must identify specific projects where the petitioner's evaluative role is documented and the project's significance can be established. Diffuse contribution activity across many minor repositories is less persuasive than concentrated maintainership of a few significant ones. USCIS adjudicators are not expected to evaluate all contributors to determine which projects are field-significant; that assessment must be done in the petition itself through organized exhibits and expert framing.
Collaborative code review — where two engineers review each other's work as peers, neither holding superior evaluative authority — is generally not sufficient to establish the judging criterion on its own. The criterion requires that the beneficiary evaluated others' work in a way that involves discretionary judgment about quality and acceptance. Mutual code review among team members of equivalent seniority resembles peer editing more than it resembles the peer review structure the criterion contemplates. Petitions presenting only this type of review record, without a distinct evaluative authority function, typically receive RFEs requesting clarification about the petitioner's specific role and authority within the review process.
Invitations to review that were not acted upon, or that resulted in declining reviews, do not satisfy the criterion. USCIS has noted in RFE language that the evidence must demonstrate actual participation, not only capacity or invitation. Similarly, serving as a moderator for a technical discussion forum, answering questions on developer platforms, or maintaining documentation for an open-source project are contributing activities that do not involve the evaluative judgment over others' original work that the judging criterion requires. These activities may support other criteria — such as original contributions or recognition from experts — but should not be presented as judging evidence where they do not involve discretionary acceptance decisions.
Presenting borderline evidence
Many open-source maintainers face the practical challenge that their judging activity was never formally recognized with a title, invitation letter, or institutional acknowledgment. A developer who became a core maintainer of a major project through years of sustained contribution may hold the evaluative authority without formal documentation of how that authority was conferred. The petition must construct the record from available evidence: the project's maintainer hierarchy documentation if available, the repository's contribution history, a declaration from another core maintainer or the project's founding organization describing the petitioner's evaluative role, and an expert declaration from a recognized figure in the technology field explaining the significance of maintainership in the relevant open-source community.
Where the project lacks a formal maintainer designation, the petition can document the functional equivalent through pull request records. If the petitioner's reviews resulted in accepted changes — where the petitioner's approval was required before a change was merged — that approval authority constitutes an evaluative function even in the absence of a formal title. Export statistics, downloads, and named organization adoption establish the project's significance and thereby the significance of the petitioner's gatekeeping role. A project used in production by multiple large commercial organizations provides materially different field-significance context than a personal project with a handful of users, and the petition should document that adoption record specifically.
Technical review invitations for conference paper submissions — such as reviews for NeurIPS, ICML, ICLR, ACL, or EMNLP, which include formal reviewer invitations — provide a hybrid evidence type that combines formal invitation structure with field significance. Technology professionals who have served as program committee members or reviewers for major computing conferences have documentary evidence that closely tracks the traditional peer review model. These invitation records should be presented before maintainership evidence where both exist, and the petitioner's maintainership should be framed as an additional field-appropriate form of judging service that supplements rather than substitutes for the more formally documented conference review record.
Building and auditing your judging criterion file
A complete judging criterion record for a technology O-1A petitioner should include three categories of documentation: evidence of the repositories or standards bodies where judging occurred; evidence of the petitioner's actual evaluative activity within those contexts; and expert framing of why that activity constitutes significant peer evaluation in the field. The first category typically comes from publicly available records — repository pages, standards body participant lists, conference reviewer acknowledgment pages. The second category comes from activity records — pull request review histories exported from the repository or meeting participation records from standards bodies. The third category is supplied by expert declarations drafted with the attorney's guidance.
A pre-filing audit of the judging criterion record should evaluate whether each piece of evidence addresses the regulatory components: participation evidenced by activity records, evaluative authority documented through maintainer designation or review decision records, work of others established by pull request or submission records, and relevance to the beneficiary's field established by repository subject matter and expert declaration. Where any component is missing or weak, the audit identifies the gap before filing. A record that is strong on activity volume but weak on field significance, or strong on repository significance but weak on documented evaluative authority, needs specific supplementation before submission.
The cover letter section presenting the judging criterion should walk adjudicators through the equivalence argument explicitly: open-source maintainer review of contributed code is the functional equivalent of academic peer review in software engineering and related disciplines, the beneficiary's review records document sustained expert evaluation of others' original work, and the field-significance of the repositories makes the evaluation function comparable in prestige to invited journal review. This explicit equivalence framing, supported by expert declarations from recognized figures in the technology sector, is more reliable than assuming that adjudicators will recognize the connection without guidance.
What we typically gather for this kind of case
| Document | Where to source | Why it matters |
|---|---|---|
| Expert letters | 5–8 independent recognized experts | Quality and independence beat volume |
| Certified translations | ATA-certified translator | Required for any non-English source document |
| Exhibit cover sheets | Drafted by counsel, one per exhibit | Tells the adjudicator what each piece shows |
| Bibliometric reports | Web of Science / Scopus | Quantifies impact for original-contributions criterion |
What we see go wrong, again and again
- 01Sending exhibits without a one-paragraph framing memo explaining what each shows and why it matters.
- 02Relying on volume over specificity — five well-targeted expert letters beat fifteen generic recommendations.
- 03Skipping certified translations or using AI translation for foreign-language source documents.
See if you qualify
Lando reviews your background against the O-1 visa criteria and tells you honestly where you stand. Free, no commitment.