The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Это руководство объясняет рабочий процесс, используемый при работе с проектом XDSD, размещенным на GitHub. Вы начинаете, когда вам назначается проблема GitHub. Затем вы получите сообщение от менеджера проекта, содержащее номер проблемы, заголовок, описание и бюджет в часах (обычно 30 минут).
Если вы не согласны с распределением бюджета, не стесняйтесь просить его увеличить. Как только вы будете удовлетворены бюджетом и понимаете объем работы, сообщите об этом в ответе на запрос и приступайте к работе. Имейте в виду, что вы не будете оплачиваться за время, превышающее выделенный бюджет времени.
Несмотря на то, что вы являетесь частью команды разработчиков, у вас нет прав на запись в репозиторий на GitHub. Следовательно, чтобы внести изменения, вам следует сделать форк репозитория в своей учетной записи GitHub (создать его частную копию), внести необходимые изменения, а затем отправить их на рассмотрение с помощью “запроса на объединение”.
После того, как вы отправите запрос на объединение на рассмотрение, владелец репозитория одобряет ваши изменения, объединяя их в основной репозиторий. Таким образом мы защищаем основной поток разработки от случайного повреждения.
В этой статье объясняется, как сделать форк репозитория: ссылка
В этой статье объясняется, как скачать и установить GitHub на ваш компьютер: ссылка
И, наконец, не забудьте добавить свой личный SSH-ключ на GitHub: ссылка
После того, как вы сделали форк нашего репозитория в свой аккаунт, склонируйте его на свой компьютер и переключитесь на ветку master. Например:
Теперь пришло время создать ветку (123 - это номер проблемы на GitHub, с которой вы собираетесь работать, а также имя ветки).
По соглашению мы используем одинаковые названия для ветки и задачи, над которыми вы работаете.
Все вопросы, связанные с задачей, следует обсуждать в вопросе на GitHub. Вопросы, связанные с GitHub, не обсуждаются по электронной почте, Skype, телефонным звонкам или встречам. Все вопросы следует задавать непосредственно в вопросах на GitHub.
Не стесняйтесь создавать новые вопросы, если что-то не ясно или вам нужна помощь. Очень часто бывает, что вам может быть сложно выполнить задачу. Не паникуйте. Это обычно происходит, когда вы только присоединились к проекту и еще не имеете достаточно информации. Если это происходит, не пытайтесь самостоятельно разобраться с проблемой или вопросом.
Золотое правило в такой ситуации гласит: “Если что-то не ясно, это наша вина, а не ваша”. Поэтому, если вы не понимаете проектный дизайн, это вина дизайнера проекта.
Отправьте отчет об ошибке, запросив объяснение концепции дизайна. За этот отчет вам будет выплачена оплата, и информация, которую вы получите в ответе, будет общей для всех других разработчиков.
Прочтите эту статью: Баги приветствуются.
Не ожидайте помощи от кого-либо. Вашим единственным источником помощи является сам исходный код. Если код не объясняет все, что вам нужно знать - это баг, который должен быть сообщен.
Внесите необходимые изменения с помощью текстового редактора или среды разработки. Хорошей практикой является фиксация изменений сразу после их внесения. Не накапливайте большое количество изменений на протяжении продолжительного времени перед фиксацией их.
Если у вас есть вопросы о объеме работы, задавайте их в проблеме на GitHub и ждите ответа. Если вы считаете, что существующий код нуждается в улучшениях, не стесняйтесь создать новую проблему на GitHub.
Не пытайтесь исправить все проблемы в одной ветке; позвольте другим программистам заботиться о них.
Создайте запрос на объединение (pull request) в GitHub, используя процесс, описанный в следующей статье: использование pull-запросов
Опубликуйте его номер в исходной задаче и дождитесь обратной связи.
Через некоторое время ваш запрос на объединение будет просмотрен кем-то из команды проекта. Во многих случаях вы можете получить несколько отрицательных комментариев, и вам придется исправить все проблемы, связанные с ними. Ваш запрос на объединение не будет включен в ветку master, пока ваши изменения не удовлетворят рецензента.
Будьте терпеливы с рецензентом и внимательно слушайте его. Однако не думайте, что ваш рецензент всегда прав. Если вы считаете, что ваши изменения действительны, настаивайте на том, чтобы кто-то еще их просмотрел.
После того, как вы внесете необходимые изменения в ветку, не забудьте уведомить рецензента в задаче, разместив сообщение, адресованное ему/ей. На каждом этапе цикла рецензирования и исправления проделайте то же самое: попросите рецензента еще раз взглянуть на ваш код. Без таких уведомлений ваш запрос на объединение может оставаться в тишине намного дольше.
Когда все выглядит хорошо для рецензента, он сообщит нашему автоматизированному боту о слиянии. Затем автоматизированный бот выберет вашу заявку и попытается слить ее с веткой “master”. По разным причинам эта операция часто не удается. Если слияние не удалось, независимо от причины, вашей обязанностью будет убедиться, что ваша ветка успешно слита.
Если вы не можете слить ветку из-за ошибок в тестах, не связанных с вашей задачей, не пытайтесь исправить их сами. Вместо этого сообщите о проблеме как о новой ошибке и дождитесь ее устранения.
Помните, что до тех пор, пока ваша ветка не будет слита, вам не будет выплачена оплата.
Когда ваши изменения объединены, вернитесь к проблеме на GitHub и попросите автора закрыть ее. Как только проблема будет закрыта менеджером проекта, вы получите оплату в течение нескольких часов.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 10:39
