Original Contributions: как правильно оформить open-source вклад в USCIS (инструкция 2026)

Для критерия original contributions of major significance в USCIS оценивается не объем активности, а доказанная связка: что именно было создано, почему это имело значение для проекта или отрасли, и как видно, что вклад принадлежит заявителю. В open-source эту связку можно собрать сильнее, чем в закрытом корпоративном коде: есть публичные issues, pull requests, release notes, обсуждения maintainers, changelog, adoption metrics и downstream-зависимости.

Ваша задача — не просто показать активность, а убедительно объяснить: какую проблему вы решили, что именно сделали, почему решение было неочевидным, как его приняли и какой эффект оно дало. Этот материал поможет вам структурировать доказательства для O-1, EB-1A или других категорий, где требуется подтверждение оригинального и значимого вклада.

Как выбрать «оригинальные» задачи в open-source для USCIS

USCIS оценивает не количество коммитов, а вклад как original contribution of major significance. Для этого нужно отобрать задачи, которые можно превратить в юридически убедительный аргумент. Офицер не будет реконструировать ваш impact по трекеру — его нужно извлечь, назвать и подтвердить документами.

Типы вкладов, которые имеют наибольший вес для USCIS

• Вклад в архитектуру или алгоритмы. Например, переработка механизма кэширования, новый планировщик задач, оптимизация inference pipeline, изменение структуры storage layer, внедрение более устойчивого алгоритма синхронизации данных. Такие задачи хорошо ложатся в аргумент «оригинальности», если видно, что решение не было механическим рефакторингом.
• Критические фичи. Новый функционал, без которого проект стал применим в важном production-сценарии: поддержка новой платформы, интеграция с облачным провайдером, SDK для мобильной разработки, модуль авторизации, compatibility layer для enterprise-клиентов.
• Исправления безопасности. Устранение vulnerability, hardening авторизации, закрытие утечек данных, исправление race condition, защита supply chain. Здесь важно показать severity, affected users, CVE или внутреннюю оценку maintainers.
• Performance и quality improvements. Снижение latency, уменьшение memory footprint, ускорение build pipeline, рост throughput, повышение test coverage для критического модуля. Особенно сильны вклады, где есть benchmark до/после.
• Дизайн API. Новый публичный API, изменение контрактов SDK, улучшение developer experience, backward-compatible расширение интерфейса. Для фаундеров, mobile developers и AI-инженеров это часто недооцененный тип вклада: API-дизайн показывает продуктовую зрелость.
• Поддержка пользователей и документации. Может работать, если документация изменила adoption: migration guide, security guide, architecture documentation, examples для enterprise use cases, инструкции для интеграции модели или библиотеки в production. Простое исправление опечаток обычно не достаточно.
• Создание модуля с нуля. Один из самых удобных форматов для USCIS: есть начальная проблема, design discussion, initial implementation, review maintainers, merge, release, subsequent usage. Такой вклад легче объяснить как самостоятельный original contribution.

Не выбирайте задачи по размеру diff. Большой pull request может быть техническим переносом файлов, а небольшой patch — исправлением дефекта, который блокировал релиз или закрывал критическую уязвимость. Для USCIS важна не длина кода, а значимость результата.

Чек-лист: что можно упаковать как оригинальный вклад

Каждый PR, issue или commit должен пройти фильтр: если вклад не проходит хотя бы два пункта из трех, он, как правило, слаб для отдельного доказательства по критерию original contributions.

• Новый функционал или нетривиальное улучшение. Вклад должен добавлять возможность, менять подход, устранять существенное ограничение или улучшать ключевую метрику.
• Вклад признается maintainers или community. Это может быть approve от core maintainer, комментарий о важности решения, включение в release notes, mention в changelog, закрепленный issue, приглашение в contributors team.
• Impact прослеживается по артефактам. Должны быть видны issue, PR, commit, merge, release, downstream usage, скачивания, stars/forks в контексте, ссылки на проекты, которые начали использовать фичу.

