for-contributors.md

Руководство для контрибьютеров

Code style

За основу берем Airbnb JavaScript Style Guide. На русском uprock/javascript.

Есть небольшие отличия в code style Airbnb от того, как нужно писать JavaScript в TARS:

1. Пробелы и табуляция Для отступов и табуляции используем 4 пробела, а не 2:

   function () {
   ∙∙∙∙const name;
   }

2. Длина строки (line length). Требования длины строки в 80 символов следует считать опциональным. Т.е. строки не должны быть слишком длинными, и должны помещаться в окно редактора даже на небольшом мониторе.

3. Комментарии. Ко всем неочевидным с первого взгляда кускам кода пишем комментарии. Обязательно !осмысленные! и на английском языке. Все комментарии будут модерироваться, поэтому стараемся писать на хорошем английском.

4. Строгое равенство/не равенство (=== / !==) Исходим из здравого смысла и пользуемся только там, где это действительно необходимо. Например в случаях с null или undefined.

5. Используем стрелочные функции по-максимуму.

6. Используем const для всего, что не будем менять. let — для переменных внутри блока (циклы), var — функциональная видимость переменной.

Чтобы проверить, все ли учтено в вашем коде, прогоните его через eslint с настройками, которые лежат в корне TARS.

Правила работы с ветками, issue и т.д.

Вы можете создать Pull request как в мастер, так и в отдельную ветку.

Реквест в мастер

В данном случае необходимо, чтобы код соответсвовал code-style, в нем не было ошибок и он не менял функциональность TARS — не добавлял и не убирал. Если предполагается изменение функциональности, то реквест необходимо делать в ветку с текущей разрабатываемой версией.

Необходимо добавить описание к реквесту, желательно на английском языке. Если есть проблемы с англйиским, то пишем описание на русском.

Реквест в ветку или реквест ветки

Ветка должна иметь вменяемое имя, в котором кратко будет описано, о чем эта ветка. Запрещается название веток на русском языке.

Если ваша правка относится к какой-либо версии, то название ветки должно начинаться так: version-*.*.*-add-something. Звездочки — конкретная версия, к которой относится реквест. Например, version-1.3.0-add-sourcemaps.

Работа с issue

Если вы хотите выполнить какой-либо issue, важно получить одобрение на его выполнение от @artem-malko.

Чтобы оставить заявку, достаточно написать в комментарии к задаче: I'll make it. После этого нужно получить от меня большой палец (смайл в виде большого пальца поднятого вверх) и на задаче должен появиться лэйбл in progress. После этого можно брать задачу в работу. Задачу необходимо выполнять в отдельной ветке, которая образована от ветки текущей разрабатываемой версии, например от version-1.3.0. О том, как создавать реквест в ветку рассказано выше.

Дополнительные контрибуторы не допускаются, если на задаче есть лейбл in progress.

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

Брать в работу можно только ту задачу, у которой есть хотя бы 1 лэйбл (кроме лейбла backlog) и она имеет какую-либо версию. Задачи без версии в работу не беруться, однако тут можно обсудить отдельно, возможно, задача может попасть в какой-либо ближайший релиз, если вы готовы ее выполнить.

Создание pull-реквестов

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

Все реквесты должны пройти аппрув от @artem-malko и тесты в travis и appveyor. Аппрув — 1 большой палец от @artem-malko. Если задачу сделал @artem-malko, то необходим палец любого другого разработчика.

Внимание! Сливать свой реквест можно только после аппрува @artem-malko.

После того, как реквест слит, необходимо удалить ветку, в которой велась работа.