The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Вот краткий список общих правил вежливости для разработки программного обеспечения с открытым исходным кодом. Фактически, они применимы везде, но они наиболее заметны при использовании GitHub для разработки. Я твердо верю, что рано или поздно весь программный код будет открытым, и эти правила будут применяться ко всем. Поэтому имеет смысл начать следовать им сейчас, будь вы активным участником Apache или счастливым обладателем книги “Java для чайников”.
В произвольном порядке:
Создавайте небольшие Pull Requests. Недавнее исследование, проведенное Кейтлин Садовски и др. из Google и Университета Цюриха, показало, что существует сильная корреляция между размером изменения и качеством рецензии: большие изменения (pull requests) негативно влияют на качество. Согласно этой статье, разработчики Google настоятельно рекомендуют делать небольшие, постепенные изменения. Кроме Google, многие другие также говорят то же самое: Microsoft, Zalando, Atlassian и OpenSource.com.
Не объединяйте изменения. Может быть соблазн объединить все изменения, которые вы хотите внести, в один pull request, чтобы их было быстрее слить и получить только один обзор. Не делайте этого. Это только усложнит процесс и раздражит ваших рецензентов. Правило простое: одно изменение = один pull request.
Используйте красивый Markdown в своей документации. Я не смог найти научных исследований на эту тему, возможно, потому что это очевидно: текст “почему f nil?” намного легче читать, чем “почему f nil?” Форматирование текста не только делает его более красивым, но также помогает читателям быстрее и с большим удовольствием усваивать содержание. После изучения Markdown я бы порекомендовал прочитать этот блог-пост Аарона Станнарда из PetaBridge: Как использовать GitHub профессионально.
Обращайтесь к своим комментариям. Всегда, без исключений, начинайте свои комментарии (либо в pull request, либо в issue) с ника на GitHub человека, с которым вы общаетесь. Если вы этого не сделаете, сообщение не дойдет до адресата и, скорее всего, будет потеряно. Люди, активно участвующие в GitHub, получают сотни писем от GitHub каждый день: они их не читают. Они читают только то, что попадает в раздел “Уведомления”.
Говорите Пожалуйста, Спасибо и Извините. Согласно Папе Франциску, успех заключается в произнесении трех простых слов. Он не имел в виду разработчиков с открытым исходным кодом, но этот совет идеально подходит для нас, программистов. Существует множество статей о правилах этикета в онлайн-коммуникации, и все они по сути одинаковы: просите вежливо, будьте благодарны и готовы признать ошибку. Я рекомендую 15 правил общения в GitHub Бена Балтера, старшего менеджера продукта в GitHub.
Пингуйте их. Когда вы вносите изменения в ветку и хотите, чтобы ваш pull request был пересмотрен снова: отправьте сообщение, явно просив вашего рецензента взглянуть на него еще раз. Когда вы отправляете pull request, разместите в нем сообщение, адресованное архитектору проекта, попросите его просмотреть PR. И так далее. Не ожидайте, что они будут следить за вашей активностью. У них есть другие дела. Ваша обязанность - напомнить о себе.
Создавайте описательные коммиты. Стиль форматирования сообщений о коммитах в Git (я уверен, что вы используете Git) обычно очень специфичен для каждого проекта. Однако, есть некоторые сходства и общие правила. Я бы рекомендовал эти блог-посты: Как написать сообщение о коммите в Git Криса Бимса, Несколько советов по этикету коммитов Джереми Гантера и Примечание о сообщениях коммитов в Git Тима Поупа. Также посмотрите на это: conventionalcommits.org и Форматирование 50/72.
Имейте аватар. Исследование Кристин Л. Новак и др. из Университета Коннектикут показывает, что пользователи с аватарками, особенно женскими и антропоморфными, привлекают больше внимания, чем те, у кого нет фотографий профиля (или у кого есть стандартные, предоставленные GitHub). Конечно, не только аватар важен; ваш профиль GitHub также должен содержать много других вещей: описание, адрес электронной почты, закрепленные репозитории и т.д. Используйте этот профиль в качестве примера: @m0nica.
Оставайтесь в сети. Офлайн-коммуникация гораздо дешевле, чем онлайн-запросы: просто задайте вопрос в офисе, и вы получите ответ немедленно. Нет необходимости писать длинные запросы, формулировать вопросы на английском, ждать, когда ответчик опубликует ответ и так далее. Однако офлайн-разговор вредит проекту по множеству причин. Каждый раз, когда вы переходите от проблемы на GitHub к чату в Slack для обсуждения, вы делаете диссервис проекту и всем его участникам. Помните об этом.
Сообщайте вежливо. Как и с коммитами в Git, правила для сообщения об ошибках отличаются от проекта к проекту, но основные принципы остаются теми же. Просто гуглите “[как написать сообщение об ошибке](https://
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-05 at 21:47
