Спасибо за помощь в улучшении AMP путём устранения ошибок, добавления новых функций или улучшения кода AMP каким-либо другим способом!
Данный документ описывает процесс, через который вы пройдёте для внесения изменений в AMP.
Обзор процесса
Процесс для устранения небольших ошибок и обновлений
Мы хотим сделать процесс внесения небольших исправлений как можно более простым. Исправление небольшой ошибки должно быть таким же простым, как создание PR с изменением, добавление/улучшение теста и отправка его на проверку.- [ ] Согласиться с Открытым соглашением о лицензии участника OpenJSF (CLA).
(необязательно) Если вы исправляете ошибку и существует соответствующий GitHub-тикет, назначьте его себе (если это возможно) или оставьте комментарий, чтобы другие знали, что вы работаете над ним. Если тикета нет, рассмотрите возможность его создания, но для небольших исправлений может быть достаточно описания PR.
(необязательно) Найдите руководство перед началом работы, чтобы помочь вам ответить на вопросы.
Следуйте соответствующим разделам Реализации, которые подходят для вашего изменения. Многие части процесса, вероятно, не потребуются для небольших исправлений -- например, вам может не потребоваться вносить изменения в валидатор или помещать ваше изменение за эксперимент для небольших исправлений. Если вы сомневаетесь, обратитесь к своему руководителю или к каналу #contributing на Slack.
Ваш код должен быть проверен/одобрен владельцем для каждого затронутого раздела вашего PR и проверяющим. - после создания вашего PR, бот автоматически найдет владельцев, которые могут одобрить ваш PR и добавит их в ваш PR; вы также можете просмотреть файл OWNERS в директориях, которые вы изменили (или их родительских директориях)
выберите проверяющего; возможно, что владельцы, которые были автоматически добавлены ботом, также являются проверяющими
если владелец, который был автоматически добавлен, не является проверяющим, или вы хотите, чтобы кто-то другой проверил и одобрил ваш код, добавьте их как проверяющих в ваш PR, если это возможно, в противном случае укажите их с помощью строки "/cc @username" в описании вашего PR. Если у вас возникнут проблемы с поиском проверяющего/владельца или у вас есть другие вопросы, свяжитесь с каналом #contributing на Slack.### Процесс для значительных изменений
Значительные изменения (например, новые компоненты или значительные изменения поведения) требуют консультаций и одобрения со стороны знающих членов сообщества.
**Если вы вносите изменения в существующее поведение, ознакомьтесь с политикой AMP по разрушительным изменениям.**Если вы отменяете/удаляете функцию, следуйте процессу отмены вместо этого процесса. - [ ] Перед тем как начать программирование, найдите руководителя, с которым вы сможете обсудить свои изменения и который сможет помочь вам пройти через процесс.
Создайте Intent-to-implement (I2I) GitHub issue и уведомите вашего руководителя. I2I должен включать:
Описание изменений, которые вы планируете реализовать.
Если вы интегрируете услугу стороннего поставщика, предоставьте ссылку на сайт и продукт стороннего поставщика.
Подробности о любом сборе данных или отслеживании, которое может потребоваться от ваших изменений.
Прототип или макет (например, изображение, GIF или ссылка на демонстрацию).
Определите, кто должен одобрить ваш I2I. Изменения, которые имеют значительное влияние на поведение AMP или значительные новые функции, требуют одобрения от Approvers Working Group (WG). Работайте с вашим руководителем, чтобы определить, достаточно ли значительны ваши изменения, чтобы требовать одобрения от группы Approvers и/или любой другой Working Group.- [ ] Получите предварительное одобрение от группы Approvers WG, если это необходимо. Для изменений, требующих одобрения от группы Approvers WG, по крайней мере, три члена группы Approvers WG должны предоставить предварительное одобрение на I2I до того, как начнется значительная реализация.
Ваш руководитель может помочь вам определить, требует ли ваше изменение документации по дизайну, и следует ли представить его на дизайнерскую проверку.
Для изменений, требующих одобрения от группы Approvers WG, создайте Intent-to-ship (I2S) issue. Укажите, какое экспериментальное изменение блокирует ваши изменения и план поэтапного внедрения. Как только это изменение будет одобрено тремя членами группы Approvers WG, план поэтапного внедрения, описанный в I2S, может быть реализован. ## Найти руководителяРуководитель — это участник сообщества AMP, который обладает знаниями о том разделе, который вы изменяете, и который может помочь вам с момента дизайна до запуска.
Руководитель обязателен, если вы вносите значительные изменения в AMP, но является необязательным при внесении небольших изменений.
Чтобы найти руководителя:
Рабочая группа, ответственная за раздел, который вы изменяете, может документировать, как найти руководителя из этой Рабочей группы. Если они этого не делают, обратитесь к посреднику Рабочей группы (в Slack или добавив "/cc @username" в тело или комментарий вашего запроса на GitHub).
Если нет очевидной Рабочей группы, ответственной за раздел, который вы изменяете, но вы знаете, какой раздел кодовой базы будет затронут, обратитесь к одному из людей, упомянутых в OWNERS файлах для затронутых разделов (в Slack или добавив их в ваш запрос на GitHub).
Если вы всё ещё не уверены, кто должен быть вашим руководителем, запросите руководителя в Slack в канале #contributing.
Если вы не можете найти руководителя после прохождения этих путей или руководители, которых вы нашли, не отвечают, обратитесь к mrjoro в Slack или добавьте его в ваш запрос на GitHub/PR.Как только вы найдете руководителя, убедитесь, что вы упомянули его в любых запросах / PR, связанных с вашими изменениями (например, если mrjoro является вашим руководителем, вы можете просто добавить "/cc @mrjoro" в тело или комментарий запроса/PR).## Реализация
Для более значительных изменений предпочтительнее создать несколько меньших запросов на слияние (pull requests), чем один большой запрос. Это будет легче проверять и предотвратит потерю времени.
Обратитесь к этим ресурсам для руководства и руководств:
Узнайте, как создать свой первый компонент, в этом руководстве
Посмотрите это видео на YouTube, чтобы узнать о "Создании нового AMP компонента" - Интеграция сторонних программ, встраиваемых элементов, услуг: Руководства
Основной характеристикой AMP является производительность. Все изменения будут анализироваться на наличие влияния на производительность; мы особенно ценим изменения, которые делают вещи еще быстрее. Пожалуйста, включите любое измеренное влияние на производительность с существенными запросами на слияние.
Подготовьтесь к рецензированию вашего кода.
Для более существенных изменений обычно лучше пройти рецензию кода перед тем, как сделать значительные инвестиции в новые тесты, примеры и т.д.
Перед окончательной рецензией убедитесь, что ваши изменения:
[Получите последние изменения из репозитория amphtml](. /getting-started-e2e. md#pull-the-latest-changes-from-the-amphtml-repository) и разрешите любые конфликты.
Запустите пред推送 проверку, это инструмент, который помогает выявить любые проблемы до того, как вы отправите код. Чтобы включить пред推送 гит-хук, см. [enable-git-pre-push. sh](. . /build-system/common/enable-git-pre-push. sh#L17-L20).
[Отправьте свои изменения](. /getting-started-e2e. md#push-your-changes-to-your-github-fork).
[Создайте запрос на слияние (PR)](. /getting-started-e2e. md#send-a-pull-request-ie-request-a-code-review).
Убедитесь, что пред推送 проверки, отображаемые в PR на GitHub, прошли успешно (например, отсутствие ошибок форматирования кода и типов, тесты прошли).
Добавьте проверяющего, который соответствует требованиям для проверки и утверждения кода, которые указаны в разделе проверка и утверждение кода. (Робот автоматически назначит всех владельцев, которые могут проверить ваш код, ваш наставник может помочь найти проверяющего, если это необходимо.)
[Ответьте на отзывы](. /getting-started-e2e. md#respond-to-pull-request-comments).
После того, как ваш PR получил все необходимые утверждения, любой участник/проверяющий может слить ваш код в репозиторий. Обычно ваш наставник занимается этим; если ваш код не был слит不久后我会完成这个翻译，请稍等。
[Получите последние изменения из репозитория amphtml](. /getting-started-e2e. md#pull-the-latest-changes-from-the-amphtml-repository) и разрешите любые конфликты.
Запустите пред推送 проверку, это инструмент, который помогает выявить любые проблемы до того, как вы отправите код. Чтобы включить пред推送 гит-хук, см. [enable-git-pre-push. sh](. . /build-system/common/enable-git-pre-push. sh#L17-L20).
[Отправьте свои изменения](. /getting-started-e2e. md#push-your-changes-to-your-github-fork).
[Создайте запрос на слияние (PR)](. /getting-started-e2e. md#send-a-pull-request-ie-request-a-code-review).
Убедитесь, что пред推送 проверки, отображаемые в PR на GitHub, прошли успешно (например, отсутствие ошибок форматирования кода и типов, тесты прошли).
Добавьте проверяющего, который соответствует требованиям для проверки и утверждения кода, которые указаны в разделе проверка и утверждение кода. (Робот автоматически назначит всех владельцев, которые могут проверить ваш код, ваш наставник может помочь найти проверяющего, если это необходимо.)
[Ответьте на отзывы](. /getting-started-e2e. md#respond-to-pull-request-comments).
После того, как ваш PR получил все необходимые утверждения, любой участник/проверяющий может слить ваш код в репозиторий. Обычно ваш наставник занимается этим; если ваш код не был слит в репозиторий сразу после утверждения, свяжитесь с ним.
[Удалите ветку](. /getting-started-quick. md#удалить-ваш-ветвь-после-ваших-изменений-были-слингованы-опционально): После того, как ваши изменения были слиты, вы можете удалить вашу ветку. ## Внесение расширенных компонентовAMP спроектирован для расширяемости — он предназначен для поддержки "Расширенных Компонентов", которые предоставляют первоклассную поддержку для дополнительных богатых функций.
Поскольку Расширенные Компоненты могут оказывать значительное влияние на производительность, безопасность и использование AMP, вклады в Расширенные Компоненты будут очень тщательно анализироваться и проверяться.
В частности, мы стремимся спроектировать общий набор компонентов таким образом, чтобы большинство сценариев использования можно было составить из них. Вместо создания нового компонента может быть лучше объединить существующие компоненты для достижения аналогичного эффекта.
У нас есть несколько дополнительных ресурсов, которые предоставляют введение в внесение расширенных компонентов:
Для получения дополнительной информации о интеграции третьих сторон (например, шрифты, встраивания и т.д.), см. наши руководства по внесению вклада для 3p.
Соглашение о лицензии для вкладчиковAMP требует от всех вкладчиков согласия с Соглашением о лицензии для вкладчиков OpenJSF для защиты вкладчиков и пользователей в вопросах интеллектуальной собственности.
Чтобы согласиться с Соглашением о лицензии для вкладчиков OpenJSF, перейдите на https://cla-assistant.io/ampproject/amphtml, прочитайте соглашение и нажмите "Согласиться с GitHub".
В качестве альтернативы, вы также можете скачать Соглашение о лицензии для вкладчиков с https://individual-cla.openjsf.org, заполнить его, подписать, указать ваш GitHub-идентификатор и отправить на operations@openjsf.org. Обработка вашего CLA осуществляется вручную, поэтому это занимает гораздо больше времени и поэтому не рекомендуется.
Проверка и одобрение кода
Все код в AMP должен быть проверен и одобрен до слияния. Проверяющие/Сотрудники в основном обеспечивают, что код корректен, эффективен и согласован с существующим кодом AMP, в то время как Владельцы в основном предоставляют предметную проверку кода.Для слияния код должен быть одобрен как проверяющими, так и владельцами.
По крайней мере один Проверяющий, который не является автором. Если автор является Проверяющим, Сотрудник может удовлетворить это требование вместо него.
По крайней мере один Владелец для всех областей, затронутых запросом на слияние (PR), за исключением тех областей, в которых автор кода является Владельцем.Разрешено одному человеку удовлетворять эти требования, например, если Владелец, который также является Проверяющим, одобрит PR, его можно будет слить.
У нас теперь есть бот, который автоматически назначает Владельцев к PR сразу после его создания, и вероятно, что по крайней мере один из этих Владельцев также будет Проверяющим.
После того как PR будет одобрен, любой, у кого есть права на коммит в репозитории, может слить PR, включая его автора.
Эти руководства специфичны для репозитория amphtml. Другие репозитории ampproject могут следовать тем же руководствам или использовать другие руководства, как это документировано в файлах docs/contributing.md.
Роли
Сотрудники
Проверяют, одобряют и сливают PR в репозиториях, для которых они являются Сотрудниками.
Статус Сотрудника предоставляется людям, которые доказали базовую осведомлённость о соответствующем репозитории.
Человек может стать Сотрудником после слияния двух PR, которые не являются тривиальными (не только исправление опечаток, не только изменения конфигурации), и получения одобрения (+1) от одного текущего Проверяющего. Чтобы запросить статус Сотрудника, создайте задачу в репозитории, в котором вы хотите стать Сотрудником, и укажите в копии Проверяющего в этом репозитории.
Просматривать, одобрять и объединять PR в репозитории, для которого они являются проверяющими (Reviewers).
Статус проверяющего (Reviewer) предоставляется тем, кто продемонстрировал глубокое знакомство с стилем кода и конвенциями соответствующего репозитория.
Человек может стать проверяющим (Reviewer) после объединения 10 PR или 10 высококачественных проверок сложных PR и получения одобрения (+1) от одного текущего проверяющего (Reviewer). Квалифицирующие PR должны быть не тривиальными (не только исправление опечаток, не только изменения конфигурации) и должны реализовать или документировать по крайней мере 2 новых функции. Для запроса статуса проверяющего (Reviewer) создайте issue в репозитории, в котором вы хотите стать проверяющим, и назначьте/укажите текущего проверяющего (Reviewer) в этом репозитории.
Владельцы- Проверяют и одобряют запросы на вливание (PR) в областях, в которых они обладают экспертными знаниями.
Требования для того, чтобы стать Владельцем:
Демонстрирование экспертных знаний в области, в которой они являются Владельцем.
Любой пользователь GitHub (включая тех, кто не является проверяющим или участником) может стать Владельцем.
При создании нового каталога (например, при создании нового расширения AMP) автор запроса на вливание должен обозначить себя как Владельца этого каталога.
Владельцы области могут одобрять других Владельцев в пределах или ниже своей области экспертизы в соответствии с обычным процессом обработки PR. Для запроса на получение статуса Владельца создайте PR, добавив себя в соответствующий файл OWNERS, и назначьте/укажите текущего Владельца этого каталога.
Список Владельцев для каталога можно найти в файле OWNERS в каталоге или родительском каталоге.
Обратите внимание, что некоторые Владельцы могут быть релевантны независимо от местоположения кода и поэтому могут включать одну или несколько рабочих групп AMP, таких как группы для безопасности и конфиденциальности и компонентов, которые могут предоставить руководство по веб-доступности.## Вливания
У нас есть хорошо определенный процесс для обработки запросов на изменения в экспериментальные/бета-версии, стабильные или LTS-выпуски. Эти изменения называются "вливаниями".
Примечание: Мы не поддерживаем вливания в канал выпуска nightly; в случае угрозы безопасности или конфиденциальности производится откат.
Порог для вливания в активный выпуск очень высок из-за нашей цели по выпуску высококачественных версий по предсказуемому графику.Помните, что выполнение слияния требует значительных усилий со стороны вас и на-duty инженера и они могут занять значительное время для обработки. - В целом cherry-picking возможен только для исправлений проблем P0. Проблемы P0 включают:
- проблемы конфиденциальности или безопасности
- утрату данных пользователей
- значительное нарушение существующих AMP-страниц
- аварийное отключение или критическая производственная проблема
- или любые другие проблемы, которые могут нанести значительный ущерб репутации AMP, если оставить их нерешенными
Регрессии, обнаруженные в экспериментальных/бета-релизах, которые не являются P0, могут быть одобрены, если их можно исправить с помощью отката. Исправления, кроме отката — независимо от того, насколько они просты — не будут одобрены, так как они могут привести к цепной реакции проблем и задержать продвижение бета-релиза к стабильному для всех.### Процесс запроса cherry-pickНиже приведен процесс запроса cherry-pick.- Убедитесь, что для проблемы подан отчет о баге, и убедитесь, что он решен до подачи запроса на cherry-pick.
Увеличьте приоритет проблемы до P0, получив согласие от одного или нескольких членов рабочей группы утверждений (WG) (если вы являетесь членом этой рабочей группы, ваш голос не учитывается для целей согласования).
Подайте запрос на cherry-pick, используя шаблон запроса cherry-pick. Следуйте инструкциям в шаблоне, предоставляя все запрошенные данные. Убедитесь, что вы полностью заполнили этот запрос, иначе ваш cherry-pick может не быть замечен или рассмотрен.
Получите необходимое одобрение для вашего cherry-pick, указанное через комментарии к запросу cherry-pick.
Для cherry-pick в experimental/beta по крайней мере один член рабочей группы утверждений (WG) должен одобрить cherry-pick/rollback.
После одобрения, на-duty инженер, занимающийся выпусками, будет работать с вами, чтобы убедиться, что cherry-pick выполнен.- **После выполнения cherry-pick вам необходимо проверить, что этот cherry-pick устраняет проблему и не вызывает других проблем.**Если вы запрашиваете cherry-pick для устранения проблемы в продакшне, вероятно, вам также потребуется cherry-pick в experimental/beta выпуски. Проблемы, cherry-pick которых выполнен в stable, могут быть перекрыты после продвижения beta. На-duty инженер поможет определить, требуется ли вам выполнить cherry-pick для обеих каналов выпуска.Возможно, что проблема P0 будет обнаружена в понедельник или вторник, хотя она уже присутствовала в кодовой базе в предыдущей неделе. Когда это происходит, предыдущая неделя's ночной выпуск (который, вероятно, будет повышен до экспериментального/бета во вторник утром) будет содержать проблемный код без исправления. В этом случае, инженер, отвечающий за выпуск, должен выполнить cherry-pick перед повышением прошлого недельного ночного выпуска до экспериментального/бета.> Примечание: Хотя cherry-pick выполняется на основе последней ночной версии, мы не продвигаем этот исправление в канал ночной версии. Это связано с тем, что cherry-pick выполняется на основе предыдущей nightly версии, а не на основе самой последней.
Мы предоставим вам отзыв в течение 2 рабочих дней через внутреннее сообщение!
Заполните причину отчета внимательно и по возможности подробно опишите ее.
Выберите тип отчета
Отмена
Отправить
Обжалование ошибочного суждения
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
отменить
Создать
Введение
Это проект с открытым исходным кодом, который призван ускорить мобильные страницы (Accelerated Mobile Pages), чтобы веб-страницы загружались за секунды.
Развернуть
Свернуть
Опубликовать ( 0 )