3. Убедитесь совместно с авторами проекта, что ваше предложение не противоречит идеологии Стандартов 1С и 1C:EDT. При этом авторы проекта всегда рады обсуждению новых идей, всегда на стороне участников, предлагающих улучшения, но при этом постараются максимально разъяснить случаи отказа в принятии идеи/реквеста, если таковые возникнут.
4. Реализуйте Ваше улучшение функциональности проекта в отдельном форке и предложите его через [Pull/merge request](#Pull-Requests-Merge-Requests)
## Доработка кода
### Написание проверок
См. [Соглашение при создании проверок](Check_Convention.md)
### Исправление ошибок
* Создайте `issue` в проекте с описанием ошибки. Убедитесь, что владельцы проекта так же считают текущее поведение ошибочным.
* Создайте ветку в своем **форке** с именем `bugfix/issue-<Номер issue>-доп-название`
* Создайте **pull-request** из своей ветки в ветку **`master`** проекта v8-code-style
* Убедитесь, что модификация кода действительно исправляет ошибку, описанную в issue, и не привносит новую функциональность - новую функциональность следует делать отдельным issue и pull-request'ом.
* Следуйте общим правилам [Pull/merge request](#Pull-Requests-Merge-Requests)
### Pull Requests (Merge Requests)
* Создайте `issue` в проекте с описанием новой функциональности, желательно перед началом работы, чтобы исключить параллельную работу разных людей над одной задачей
* Создайте ветку в своем **форке** с именем `feature/issue-<Номер issue>-доп-название`
* Внесите изменения в конфигурацию или расширение
* Создайте **pull-request** из своей ветки в ветку **`master`** проекта v8-code-style
* Укажите ссылку на issue, которую закрывает данный pull-request
* Установите в своем PR флажок "allow edits from maintainers"
### Правила оформления коммитов
Правила необходимы для предотвращения написания бессмысленных заголовков, мешающих пониманию ситуации на проекте. Хорошие оформленные коммиты помогают значительно облегчить процесс выяснения причин внесенных в код изменений, анализируя историю коммитов. Так же это необходимо для стилистического единообразия сообщений коммитов в репозитории.
#### Тексты сообщений коммитов
При написании сообщения коммита следует использовать формат:
```
#<НОМЕР ЗАДАЧИ> Короткое сообщение что сделано
Длинное сообщение что сделано
```
1. Начинаем с номера задачи (например, #12311). Идентификатор необходим для интеграции с задачами GitHub
2. В качестве разделителя между номером задачи и заголовком коммита используем пробел.
3. Далее идет заголовок коммита:
- Пишем на русском языке.
- Заголовок с большой буквы.
- В конце заголовка точку не ставим.
- Желательно использовать настоящее время, а не прошедшее (например, "Исправление ошибок запуска при указанной web ИБ").
- Рекомендуем писать не слишком длинный заголовок, так как его отображение во многих интерфейсах выполнено в одну строку без переносов, так что, он может не влезть. Подробные детали пишем отдельным параграфом в описании коммита.
4. Описание коммита (опционально).
- Отделяем от заголовка пустой строкой.
- Пишем полноценные предложения (начинаем с большой буквы, заканчиваем точкой)
- Хорошей практикой является ограничение длины строк в сообщении ≈72 символами, с добавлением переносов, если не влезает. Многие UI инструменты для GIT (в том числе EGit) не делают переносы текста описания, если он не влез.
Контент сообщения коммита:
В сообщении коммита пишем "что" и "почему" сделано, но избегаем деталей "как" сделано. Назначение комментария - дать коллегам понять, что происходит в проекте.
1. Заголовок должен быть ёмкий и информативный.
2. Заголовок должен быть написан официальным языком, без разговорных оборотов.
3. Чтобы определить достаточность детализации заголовка коммита, попробуйте ответить на вопрос, не заглядывая в код:
-`[Bug]` Какая конкретно проблема здесь исправлена?
-`[Feature]` Какая функциональность здесь добавлена?
-`[Refactoring]` В каких компонентах/классах произведен рефакторинг?
-`[Tests]` Что они тестируют?
-`[Baseline]` В каком компоненте/плагине/пакете подняли версию/версии?
-`[Документация]` В каком компоненте добавлена документация?
-`[Исправление замечаний]` Какие именно проблемы вы исправили?
4. Зачем писать сообщение коммита?
- Когда сделанные изменения неочевидны коллегам, то, помимо комментария в самом коде, не будет лишним описать детальнее, зачем эти изменения были сделаны или, почему сделаны именно так, а не иначе.
- При исправлении сложных багов можно воспользоваться методологией [Root_cause_analysis](https://en.wikipedia.org/wiki/Root_cause_analysis), и указать причину ошибочного поведения, а так же, каким образом это исправили. Человек (или даже вы сами), который через пару лет наткнется на неочевидное изменение, скажет вам спасибо.
#### Количество коммитов
Стоит ли делать один коммит на фичу - зависит от фичи. Коммит - логически завершенное изменение, а сложная фича может содержать много таких изменений, слияние которых в один коммит, приводит к потере информации о деталях ее выполнения. Это касается не только фич.
Squash'ить коммиты стоит, если были сделаны лишнее изменения, которые в следующих коммитах отменили. Так же, стоит избегать коммитов вида "Поднятие версий", которые не являются самостоятельными (вызваны другими изменениями, без них билд проекта не будет выполнен).
Лицензирование расширений, размещенных в данном проекте, осуществляется на условиях свободной (открытой) лицензии Eclipse Public License - v 2.0 (полный текст лицензии - https://www.eclipse.org/legal/epl-2.0/)
- Вы можете свободно и бесплатно заимствовать код и помещать его в свои проекты, учитывая однако, что такой код не становится вашей интеллектуальной собственностью, Вы лишь получаете неисключительные права его использования с учетом рамок и ограничений, описанных в EPL 2.0
- Внося изменения в расширение, модифицируя и дорабатывая его, а также объединяя файлы расширения с иными материалами, не относящимися к расширению (далее по тексту как «результаты работ»), Вы также обязаны публиковать это обновленный код на условиях EPL 2.0, т.е. автоматически предоставляете любым третьим лицам, включая ООО «1С-Софт» и иных контрибьюторов, безвозмездное право использования результатов Ваших работ на территории стран всего мира на условиях открытой лицензии EPL 2.0.
Загружая свои разработки, доработки и исправления к программам других авторов Вы также подтверждаете, что:
- являетесь единственным автором и обладателем имущественного права на результаты работ; в случае, если обладателем имущественного права на результаты работ является Ваш работодатель, Вы гарантируете наличие его согласия на публикацию кода на условиях открытой лицензии EPL 2.0;
- Вы снабдили результаты Ваших работ всеми необходимыми уведомлениями, свидетельствующими о том, что они подчиняются открытой лицензии EPL 2.0;
- Результаты Ваших работ доступны в виде исходного кода, или Вы обязуетесь сообщить, каким образом третьи лица без существенных затрат могут получить результаты Ваших работ в виде исходного кода;
- Bсе имеющиеся ранее уведомления других авторов (license notices) не были Вами удалены или изменены, а указанные Вами уведомления отражают достоверную информацию о Вас как правообладателе Вашего оригинального кода (включая ФИО или наименование организации-работодателя)
Пояснения выше приведены исключительно для удобства восприятия основных положений лицензии EPL 2.0. и не заменяет содержание понятий, приведенных по тексту лицензионного соглашения. Для более детального понимания Ваших прав и обязанностей рекомендуем ознакомиться с полным текстом открытой лицензии EPL 2.0.
Все файлы проекта, подлежащие лицензированию, должны иметь заголовок.
This program and the accompanying materials are made
available under the terms of the Eclipse Public License 2.0
which is available at https://www.eclipse.org/legal/epl-2.0/
SPDX-License-Identifier: EPL-2.0
Contributors:
1C-Soft LLC - initial API and implementation
```
Если вы не являетесь сотрудником фирмы 1С - допишите актуальную информацию в секцию `Contributors:`
Для всех новых или измененных файлов - выполняйте обновление копирайта: ПКМ по файлу - "Fix Copyrights".
### Язык проекта
Исходный код должен быть написан на Английском языке. Английский язык - является языком по умолчанию.
Не допускается использование транслита или иных не английских слов и терминов.
В случае, если вы затрудняетесь в выборе подходящего термина на английском - обратитесь за помощью в issue по вашей функциональности к владельцам проекта - мы всегда поможем!
Язык ведения проекта (issue, аудит и т.д.) - Русский, т.к. ориентация на русское сообщество программистов.
Поддержка разработчиков на других языка в будущем может быть решена дополнительно.
Все интерфейсные тексты, которые видит пользователь, должны быть написаны на английском яызке и локализированы - вынесены в отдельные ресурсные файлы `*.properties`.
Для большего удобства используйте помощник Eclipse Externalize Strings Wizard, который помогает переносить интерфейсные строки из кода в ресурсные файлы, с автоматическим созданием файла констант NLS.
Для редактирования ресурсных файлов следует использовать плагин из Маркет-плайса Eclipse: [ResourceBundle Editor](https://marketplace.eclipse.org/node/2628188) или аналогичны, позволяющий синхронно редактировать интерфейсы на нескольких языках, корректно учитывающий кодировку UTF-8.