Идеальная единица доказательства выглядит так: issue сформулировал проблему, PR показал ваше решение, review подтвердил качество, release notes зафиксировали включение, последующие ссылки или метрики показали эффект.

Формулируем вклад: «проблема → решение → эффект»

Для каждой позиции подготовьте 1–2 плотных предложения. Не описывайте процесс разработки. Описывайте юридически релевантный результат.

• Проблема: какое ограничение, дефект, риск или отсутствующая возможность существовали в проекте.
• Ваше решение: что именно вы спроектировали, реализовали или исправили.
• Эффект: что изменилось после merge: производительность, безопасность, совместимость, adoption, стабильность, developer experience, возможность использования в production.

Пример для AI-инженера: «В проекте отсутствовал механизм батчинга запросов для inference на GPU, из-за чего latency росла при concurrent workloads. Заявитель реализовал scheduler и memory-aware batching layer, что было принято maintainers и включено в релиз, снизив среднее время обработки запросов по benchmark проекта».

Пример для mobile-разработчика: «Android SDK не поддерживал корректное восстановление сессии после background termination, что приводило к потере состояния у приложений на production-устройствах. Заявитель переработал lifecycle handling и добавил regression tests; изменение было merged в core SDK и отмечено в release notes как stability fix».

Пример для фаундера или технического лидера: «Проект не имел API для интеграции с внешними billing providers, что ограничивало коммерческое использование продукта. Заявитель спроектировал и реализовал extensible API layer, после чего maintainers включили модуль в релиз и community начала использовать его для production-интеграций».

Если вы подаете EB-1 или O-1, не заставляйте офицера USCIS читать GitHub как инженерный менеджер. К каждому техническому артефакту нужен короткий вывод: почему это оригинально, почему это существенно, где это подтверждено независимыми или полунезависимыми источниками.

«Небольшие коммиты» и «только документация»: когда это работает

Небольшие коммиты сами по себе редко выглядят убедительно для критерия original contributions. Однако небольшой commit может быть сильным, если он закрывает значимую проблему: patch устраняет security flaw, исправляет memory leak, снимает production blocker, восстанавливает совместимость с major version dependency или предотвращает data corruption. В таком случае нужно показывать не размер изменения, а масштаб риска и признание maintainers.

Документация также не является автоматически слабой. Слабая документация — это cosmetic edits. Сильная документация — это architecture guide, migration playbook, security model, API reference, onboarding для enterprise users, examples, без которых технология плохо внедрялась. Для USCIS это нужно связывать с adoption: issue от пользователей, комментарии maintainers, рост использования, включение guide в official docs.

Типичная ошибка — стесняться документации и включать ее как второстепенный довесок. Если вы создали migration guide, который позволил сотням разработчиков перейти на новую major version без breaking changes, это может быть contribution. Но это нужно доказывать через usage, ссылки, признание maintainers и конкретный эффект.

Практический фильтр для отбора PR, issue и commits

Соберите таблицу и оцените каждую позицию по пяти параметрам. В петицию стоит включать только те строки, где можно получить сильную доказательную связку.

• Originality: было ли решение новым для проекта или нетривиальным по подходу.
• Significance: повлияло ли изменение на безопасность, архитектуру, производительность, adoption, стабильность или применимость проекта.
• Attribution: видно ли, что именно вы автор решения, а не один из многих участников без различимого вклада.
• Recognition: есть ли подтверждение от maintainers, community, release notes, changelog, публичных обсуждений.
• Traceability: можно ли пройти путь от issue к PR, от PR к merge, от merge к релизу, от релиза к использованию.

Внутри петиции это удобно оформлять не как список ссылок, а как мини-досье по каждому ключевому вкладу: название задачи, проблема, ваше решение, доказательства принятия, эффект, ссылки на артефакты.

Типичные ошибки при упаковке open-source вклада для USCIS

