QR code

Advice for First-Time Open Source Contributors

  • Translated by to

Моя первая попытка внести вклад в репозиторий с открытым исходным кодом была полным провалом. Я выбрал репозиторий на Java, который уже использовал (Glassfish Jersey), создал модульный тест для существующего класса, отправил патч (на тот момент не было запросов на объединение), и… его приняли. Я взволновался и отправил еще один модульный тест в новом патче. Неудивительно, владельцы репозитория попросили меня прекратить хулиганить: видимо, им не нужны модульные тесты просто так. Я быстро потерял интерес к внесению изменений в чужой код и начал работать над своими собственными вещами вместо этого.

Не повторяйте мою ошибку! Стать участником существующего кода - это гораздо быстрый путь в мир с открытым исходным кодом и намного более вознаграждающий. Вот несколько вещей, которые стоит иметь в виду, чтобы ваш путь к успеху был еще более быстрым - особенно если вы только начинаете делать свои первые запросы на объединение.

Изучите Существующие Файлы. Владельцы репозитория обычно гордятся своим кодом, несмотря на то, насколько он может быть уродливым. Не пытайтесь произвести впечатление на них своим уникальным форматированием или стилем именования; это только раздражит их. Вместо этого изучите несколько файлов, которые они написали, и постарайтесь максимально точно имитировать их стиль. Это безопаснее. Когда вы объединили несколько запросов на объединение, вы можете стать более творческими. Но не сейчас.

Не Спрашивайте, Создавайте Задачи. Вы не первый участник, и не будете последним. Многие перед вами задавали бесчисленные вопросы, но не написали ни одной строки кода. Владельцы репозиториев, особенно в больших проектах, не в восторге от того, чтобы учить вас или объяснять, как работает их код. Не беспокойте их в Telegram вопросами; это только продемонстрирует отсутствие дисциплины. Вместо этого сформулируйте каждый вопрос как новую задачу, указав, например: 1) отсутствие документации, 2) несогласованный дизайн, 3) высокая сложность или что-то еще, что мешает вам быстро понять код и вносить вклад. Такая задача сама по себе ценный вклад.

Вносите Маленькие Изменения. Нет ничего более раздражающего для сопровождающего, чем большой запрос на объединение от незнакомца. Причины просты: во-первых, незнакомцы обычно пишут плохой код; во-вторых, они часто разочаровываются, когда им говорят, что их код плохой. Поэтому инвестировать время в рассмотрение большого запроса на объединение от нового участника - рискованно. В то же время грустно видеть потенциально хороший код в мусорной корзине. Сделайте всем одолжение и начните с малого - менее 50 строк кода на каждый запрос на объединение. Этот подход приведет к более качественным обзорам и более быстрым объединениям.

Выбирайте Самые Простые Проблемы. Не знаете, что внести вклад? Прочтите их список задач и найдите самые простые для исправления. Не пытайтесь произвести впечатление в своем первом запросе на объединение, показывая, насколько вы умны. Вместо этого произведите впечатление, быстро найдя легкую задачу, исправив ее и получив ее объединение. В больших, качественных проектах действительно важно ваше умение пропустить ваш код через процесс проверок, линтеров и рецензентов. Чем проще проблему вы решите, тем быстрее ваше решение будет принято.

Напишите Тесты. Как просто это звучит: каждое изменение, которое вы вносите, должно быть мотивировано тестом, который доказывает, что код был сломан до этого. Если вы, как новичок, изменяете код, написанный владельцами, у вас должна быть очень хорошая причина. Когда они рассматривают ваш вклад, их первый вопрос будет: “Почему вы это сделали?”. Сильным аргументом будет тест, который не проходит. Вы даже можете рассмотреть отправку запроса на объединение только с тестом, который не проходит (отключен), получив его объединение, и затем отправить другой запрос на объединение, который исправляет тест.

Выглядите Как Человек. Ваш запрос на объединение выглядит подозрительно, потому что вы незнакомец. В век ИИ некоторые запросы на объединение могут поступать от ботов, и этот тренд только усилится. Вы должны доказать, что вы надежный человек: установите приличный аватар, укажите свое настоящее имя в профиле, заполните все обязательные поля и так далее.

Объясните Ваши Изменения. При отправке запроса на объединение есть текстовая область для описания. Если вы оставите ее пустой или напишете всего лишь несколько слов, звучит это так: “Привет, ребята, я написал немного кода. Теперь ваша задача разобраться, что он делает, почему это важно и как это работает. Я иду спать, потому что мне надоел ваш код. Удачи!”. Лишнего говорить, что это не поможет вашему запросу на объединение быть принятым в ближайшее время.

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

Будьте Вежливы и Настойчивы. Люди, которым вы отправляете код, могут быть грубыми. Не воспринимайте это на личный счет. Они имеют дело с сотнями новичков, которые пишут код низкого качества и предполагают, что он прекрасен. Независимо от того, насколько агрессивно или обидчиво они звучат, оставайтесь вежливыми и профессиональными. Не уходите после первого отрицательного комментария. Продолжайте настаивать на том, что ваш запрос на объединение заслуживает объединения. Обращайте внимание на то, что они говорят, а не на то, как они это говорят. В конце концов, вам хочется пропустить ваш код. Вы не хотите стать их другом; вы хотите, чтобы ваш код был объединен.

Вы также можете посмотреть мой курс [“Лучшие практики открытого исходного кода”], который недавно был прочитан студентам бакалавриата в [Университете Иннополиса]: [восемь видеолекций]. На лекциях подробно обсуждаются большинство вышеупомянутых тем.

Translated by ChatGPT gpt-3.5-turbo/42 on 2024-12-15 at 18:15

sixnines availability badge   GitHub stars