fix: Make checklist with checkboxes

contributing.md

@@ -8,53 +8,53 @@
 
 ## Создание новой функциональности
 
- - проработка предметной области и выделение основных абстракций;
- - написание кода, реализующего эти абстракции;
+- [ ] проработка предметной области и выделение основных абстракций;
+- [ ] написание кода, реализующего эти абстракции;
 
 > Следует предоставлять в модулях _простые_, _понятные_ и _полные_ (_симметричные_) интерфейсы.
-> 
+>
 > Огромное количество полезных рекомендаций приведено в [соответствующем документе](code-style.md).
 
- - покрытие написанного кода спеками;
+- [ ] покрытие написанного кода спеками;
 
 > Хорошей практикой является покрытие типами и спеками элементов и процессов, присутствующих в предметной области.
-> 
+>
 > Необходимо стремиться к сужению области определения различных типов, чтобы инструменты статического анализа действительно могли помочь в поиске проблем с написанным кодом.
 
- - покрытие написанного кода тестами;
+- [ ] покрытие написанного кода тестами;
 
 > Большее внимание стоит уделять тестам, затрагивающим исключительные, неуспешные или ошибочные сценарии использования нового функционала, и только потом – тестам успешных или штатных сценариев использования.
-> 
+>
 > Тесты должны быть _самодостаточными_, иными словами явно поддерживать настройку критичного для тестовых сценариев окружения, [_mocking_](https://en.wikipedia.org/wiki/Mock_object) или работу с эфемерными внешними зависимостями, будь то девственно чистые базы данных, пустые списки и правила контроля доступа или отсутствующие сервера доменных имён. В экстремальных случаях возможно даже отсутствие интернета на время запуска и прогона тестов.
-> 
+>
 > Необходимо отказаться в тестах от стохастического поведения, привнесения элемента случайности. Также не стоит использовать слишком большие, ничем не оправданные задержки. Каждая операция в тестовом сценарии должна иметь понятный и чётко определённый критерий завершения.
 >
 > Сценарии, опять же _по возможности_, должны быть написаны с расчётом на то, что они будут запускаться в экстремальном случае в параллельном режиме, одновременно и в случайном порядке.
-> 
+>
 > Если инструменты для тестирования дают такую возможность, следует давать тестам понятные разработчику названия и/или описания.
 
- - написание документации;
+- [ ] написание документации;
 
 > Если вносимое изменение каким-либо образом отражается на внешних интерейсах сервиса, приложения или библиотеки (при решении бизнес-задач случается в 95% случаев), этот эффект должен быть отражён в документации.
-> 
+>
 > Если реализация задачи привела к появлению нового, отдельного сервиса, хорошей мыслью будет сразу написать к нему краткую операционную документацию. Вопросы, которые непременно будут волновать админов / операторов: установка, начальная настройка, запуск, проверка работоспособности и конечно же _остановка_.
-> 
+>
 > Чем ближе документация к репозиторию с кодом, тем лучше.
 
- - подготовка процессов миграции.
+- [ ] подготовка процессов миграции.
 
 > Если необходима миграция и она может быть проведена без участия человека, она _должна_ быть проведена автоматически. В ином случае процессы миграции должны быть подробно задокументированы.
-> 
+>
 > Также не лишним будет задокументировать _последствия_ миграции.
 
 ## Правка багов
 
- - анализ ситуации, в которой наблюдается ошибочное поведение;
- - написание одного или нескольких тестовых сценариев, покрывающих эти ситуации;
+- [ ] анализ ситуации, в которой наблюдается ошибочное поведение;
+- [ ] написание одного или нескольких тестовых сценариев, покрывающих эти ситуации;
 
 > Хорошим тоном будет сразу провести прогон тестов и проверить, что новые тестовые сценарии действительно завершаются неуспешно в отсутствии исправления.
 
- - исправление логики в исходном коде.
+- [ ] исправление логики в исходном коде.
 
 > После этого все тестовые сценарии из предыдущего пункта должны завершатся успешно.
 >