• Не связывать вклад с реальной областью экспертизы. Если заявитель позиционируется как AI engineer, а в доказательствах только мелкие правки frontend-документации, возникает разрыв между заявленной областью и вкладом.
• Не показывать причинно-следственную связь. Фраза «мой PR был merged» недостаточна. Нужно показать, что merge привел к релизу, релиз закрыл проблему, а закрытая проблема имела значение для пользователей или проекта.
• Перегружать трекер ссылками без выводов. Десятки GitHub URLs без аналитики выглядят как сырой data dump. USCIS не обязан делать технический анализ за заявителя.
• Подменять impact активностью. «100 commits» не равно «major significance». Лучше 5 сильных вкладов с release notes и признанием maintainers.
• Игнорировать независимое подтверждение. Если все доказательства исходят только от заявителя, пакет слабее. Нужны comments maintainers, external adoption, third-party references, release documentation.

Для сильной подачи выберите 3–7 ключевых open-source вкладов и разберите их глубоко. В USCIS-пакете выигрывает не ширина GitHub-активности, а доказанная значимость конкретных решений в признанном проекте или экосистеме.

Какие доказательства приложить: ссылки, метрики и письма

Для критерия original contributions of major significance в O-1 и EB-1 важно не просто показать, что кандидат писал open-source-код. USCIS смотрит на связку: что именно было создано, почему это не было рутинной задачей, как contribution был принят сообществом или production-пользователями, и какой измеримый эффект он дал.

Репозиторий сам по себе редко закрывает критерий. Его нужно превратить в доказательный пакет: технические артефакты, метрики влияния и независимые подтверждения.

1. Артефакты из репозиториев: что выгружать и как объяснять

По каждому значимому contribution готовится не «ссылка на GitHub», а мини-досье. Офицер USCIS не обязан разбираться в архитектуре вашего проекта, читать весь diff или понимать, почему изменение в runtime, compiler, ML framework, database engine или mobile SDK было нетривиальным. Это нужно объяснить в доказательствах.

В пакет по каждому contribution стоит включить:

• PR ID / commit IDs. Укажите точные номера pull request, commit hash, дату открытия, дату merge, автора, reviewers и целевую ветку.
• Changelog и release notes. Если изменение вошло в релиз, приложите страницу release notes, changelog, tag релиза и ссылку на версию, где contribution стал доступен пользователям.
• Merge / acceptance evidence. Скриншоты или экспорт страниц, где видно, что PR был approved, reviewed, merged maintainers проекта.
• Issue-to-fix timeline. Связка issue → обсуждение → design decision → PR → review → merge → release. Это особенно полезно для bug fixes, security patches, performance work и миграций.
• Design docs и technical proposals. Если вы предлагали архитектурное решение, приложите ADR, proposal или mailing list discussion.
• Code review discussion. Выберите фрагменты review, где maintainers обсуждали сложность решения, компромиссы, безопасность, backward compatibility, performance или масштабируемость.
• Связанные issues пользователей. Если contribution закрывал запросы компаний, production-команд или downstream-проектов, приложите issues, где описана проблема, affected environments и подтверждение, что fix помог.

Не перегружайте петицию десятками мелких commits. USCIS не оценивает объём активности как GitHub-рекрутер. Лучше выбрать 3–6 сильных contributions и по каждому показать проблему, ваше решение, принятие решения maintainers и последствия для пользователей.

2. Метрики impact: что считать и как избежать vanity metrics

Для USCIS ключевой вопрос — не «сколько звёзд у репозитория», а какое значение имел именно ваш вклад. Popularity проекта может усилить доказательство, но не заменяет доказательство impact.

Метрики стоит делить на несколько групп:

