Слияние кода завершено, страница обновится автоматически
🎈 Спасибо за вашу помощь в улучшении проекта! Мы очень рады, что вы с нами!
Возможности для участия в проекте axum есть на любом уровне. Неважно, только начинаете ли вы работать с Rust или являетесь самым опытным экспертом, ваша помощь необходима.
Любая помощь, какая бы она ни была, ценна.
Эта инструкция поможет вам начать. Не позволяйте этой инструкции запугать вас. Она должна рассматриваться как карта, помогающая вам навигировать процесс.
Не знаете, с чего начать? Проверьте задачи, помеченные как "E-help-wanted" или "E-easy".
Вы также можете получить помощь с участием в axum Discord канале, пожалуйста, присоединяйтесь к нам!
Проект axum следует кодексу поведения Rust. Это описывает минимальное поведение, ожидаемое от всех участников.
Для любой задачи существуют три основных способа участия:
axum, создание новой задачи в трекере задач tokio-rs/axum — это способ её отчета.issues: https://github.com/tokio-rs/axum/issues2. Помощь в сортировке задач: Это можно сделать, предоставляя подтверждающие детали (тестовый случай, демонстрирующий ошибку), предлагая идеи по решению задачи или убедившись, что задача правильно помечена.3. Помощь в разрешении задачи: Обычно это делается либо путем демонстрации того, что отчетная задача не является проблемой, либо, чаще всего, путем открытия Pull Request, который изменяет какую-то часть проекта axum в конкретном и проверяемом виде.
Любой может участвовать на любом этапе участия. Мы призываем вас участвовать в обсуждении ошибок и участвовать в проверке Pull Requests.
Если вы просмотрели существующую документацию и у вас все еще есть вопросы или проблемы, вы можете открыть задачу, запрашивающую помощь. Взамен на получение помощи мы просим вас внести вклад в виде документации PR, который поможет другим избежать проблем, с которыми вы столкнулись.
При открытии нового вопроса в трекере проблем axum пользователи будут
представлены шаблоном базового отчета, который следует заполнить. Если вы
считаете, что обнаружили баг, пожалуйста, заполните этот шаблон, следуя
шаблону по возможности. Не беспокойтесь, если вы не можете ответить на каждый
деталь, просто заполните то, что можете.Две самых важных части информации, которые нам нужны для правильной
оценки отчета, это описание поведения, которое вы видите, и простой
тестовый пример, который мы можем использовать для воспроизведения проблемы
сами. Если мы не можем воспроизвести проблему, нам становится сложнее её
исправить.См. Как создать минимальный, полный и проверяемый пример.
Как только проблема была открыта, вокруг нее часто начинается обсуждение. Некоторые участники могут иметь разные мнения о проблеме, включая вопрос, является ли наблюдаемое поведение багом или функцией. Это обсуждение является частью процесса и должно быть сосредоточено, полезным и профессиональным.
Короткие, сжатые ответы, которые не предоставляют дополнительного контекста или подтверждающих деталей, не являются полезными или профессиональными. Для многих такие ответы просто раздражают и не дружелюбны.
Участникам рекомендуется помогать друг другу продвигаться вперед, вовлекая друг друга в совместное решение проблем. Если вы решите оставить комментарий к проблеме, которую вы считаете либо не являющейся проблемой, требующей исправления, либо если вы столкнетесь с информацией в проблеме, которую вы считаете неверной, объясните, почему вы так считаете, с дополнительным контекстом, и будьте готовы признать, что вы можете ошибаться. Так мы часто быстрее достигаем правильного результата.
открытия и проверки Pull Request похож на процесс открытия и трайажа проблем,
но включает в себя необходимую процедуру проверки и утверждения, которая
гарантирует, что предложенные изменения соответствуют минимальным требованиям
качества.## Pull запросыПулл-запросы — это способ вносить конкретные изменения в код, документацию и зависимости в репозитории axum.
Даже небольшие пулл-запросы (например, пулл-запрос, исправляющий опечатку в документации API за одну букву) очень ценятся. Перед внесением крупных изменений обычно полезно сначала открыть задачу, описывающую изменения, чтобы получить отзывы и рекомендации. Это увеличит вероятность того, что пулл-запрос будет принят.
Если предложенные изменения затрагивают код (в отличие от изменения только документации, например), они либо добавляют новую функциональность в crate, либо исправляют существующую, сломанную функциональность. В обоих этих случаях пулл-запрос должен включать один или несколько тестов, чтобы убедиться, что crate не ухудшит свои характеристики в будущем.
Идеально, каждое API должно иметь хотя бы один [тест документации], который демонстрирует, как использовать API. Тесты документации запускаются с помощью cargo test --doc. Это гарантирует, что пример корректен и обеспечивает дополнительное покрытие тестами.
Трюк с тестами документации заключается в том, чтобы найти баланс между краткостью для удобства чтения и реальным тестированием API.
В документации Rust строки, начинающиеся с /// #, удаляются при генерации документации. Они присутствуют только для запуска теста.### Коммиты
Рекомендуется соблюдать лучшие практики и группировать ваши изменения логически в рамках отдельных коммитов. Нет ограничений на количество коммитов, которое может содержать любой пулл-запрос, и многие вкладчики находят удобным обзор изменений, разделённых на несколько коммитов.
Обратите внимание, что несколько коммитов часто сжимаются при слиянии (см. примечания о [сжатии коммитов]).
Хорошее сообщение коммита должно описывать, что изменилось и почему.
Оставить вторую строку пустой.
Обрезать все остальные строки до 72 столбцов (за исключением длинных URL).
Если ваш патч исправляет открытую задачу, вы можете добавить ссылку на неё в конце лога. Используйте префикс Fixes: # и номер задачи. Для других ссылок используйте Refs: #. Refs могут включать несколько задач, разделённых запятой. Примеры:
Исправляет: #1337Ссылается на: #1234, #42Изнутри GitHub, открытие нового запроса на вытягивание предложит вам заполнить [шаблон]. Пожалуйста, постарайтесь заполнить все детали, но не стесняйтесь пропустить части, если вы не уверены, что нужно вписать.[шаблон]: .github/PULL_REQUEST_TEMPLATE.md
Вероятно, вы получите обратную связь или запросы на изменения вашего запроса на вытягивание. Это большая часть процесса подачи, так что не расстраивайтесь! Некоторые участники могут сразу одобрить ваш запрос на вытягивание, другие могут иметь более детальные комментарии или обратную связь. Это необходимая часть процесса для оценки того, являются ли изменения правильными и необходимыми.
Любой участник сообщества может проверить PR, и вы можете получить противоречивые отзывы. Обратите внимание на комментарии от владельцев кода для предоставления руководства по противоречивым отзывам.
После открытия PR не рекомендуется выполнять ребейз коммитов. Подробнее см. [Сжатие коммитов].
В большинстве случаев, не сжимайте коммиты, которые вы добавляете к вашему запросу на вытягивание во время процесса проверки. Когда коммиты в вашем запросе на вытягивание появляются, они могут быть сжаты в один коммит на каждую логическую изменение. Метаданные будут добавлены в сообщение коммита (включая ссылки на запрос на вытягивание, ссылки на связанные проблемы, и имена рецензентов). Однако история коммитов вашего запроса на вытягивание останется неизменной на странице запроса на вытягивание.## Проверка запросов на вытягивание
Любой участник сообществ Tokio, Hyperium, Tower, axum может проверять любой запрос на вытягивание.
Все участники, которые выбирают проверять и предоставлять обратную связь на запросы на вытягивание, имеют ответственность перед проектом и тем, кто делает вклад. Проверки и обратная связь должны быть полезными, содержательными и направленными на улучшение вклада, а не просто блокированием его. Если есть причины, по которым вы считаете, что PR не должен быть принят, объясните, что это за причины. Не ожидайте, что вы сможете заблокировать запрос на вытягивание от продвижения просто потому, что вы скажете "Нет" без объяснения. Будьте открытыми к тому, чтобы изменить свое мнение. Будьте открытыми к работе с вкладчиком для улучшения запроса на вытягивание.
Проверки, которые являются пренебрежительными или неуважительными по отношению к вкладчику или любому другому рецензенту, строго противоречат Кодексу поведения. При обзоре Pull Request основные цели заключаются в улучшении кодовой базы и успехе человека, подающего запрос. Даже если Pull Request не будет принят, подающие запрос должны выйти из этого опыта с ощущением, что их усилия не были потрачены впустую или не были оценены. Каждый Pull Request от нового участника — это возможность для развития сообщества.### Обзорите по частям.
Не перегружайте новых участников.
Возникает соблазн микроподгонять и делать всё идеальным с точки зрения относительной производительности, идеальной грамматики или точного соответствия стилю. Не поддавайтесь этому соблазну.
Сначала сосредоточьтесь на самых значимых аспектах изменений:
Обратите внимание, что только незначительное улучшение требуется для принятия PR. Это означает, что PR не должен быть идеальным, он должен быть лучше текущего состояния. Следующие PR могут быть открыты для продолжения итераций.
Когда необходимы изменения, запрашивайте их, не требуйте их, и не предполагайте, что подающий запрос уже знает, как добавить тест или запустить бенчмарк.
Особые методы оптимизации производительности, стили кодирования и конвенции меняются со временем. Первое впечатление, которое вы оставляете для нового участника, никогда не будет забыто.Мелкие замечания (запросы на небольшие изменения, которые не являются обязательными) допустимы, но постарайтесь избегать задержек Pull Request. Большинство мелких замечаний обычно могут быть исправлены Collaborator проекта, который принимает Pull Request, но они также могут быть возможностью для участника узнать больше о проекте.Всегда полезно ясно указывать мелкие замечания в своих комментариях: например, Мелкий момент: измените foo() на bar(). Но это не блокирует.
Если ваши комментарии были учтены, но не были автоматически скрыты после новых коммитов или если они оказались ошибочными, пожалуйста, [скройте их][скрытие-комментария] с соответствующим объяснением, чтобы поддерживать лаконичность и релевантность обсуждения.
Будьте осведомлены о том, что как вы коммуницируете запросы и отзывы в вашем отзыве может иметь значительное влияние на успех Pull Request. Да, мы можем принять определенное изменение, которое сделает axum лучше, но индивидуум может просто не захотеть иметь ничего общего с axum никогда больше. Цель не только в том, чтобы иметь хороший код.### Брошенные или застопорившиеся Pull Requests
Если Pull Request кажется брошенным или застопорившимся, вежливо сначала
уточнить у вкладчика, намерен ли он продолжить работу, прежде чем проверить,
не возражает ли он, если вы возьмете его на себя (особенно если в нем осталось
немного недоработок). При этом вежливо признать первоначального вкладчика за
работу, которую он начал, сохраняя его имя и адрес электронной почты в журнале
коммитов или используя метаданный тег Author: в коммите.[hiding-a-comment]: https://help.github.com/articles/управление-деструктивными-комментариями/#скрытие-комментария
[documentation test]: https://doc.rust-lang.org/rustdoc/тестирование-документации.html
[keep-a-changelog]: https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )