Понимание культуры открытого исходного кода: лучшие практики для эффективного участия

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

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

:::Информация

Примечание. Эта статья может быть полезна, только если вы знакомы с базовой терминологией git и понимаете начальный рабочий процесс использования Git и GitHub.

Вот некоторые из лучших практик, которые вы можете использовать для своего следующего вклада!

Культура и общение

Сообщества с открытым исходным кодом — это большой пул людей из разных социальных и этнических слоев, рас, религий и языков. Таким образом, лучший способ идти вместе со всеми — это практиковать эмпатию.

• Во время обсуждения всегда следите за тем, чтобы ваш тон оставался дружелюбным и уважительным.

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

• Оставайтесь смиренным и скромным. Никто из нас не знает всего. Мы все учимся. Некоторым разработчикам может понадобиться помощь с чем-то очень простым, будьте добры и протяните руку помощи, когда сможете.

• Постарайтесь узнать как можно больше, посвятите время изучению кодовой базы и попытайтесь понять вещи, прежде чем задавать вопрос на общедоступном канале или открывать проблему. В любом случае, если вам кажется, что вы застряли с чем-то, не стесняйтесь задавать вопросы коллегам-разработчикам. Точно так же уважайте пространство и вопросы, заданные другими.

• Будьте милы и приветливы. Цените своих коллег-разработчиков и участников за их хорошую работу. Продлите "пожалуйста" или "спасибо" в обсуждении, чтобы выразить вежливость и великодушие.

Каналы связи

Большинство сообществ с открытым исходным кодом имеют свои собственные частные или общедоступные каналы связи, такие как Slack, Discord, Gitter и т. д., поскольку чат — отличный способ связаться с другими участниками и сопровождающими.

Чтобы эффективно использовать эти каналы, участники должны стараться следовать следующим пунктам:

• Не переключайтесь на приватное общение с сопровождающим или другим участником до тех пор, пока в этом нет необходимости. Это отключает других участников, которые могут столкнуться с теми же проблемами, и могут сразу же получить помощь, прочитав предыдущую беседу.

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

Запросы функций и отчеты об ошибках

Запросы функций и отчеты об ошибках лучше всего обрабатывать через GitHub, но необходимо выполнить определенные шаги, чтобы использовать их конструктивно:

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

• Старайтесь включать всю необходимую информацию, когда вы отправляете вопрос, чтобы помочь другим легко понять его. Включите ссылки, информацию о коде, который необходимо изменить, и скриншоты, где это необходимо.

• Разбивайте большие запросы функций на более мелкие задачи, чтобы над ними могли одновременно работать несколько участников.

• Всегда не забывайте добавлять шаги для воспроизведения ошибки, о которой вы сообщаете, при отправке отчета об ошибке.

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

Разработка

После того, как вы определились с проектом с открытым исходным кодом, в который хотите внести свой вклад, первым шагом будет установка проекта на локальном компьютере и его запуск. Шаги обычно определяются в файле README.md. Следующим шагом будет изучение политики филиала и руководств по внесению вклада этого проекта. Их можно легко найти в файле CONTRIBUTING.md. Как только вы закончите, вы можете начать с изменений в проекте.

Между тем, во время разработки, если у вас есть какие-либо сомнения или вы сталкиваетесь с какими-либо проблемами, не стесняйтесь задавать вопросы сопровождающим или другим участникам. (Вы можете либо использовать канал связи, либо продолжить разговор через GitHub.)

Коммиты и пулреквесты

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

• Пишите осмысленные сообщения фиксации, которые сообщают, какие изменения были сделаны. Например:
  

• Убедитесь, что вы используете минимальное количество коммитов для изменения. Если у вас много коммитов для небольшого исправления, сквош их перед созданием PR.

• Вносить в PR только те изменения, которые были упомянуты в выпуске. Не меняйте ничего, что не имеет отношения к этой конкретной проблеме.

• Всегда связывайте свой PR с проблемой, которую он устраняет. Узнайте, как это сделать [здесь] (https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#:\~ :text=На%20GitHub%2C%20перейдите%20к%20,к%20связать%20к%20к%20проблеме.).

• Делайте PR из собственных форков (даже если у вас есть права на репо, не создавайте новые ветки, развивайтесь на своих ветках).

• Укажите фактические улучшения или изменения, сделанные в PR, а не просто упоминание «Исправления № 1». Обратитесь к шаблону PR для получения подробной информации, если он есть в проекте.

• Не забудьте добавить скриншот или видео, если вы внесли какие-либо изменения в пользовательский интерфейс. Это ускоряет процесс проверки в геометрической прогрессии.

• Помогите рецензентам решить конфликты слияния, если таковые имеются. Подробнее о конфликтах слияния читайте [здесь] (https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/addressing-merge-conflicts).

Документация

Все в пространстве с открытым исходным кодом происходит посредством обмена словами. Таким образом, документация является важным шагом для предоставления информации о вашем вкладе.

Документация — это непрерывная работа на каждом этапе разработки программного обеспечения.

• Добавляйте информацию о новых технологиях, фреймворках, библиотеках и коде через комментарии и в файлы документации, например, в папку README.md или /docs.

• Всегда обновляйте документацию и облегчайте присоединение новых участников к проекту.

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

Это все, чему я научился на своем пути в open-source. Я надеюсь, что упомянутые выше практики приблизит вас к вашему следующему (эффективному) вкладу с открытым исходным кодом и помогут вам реализовать свой шанс отдать долг сообществу, по одному коммиту за раз!

Если вы найдете это проницательным, дайте мне знать ваше мнение в комментариях. Также приветствуются любые отзывы. Если вы хотите связаться со мной, перейдите по ссылкам ниже:

LinkedIn | [GitHub] (https://github.com/PragatiVerma18/) | [Твиттер] (https://twitter.com/pragati_verma18) | [StackOverflow] (https://stackoverflow.com/users/10364459/pragati-verma)

Также опубликовано [здесь] (https://dev.to/pragativerma18/open-source-best-practices-902).