• Number of users affected. Сколько пользователей, разработчиков, организаций или downstream-систем затронул contribution. Источники: package registry statistics, dependency graph, public adoption pages, production statements, telemetry.
• Downloads / usage. Для npm, PyPI, Maven Central, crates.io, Docker Hub, GitHub Packages, Homebrew, CocoaPods, RubyGems можно приложить статистику загрузок и usage trend.
• Performance improvements. Для оптимизаций нужны benchmarks до и после: latency, throughput, memory footprint, CPU utilization, build time, inference speed.
• Security incidents mitigated. Для security-related contributions приложите CVE, advisory, vulnerability report, affected versions, severity.
• Migration adoption. Если вы разработали migration path или compatibility layer, покажите количество проектов, перешедших на новую версию, adoption rate, ссылки на downstream migrations и release notes.
• Stars, forks, contributors, maintenance status. Эти показатели можно использовать как контекст значимости проекта: active maintainers, frequency of releases, relevance. Но сами по себе stars и forks не доказывают, что ваш вклад был original и significant.

Инсайд: формулировка «репозиторий имеет 30,000 stars» слабее, чем «мой patch устранил regression, affecting API used by mobile clients; fix был включён в changelog и снизил crash rate». USCIS оценивает доказательность причинно-следственной связи, а не социальную популярность страницы.

Для IT, AI и mobile engineering особенно хорошо работают следующие типы impact:

• AI / ML frameworks: ускорение inference, оптимизация memory allocation, поддержка новой модели или backend.
• Mobile development: снижение crash rate, уменьшение bundle size, улучшение startup time, compatibility patch для iOS / Android SDK.
• Infrastructure / DevOps: ускорение CI/CD, снижение build time, исправление race condition, security hardening.
• Founder / CTO track: open-source-компонент, который стал частью коммерческого продукта, developer platform, SDK, API gateway.

3. Письма поддержки: кто должен подписывать и что в них должно быть

Письма поддержки должны быть не комплиментарными, а доказательными. Их задача — перевести технический вклад на язык иммиграционного критерия: роль кандидата, оригинальность решения, значимость результата и независимое признание.

Наиболее сильные авторы писем:

• Maintainers проекта. Они могут подтвердить, что contribution был review-approved, merged, вошёл в release, решил нетривиальную проблему.
• Ведущие разработчики или архитекторы. Особенно если они участвовали в review, design discussion или релизном процессе.
• Пользователи из production. Инженерные лиды компаний или команд, которые используют проект и могут подтвердить, что contribution решил реальную операционную проблему.
• Независимые эксперты. Специалисты из отрасли, которые не работали с кандидатом напрямую, но могут оценить значение contribution для экосистемы.

В письме должны быть конкретные блоки:

• Кто автор письма и почему он компетентен оценивать вклад.
• Какая именно была роль кандидата.
• В чём оригинальность.
• В чём значимость.
• Ссылки на доказательства.

Ворнинг: письма в стиле «он талантливый инженер» почти не работают. USCIS по Kazarian смотрит сначала на наличие доказательств по критерию, затем на final merits determination. Поэтому письмо должно помогать офицеру связать факты с критерием original contributions, а не заменять факты оценочными фразами.

4. Как оформлять ссылки, скриншоты и архивы

Страницы меняются, аккаунты переименовываются, ветки удаляются, permissions закрываются. Поэтому ссылки нужно фиксировать документально:

• Копии страниц с датами. Делайте PDF-export или печать страницы в PDF с видимыми датами PR, commits, comments, approvals, merge status и release tags.
• Скриншоты ключевых фрагментов. Скриншот должен показывать URL, дату, имя пользователя, статус PR, related issue, reviewers или release note.
• Экспорт страницы PR. Для сильных PR сохраняйте полную страницу: описание, timeline, review comments, approvals, merge event, linked issues, labels и release reference.
• Архивирование внешних страниц. Используйте web archive или внутренний PDF archive, чтобы показать, каким был контент на дату подготовки петиции.
• Фиксация package metrics. Статистика downloads и usage должна быть сохранена с датой, источником и методологией.
• Нумерация exhibit-ов. Каждому доказательству присваивайте номер: Exhibit OS-1, OS-2, OS-3. В письмах поддержки и attorney brief должны быть ссылки на эти exhibit-ы.

5. Единый индекс доказательств

Лучший способ сделать open-source-пакет понятным для USCIS — собрать единый индекс. Это помогает снизить риск RFE, потому что офицеру не нужно самостоятельно переходить по десяткам ссылок.

Сильный индекс строится не по типам файлов, а по юридической логике критерия. Не «GitHub links», «screenshots», «letters», а «originality evidence», «acceptance evidence», «major significance evidence».

6. Точность и непротиворечивость: проверка перед подачей

Перед подачей проверьте:

• Сроки: дата issue, дата PR, дата merge, дата release и дата письма поддержки должны логически совпадать.
• Имена и идентичность: GitHub handle, юридическое имя, имя в резюме, имя в письмах должны быть связаны.
• Проекты и версии: название репозитория, package name, module name и release version должны совпадать во всех документах.
• Роль кандидата: если в PR видно, что кандидат сделал minor edit, письмо не должно утверждать, что он «led the architecture».
• Метрики: downloads, users, benchmarks и adoption должны иметь источник, дату и корректное описание.
• Письма поддержки: авторы писем должны ссылаться на те же contributions, что и индекс доказательств.

Если письмо утверждает, что contribution «используется миллионами пользователей», а в доказательствах есть только 1,200 GitHub stars, это не усиление, а риск. Для USCIS лучше формулировка «adopted in release X» с чёткими метриками.

Итоговый пакет по open-source должен отвечать на четыре вопроса: что было сделано, почему это было оригинально, кто это принял или подтвердил, и какой measurable impact это имело. Всё остальное — ссылки, скриншоты, письма и метрики — должно работать на эту структуру.

Справочные нормы: см. разделы по критериям и общему подходу к доказательствам на USCIS Policy Manual.

Narrative-письмо: как составить убедительную историю вклада

Для критерия Original Contributions of Major Significance narrative-письмо — это не пересказ GitHub-истории, а юридико-техническое обоснование. Офицер USCIS должен увидеть, что из доказательств можно разумно вывести: вклад был original, то есть создан заявителем или при его существенном участии, и of major significance, то есть имел значение за пределами обычной рабочей активности.

Ключевой риск: сильный инженерный вклад часто проигрывает в USCIS не из-за слабого кода, а из-за слабой упаковки. Если narrative сводится к «я сделал 47 commits, вот ссылки», офицер видит активность, но не видит значимость.

Базовая структура narrative-письма

Структура narrative должна быть логичной, понятной и подтверждённой документами. Оптимальная структура — пять блоков:

1. Background: ваша роль и домен. Покажите, кто вы в контексте проекта: core contributor, maintainer, author of a module, external contributor, founder-engineer. Не перегружайте вступление стеком технологий.
2. Summary table: вклад 1–N. Таблица, где каждый вклад описан по единой логике: что сделано, почему оригинально, чем подтверждается, какой эффект наступил.
3. Deep dive: подробный разбор 2–3 ключевых вкладов. Техническая проблема, ваше решение, почему оно было неочевидным, как принято, какой результат.
4. Evidence map: навигационная карта по доказательствам. Где именно офицер должен увидеть подтверждение каждого утверждения.
5. Independent validation: подтверждение со стороны третьих лиц: maintainers, downstream users, независимые эксперты, adoption-сигналы.

1. Background: роль, домен и контекст проекта

В первом блоке важно показать контекст, достаточный для офицера USCIS. Сформулируйте:

• Для AI/ML-инженера: «The petitioner contributed to an open-source machine learning infrastructure project used for model serving and inference optimization.»
• Для mobile-разработчика: «The petitioner contributed architectural improvements to a cross-platform mobile framework.»
• Для backend/infra-инженера: «The petitioner designed and implemented changes in distributed task scheduling and fault-tolerance mechanisms within an open-source infrastructure tool.»
• Для фаундера: «The petitioner initiated and led development of an open-source developer tool later adopted by external teams.»

Не пишите «I was one of the most important contributors» без внешней опоры. Лучше: «The petitioner’s contribution was merged by the maintainers, included in release 2.4».

2. Summary table: вклад 1–N

Обзор всех релевантных contributions — это таблица доказательств, которая позволяет офицеру быстро увидеть, что каждый вклад связан с оригинальностью, доказательством и эффектом.

3. Deep dive: 2–3 ключевых вклада

Для каждого key contribution дайте:

• Technical problem: какая проблема существовала до вашего вмешательства.
• Your solution: что именно вы спроектировали или реализовали.
• Why it was original: почему это не было механическим исправлением.
• Effect: как изменилось поведение системы или adoption.

Формула для deep dive:

«Before this contribution, the project lacked ___. The petitioner designed and implemented ___, a non-trivial architectural change that ___. The contribution was merged in PR #___, adopted in release X, and referenced by maintainers as a key architectural improvement.»

4. Evidence map: где именно в репозитории это видно

Evidence map — это навигация по доказательствам. Для каждого ключевого вклада укажите:

• Pull request, commit hash, issue, release notes, maintainer comments, design docs, benchmarks, downstream adoption.
• Скриншоты или экспорт страниц с датами, URL и контекстом.

5. Independent validation

Независимое подтверждение — критически важный блок. Подтверждение может исходить от:

• maintainers, core contributors;
• downstream users и инженерных лидеров компаний;
• adoption metrics и public adoption;
• упоминания в release notes, changelog, RFC, design docs.

Сильная формулировка:

«The significance of this contribution is supported by maintainer review comments, inclusion in release X, and independent confirmation from downstream teams integrating the library into production CI/CD workflows.»

Избегайте завышения и жаргона

Не называйте вклад industry-changing, если есть только merge в репозиторий. Не используйте избыточный технический жаргон. Каждое утверждение должно быть подкреплено документом и понятно неспециалисту.

Безопасная стратегия — писать на один уровень ниже максимальной самопрезентации, но подкладывать сильные доказательства: «material improvement adopted in release X and recognized by maintainers».

Мини-шаблон narrative-блока

Background: The petitioner is a software engineer specializing in ___ and contributed to ___, an open-source project used for ___.

Summary: The petitioner made several original contributions to the project, including (1) ___, (2) ___, and (3) ___. These contributions were not routine code changes; they addressed technical limitations and were accepted into the project after maintainer review.

Deep dive: Prior to the petitioner’s contribution, the project faced ___. The petitioner designed and implemented ___, a non-trivial architectural contribution that ___. The contribution was merged in PR #___ and adopted in release X.

Evidence map: The implementation is documented in PR #___ and commit ___; reviewed by maintainers ___; adopted in release ___; confirmed by downstream users ___.

Independent validation: Maintainer comments describe ___; downstream users reference ___; release notes identify ___.

Пошаговый план подготовки пакета для USCIS

Open-source вклад для USCIS нельзя упаковывать как набор ссылок на GitHub. Это доказательство конкретного критерия: original scientific, scholarly, artistic, athletic, or business-related contributions of major significance. Перед сборкой пакета нужно сверить чек-лист под вашу категорию и правовой стандарт.

Ключевая ошибка: заявители доказывают, что много кодили, вместо того, чтобы доказывать, что их вклад изменил проект, индустрию, инфраструктуру или пользователей. USCIS оценивает значимость вклада и его подтверждение независимыми источниками.

Шаг 1. Проведите инвентаризацию PR, commits, issues и releases

• Соберите merged PR, а не черновики или открытые ветки.
• Сохраните commit history с датами и идентификаторами.
• Отметьте PR, попавшие в major/minor releases.
• Зафиксируйте обсуждения, где maintainers признают ценность решения.
• Сохраните contributors, release notes и changelog в PDF с датой доступа.

Шаг 2. Выделите strongest contributions, а не все активности

Для USCIS сильнее работают 3–5 глубоко раскрытых вкладов, чем 70 необъясненных ссылок. Отберите вклад, который можно связать с measurable impact: ускорение performance, устранение критической уязвимости, архитектурное изменение, adoption крупными компаниями.

Шаг 3. Соберите релизы и документы, которые связывают вклад с результатом

Покажите цепочку: проблема → ваше решение → принятие maintainers → включение в релиз → внешнее использование.

• release notes, где упомянут ваш PR;
• changelog с датой версии и описанием;
• technical design document или RFC;
• package registry statistics (npm, PyPI, Maven и др.);
• упоминания в документации проекта, официальном блоге, developer guide;
• evidence downstream adoption: кто использует библиотеку и где.

Шаг 4. Соберите доказательственную таблицу

В таблице должны быть:

• Contribution: название вклада.
• Project: репозиторий и аудитория.
• Your role: author, co-author, maintainer.
• Technical substance: что именно сделано.
• Originality: почему не рутинная задача.
• Impact: релиз, adoption, metrics, security effect.
• Evidence: номера exhibits, ссылки, письма.
• USCIS criterion: к какому критерию относится.

Шаг 5. Получите письма поддержки с конкретикой

Письмо должно объяснять не вашу «талантливость», а значение конкретного вклада. Оно должно быть экспертным интерпретатором доказательств.

Шаг 6. Напишите narrative под стандарт вашей категории

• Начинайте с contribution и его значения, а не с биографии.
• Объясняйте техническую проблему понятным языком.
• Каждое утверждение связывайте с exhibit.
• Разделяйте «я написал код» и «мой код был принят, распространён и повлиял».
• Не завышайте роль, если вклад был коллективным.

Шаг 7. Скомпонуйте пакет: exhibits должны читаться без расследования

Пакет должен быть автономным: PDF-скриншоты, архивированные страницы, выделенные фрагменты, пояснения, индексы, номера exhibits.

• Сделайте exhibit index.
• Разделите материалы по contributions, а не по типам файлов.
• Для каждого скриншота укажите repository name, URL, дату, автора, статус merged/closed.
• Для release notes выделите версию, дату и relevant line.
• Для метрик downloads/stars/forks поясните источник и период.

Ссылки могут умереть, страницы GitHub могут измениться. Закладывайте время на архивирование доказательств: PDF, web archive, скриншоты с URL и датой доступа.

Шаг 8. Проверьте логику, даты и непротиворечивость

• Дата PR не должна противоречить дате релиза.
• Роль в письмах должна совпадать с ролью в репозитории.
• Метрики adoption должны относиться к релевантному периоду.
• Описание impact не должно быть шире, чем подтверждают документы.
• Названия проектов, версий и технологий должны быть единообразны во всём пакете.

Шаг 9. Проведите финальную вычитку как RFE-аудит

Финальная проверка должна ответить на вопрос: если USCIS пришлёт RFE по original contributions, что будет слабым местом?

• Уберите дублирующие ссылки без анализа.
• Проверьте, что каждый exhibit упомянут в narrative.
• Проверьте, что каждый сильный тезис имеет документальное подтверждение.

Типичные риски при оформлении open-source для USCIS

• Слишком общий вклад. «Участвовал в развитии проекта» не показывает original contribution.
• Отсутствие impact. Принятый PR сам по себе не равен major significance.
• Письма без конкретики. Рекомендатели должны описывать вклад, а не характер.
• Несостыковки с GitHub. Любое несоответствие между narrative и репозиторием — риск.
• Переводы и копии без дат и контекста. Скриншот без URL, даты и пояснения имеет низкую ценность.

Если есть сомнения в силе вклада, не расширяйте пакет десятками необъясненных ссылок. Усиливайте связку evidence + narrative: выберите меньше contributions, но глубоко покажите их оригинальность, подтвердите impact и привяжите каждое доказательство к требованиям вашей категории.

Проверенные источники:

• USCIS: Form I-129 (как подготовить)
• USCIS: Form I-140 (как подготовить)