From d551e34d0e70c17810463ed78d2e0a7aeb596cdd Mon Sep 17 00:00:00 2001 From: Daniil Sitdikov Date: Thu, 5 Sep 2019 18:32:07 +0300 Subject: [PATCH 1/7] proposal/process-review-no-code-managment-tasks common: added info --- doc/common/README.md | 36 ++++++++++++++++++++++++++++-------- 1 file changed, 28 insertions(+), 8 deletions(-) diff --git a/doc/common/README.md b/doc/common/README.md index 7cbe926b..9ae19b71 100644 --- a/doc/common/README.md +++ b/doc/common/README.md @@ -576,7 +576,27 @@ g. Все вопросы по ревью обсуждаются наибыстр использовать такой способ коммуникации, при котором ответ затягивается, а соответственно затягивается и ревью. -#### 6.4.4. Противоречия и споры в процессе обзора кода +#### 6.4.4. Процесс обзора задачи, не связанных с системой управления кодом (Github, Gitlab) + +Такие задачи, как документирование в Notion, Confluence и пр. + +1. Ревьюер в процессе обзора кода фиксирует свои замечания и пожелания в одном +месте. \ +Например: +[Документ GoogleDocs](https://docs.google.com/spreadsheets/d/1yZT4qOec28r-uTDg9uz3TOvNi5I0ePbppZa7URWby1s/edit?usp=sharing) + +2. После того, как ревьюер завершил фиксирование замечаний, он уведомляет об этом автора задачи. + +3. Автор задачи знакомится со списком замечаний и пожеланий, готовит список вопросов и обсуждает + их с ревьюером. + +4. После того, как автор задачи завершил улучшение проделанной работы и отметил все пункты как + завершённые, он также сообщает об этом ревьюверу. + +5. Если ревьювер с чем-то не согласен, он отмечает незавершённые пункты и отдаёт их на доработку, + и процесс повторяется с шага 4. + +#### 6.4.5. Противоречия и споры в процессе обзора кода a. Споры и затягивание обзора кода не допускаются. @@ -590,7 +610,7 @@ c. Не допускается повторных обсуждений по по уже принятых правил написания кода. Это не исключает возможности договориться о новых при хорошем уровне коммуникаций и взаимопонимания в команде. (см. пункт выше) -#### 6.4.5. Правила для участников, проверяющих код +#### 6.4.6. Правила для участников, проверяющих код a. Закрыв файл после проверки, вы тем самым полностью принимаете этот вариант так, как будто это написали вы. А так же вы уже несёте ответственность за уровень качества и работоспособности кода. @@ -601,7 +621,7 @@ b. Если что-то правится быстро (5-10 секунд) и о то можно уведомить автора об этих изменениях, чтобы он получил дополнительный опыт и учитывал его в дальнейшей работе. -#### 6.4.6. Состав участников обзора кода +#### 6.4.7. Состав участников обзора кода a. Запрос на влитие изменений должен быть сделан на двух участников команды, которые в состоянии понять смысл изменений и подтвердить их корректностью. Не может считаться @@ -635,7 +655,7 @@ d. [?] В качестве варианта ревью, возможно, сто автором с пояснениями. Это может сократить время, необходимое участникам команды на осмысление кода каждому в отдельности. -#### 6.4.7. Написание комментариев в процессе обзора кода +#### 6.4.8. Написание комментариев в процессе обзора кода a. Критиковать код, а не автора. Помните, раз вы увидели этот код - то он уже тоже ваш. @@ -658,7 +678,7 @@ d. Не писать в побудительном наклонении: `Исправь А на Б` ``` -#### 6.4.8. Отношение к комментариям в обзоре кода +#### 6.4.9. Отношение к комментариям в обзоре кода a. Не оправдываться в комментариях: `А, да, точно, я затупил`, `Я невыспался` и т.д. @@ -671,14 +691,14 @@ c. Запомнить ситуацию, усвоить полученный оп d. Если не согласны - обсудить. Не использовать агрессивно-защитные высказывания и пассивное игноирование. Держать в голове всегда цели обзора кода и команды в целом. -#### 6.4.9. Проверка стиля кода +#### 6.4.10. Проверка стиля кода a. У каждого участника должны быть настроены все автоматизированные средства для автоматической проверки и исправлений кода. b. В результате необходимо стремиться к отсутствию комментариев, касающихся стиля кода. -#### 6.4.10. Приоритет обзора кода +#### 6.4.11. Приоритет обзора кода a. Обзор кода не должен задерживать поток задач, соответственно должен быть приоритетным как для просматривающего изменения, так и для автора изменений. Задача в состоянии "ревью" @@ -692,7 +712,7 @@ b. Идеальное время влития изменений равно ну c. Запрос на влитие изменений не должен отправляться на участников команды, которые не могут своевременно выполнить обзор кода. -#### 6.4.11. Учёт при планировании +#### 6.4.12. Учёт при планировании a. Время на ревью и исправления должно учитываться при планировании задач на итерацию. From 64f5da8067d0b40e66242fd465f92033d019a1c4 Mon Sep 17 00:00:00 2001 From: Daniil Sitdikov Date: Thu, 5 Sep 2019 19:29:39 +0300 Subject: [PATCH 2/7] proposal/process-review-no-code-managment-tasks common: updated info --- doc/common/README.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/doc/common/README.md b/doc/common/README.md index 9ae19b71..e439c38c 100644 --- a/doc/common/README.md +++ b/doc/common/README.md @@ -569,10 +569,13 @@ d. Участники, проверяющие код, добавляют ком e. Комментарии отмечает выполненными автор изменений, код которого просматирвают. -f. После корректировки замечаний и реализации предложений должен запрашиваться +f. В начале процесса исправления замечаний задача переводится в соотвествующий рабочий статус. + После завершения исправлений задача переводится обратно в статус ревью. + +g. После корректировки замечаний и реализации предложений должен запрашиваться повторный обзор кода. -g. Все вопросы по ревью обсуждаются наибыстрейшим из возможных способов. Недопустимо +h. Все вопросы по ревью обсуждаются наибыстрейшим из возможных способов. Недопустимо использовать такой способ коммуникации, при котором ответ затягивается, а соответственно затягивается и ревью. @@ -585,10 +588,11 @@ g. Все вопросы по ревью обсуждаются наибыстр Например: [Документ GoogleDocs](https://docs.google.com/spreadsheets/d/1yZT4qOec28r-uTDg9uz3TOvNi5I0ePbppZa7URWby1s/edit?usp=sharing) -2. После того, как ревьюер завершил фиксирование замечаний, он уведомляет об этом автора задачи. +2. После того, как ревьюер завершил фиксирование замечаний, он уведомляет об этом автора задач. 3. Автор задачи знакомится со списком замечаний и пожеланий, готовит список вопросов и обсуждает - их с ревьюером. + их с ревьюером. В начале работы над исправлениями по замечаниям автор задачи меняет статус задачи + на соответствующий рабочему. 4. После того, как автор задачи завершил улучшение проделанной работы и отметил все пункты как завершённые, он также сообщает об этом ревьюверу. From 5834264f6786efd17cf120724e3cab6abd18f868 Mon Sep 17 00:00:00 2001 From: Daniil Sitdikov Date: Sun, 8 Sep 2019 17:55:27 +0300 Subject: [PATCH 3/7] proposal/review-process-node-code-tasks common: fixed process description --- doc/common/README.md | 39 ++++++++++++++++++++++++++------------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/doc/common/README.md b/doc/common/README.md index e439c38c..e00cddb9 100644 --- a/doc/common/README.md +++ b/doc/common/README.md @@ -583,22 +583,35 @@ h. Все вопросы по ревью обсуждаются наибыстр Такие задачи, как документирование в Notion, Confluence и пр. -1. Ревьюер в процессе обзора кода фиксирует свои замечания и пожелания в одном -месте. \ -Например: -[Документ GoogleDocs](https://docs.google.com/spreadsheets/d/1yZT4qOec28r-uTDg9uz3TOvNi5I0ePbppZa7URWby1s/edit?usp=sharing) - -2. После того, как ревьюер завершил фиксирование замечаний, он уведомляет об этом автора задач. - -3. Автор задачи знакомится со списком замечаний и пожеланий, готовит список вопросов и обсуждает - их с ревьюером. В начале работы над исправлениями по замечаниям автор задачи меняет статус задачи +Мотивация:\ +Сократить количество отвлекающих воздействий на автора изменений до 2 (в позитивном сценарии), +меньше отвлекая друг друга от работы. + +1. Рецензент в процессе обзора кода фиксирует свои замечания и пожелания в одном + месте. \ + Например: тематический канал в Slack, с отключёнными уведомлениями. \ + Формат сообщений: \ + 1: [Номер задачи]: [краткое описание задачи], [ссылка на задачу] \ + 2: [Замечание или пожеление 1] \ + 3: [Замечание или пожеление 2] \ + N+1: [Замечание или пожеление N] + +2. После того, как рецензент завершил фиксирование замечаний, он уведомляет об этом автора задач. + А также переводит задачу в статус «открыта» / «переоткрыта», чтобы другие рецензенты делали + обзоры только на непросмотренные задачи. + +3. Автор задачи знакомится со списком замечаний и пожеланий, называет список вопросов и обсуждает + их с рецензентом. В начале работы над исправлениями по замечаниям автор задачи меняет статус задачи на соответствующий рабочему. -4. После того, как автор задачи завершил улучшение проделанной работы и отметил все пункты как - завершённые, он также сообщает об этом ревьюверу. +4. Автор задачи отмечает сделанные задачи смайлом: ✔ + +5. После того, как автор задачи завершил улучшение проделанной работы и отметил все пункты как + завершённые, он также сообщает об этом рецензенту. -5. Если ревьювер с чем-то не согласен, он отмечает незавершённые пункты и отдаёт их на доработку, - и процесс повторяется с шага 4. +6. Рецензент отмечает смайлом ✔ те пункты, в которых он уверен, что они исправлены или не нуждаются +в исправлении. Если рецензент с чем-то не согласен, он уведомляет автора задачи о необходимости +её доработать, и процесс повторяется с шага 2. В другом случае задача переводится в состояние «Готово». #### 6.4.5. Противоречия и споры в процессе обзора кода From 1fe1a347e1bc9004edebf0113a0bbc083f131821 Mon Sep 17 00:00:00 2001 From: Daniil Sitdikov Date: Mon, 9 Sep 2019 11:13:22 +0300 Subject: [PATCH 4/7] proposal/review-process-node-code-tasks common: removed double quotes to tree quotes; updated rules --- doc/common/README.md | 49 ++++++++++++++++++++++++-------------------- 1 file changed, 27 insertions(+), 22 deletions(-) diff --git a/doc/common/README.md b/doc/common/README.md index e00cddb9..81964949 100644 --- a/doc/common/README.md +++ b/doc/common/README.md @@ -453,10 +453,10 @@ h. Небольшие изменения (исправление опечатк вызывает сомнение в стабильности, оно должно быть выполнено либо через задачу, либо через запрос на вливание этого изменения, чтобы оно прошло обзор кода (ревью). -i. Задача должна быть переведена в состояние "в работе", когда над ней действительно начата +i. Задача должна быть переведена в состояние «‎‎в работе», когда над ней действительно начата работа. -j. Допускается отправлять в репозиторий только "зелёные файлы", т.е. файлы, по которым +j. Допускается отправлять в репозиторий только «зелёные файлы», т.е. файлы, по которым пройдены все инспекции кода. k. Перед отправкой изменений в репозиторий должны выполняться автоматизированный @@ -470,7 +470,7 @@ l. Добавленные изменения должны быть покрыт a. В файле `CHANGELOG.md` в корне проекта присутствует запись о сделанных изменениях. [Ведите Changelog](https://keepachangelog.com/ru/1.0.0/) -b. Задача должна быть перведена в состояние "ревью". +b. Задача должна быть перведена в состояние «ревью». c. Должно быть выполнено саморевью задачи, т.е. просмотр своих изменений перед тем, как предложить сделать это другим участникам команды. На этом шаге, как правило, @@ -488,7 +488,7 @@ f. После того, как изменения приняты проверя с последующим удалением своей ветки. g. Задача должна быть переведена в состояние следующее состояние задачи (как правило, -это состояние "готово") после её влития в `dev`. +это состояние «готово») после её влития в `dev`. ### 6.3. Ведение журнала изменений (changelog) @@ -579,39 +579,44 @@ h. Все вопросы по ревью обсуждаются наибыстр использовать такой способ коммуникации, при котором ответ затягивается, а соответственно затягивается и ревью. -#### 6.4.4. Процесс обзора задачи, не связанных с системой управления кодом (Github, Gitlab) +#### 6.4.4. Процесс обзора задач, не связанных с системой управления кодом (Github, Gitlab) Такие задачи, как документирование в Notion, Confluence и пр. Мотивация:\ -Сократить количество отвлекающих воздействий на автора изменений до 2 (в позитивном сценарии), +Сократить количество отвлекающих воздействий на автора изменений до 1 (в позитивном сценарии), меньше отвлекая друг друга от работы. -1. Рецензент в процессе обзора кода фиксирует свои замечания и пожелания в одном - месте. \ - Например: тематический канал в Slack, с отключёнными уведомлениями. \ - Формат сообщений: \ - 1: [Номер задачи]: [краткое описание задачи], [ссылка на задачу] \ - 2: [Замечание или пожеление 1] \ - 3: [Замечание или пожеление 2] \ - N+1: [Замечание или пожеление N] +1. Рецензент в процессе обзора кода фиксирует свои замечания и пожелания в комментариях +под задачей в канале `review`. + + ##### Формат + + Сообщение: + > [краткое описание задачи] \ + [ссылка на задачу] + + Комментарии: + > 1 [Замечание или пожеление 1] \ + 2: [Замечание или пожеление 2] \ + N: [Замечание или пожеление N] 2. После того, как рецензент завершил фиксирование замечаний, он уведомляет об этом автора задач. - А также переводит задачу в статус «открыта» / «переоткрыта», чтобы другие рецензенты делали - обзоры только на непросмотренные задачи. +А также переводит задачу в статус «открыта» / «переоткрыта», чтобы другие рецензенты делали +обзоры только на непросмотренные задачи. -3. Автор задачи знакомится со списком замечаний и пожеланий, называет список вопросов и обсуждает - их с рецензентом. В начале работы над исправлениями по замечаниям автор задачи меняет статус задачи - на соответствующий рабочему. +3. Автор задачи знакомится со списком замечаний и пожеланий, формирует список вопросов и обсуждает +их с рецензентом. В начале работы над исправлениями по замечаниям автор задачи меняет статус задачи +на соответствующий рабочему. 4. Автор задачи отмечает сделанные задачи смайлом: ✔ 5. После того, как автор задачи завершил улучшение проделанной работы и отметил все пункты как - завершённые, он также сообщает об этом рецензенту. +завершённые, он также сообщает об этом рецензенту. 6. Рецензент отмечает смайлом ✔ те пункты, в которых он уверен, что они исправлены или не нуждаются в исправлении. Если рецензент с чем-то не согласен, он уведомляет автора задачи о необходимости -её доработать, и процесс повторяется с шага 2. В другом случае задача переводится в состояние «Готово». +её доработать, и процесс повторяется с шага 2. В другом случае задача переводится в состояние «готово». #### 6.4.5. Противоречия и споры в процессе обзора кода @@ -718,7 +723,7 @@ b. В результате необходимо стремиться к отсу #### 6.4.11. Приоритет обзора кода a. Обзор кода не должен задерживать поток задач, соответственно должен быть приоритетным -как для просматривающего изменения, так и для автора изменений. Задача в состоянии "ревью" +как для просматривающего изменения, так и для автора изменений. Задача в состоянии «‎ревью» имеет наивысший приоритет, если по какой-то причине явно не было принято другое решение в виде исключения. From 962f45b92eb6ce05254b46a7faf9657ad79c6b60 Mon Sep 17 00:00:00 2001 From: Daniil Sitdikov Date: Wed, 11 Sep 2019 14:15:13 +0300 Subject: [PATCH 5/7] doc/process: supported english language --- doc/process/README.md | 48 ++++++++++++++++++++++++++++++++++++++----- 1 file changed, 43 insertions(+), 5 deletions(-) diff --git a/doc/process/README.md b/doc/process/README.md index aee79ee9..b90c1031 100644 --- a/doc/process/README.md +++ b/doc/process/README.md @@ -211,10 +211,10 @@ h. Небольшие изменения (исправление опечатк вызывает сомнение в стабильности, оно должно быть выполнено либо через задачу, либо через запрос на вливание этого изменения, чтобы оно прошло обзор кода (ревью). -i. Задача должна быть переведена в состояние "в работе", когда над ней действительно начата +i. Задача должна быть переведена в состояние «‎в работе», когда над ней действительно начата работа. -j. Допускается отправлять в репозиторий только "зелёные файлы", т.е. файлы, по которым +j. Допускается отправлять в репозиторий только «зелёные файлы», т.е. файлы, по которым пройдены все инспекции кода. k. Перед отправкой изменений в репозиторий должны выполняться автоматизированный @@ -228,7 +228,7 @@ l. Добавленные изменения должны быть покрыт a. В файле `CHANGELOG.md` в корне проекта присутствует запись о сделанных изменениях. [Ведите Changelog](https://keepachangelog.com/ru/1.0.0/) -b. Задача должна быть перведена в состояние "ревью". +b. Задача должна быть перведена в состояние «ревью». c. Должно быть выполнено саморевью задачи, т.е. просмотр своих изменений перед тем, как предложить сделать это другим участникам команды. На этом шаге, как правило, @@ -246,7 +246,7 @@ f. После того, как изменения приняты проверя с последующим удалением своей ветки. g. Задача должна быть переведена в состояние следующее состояние задачи (как правило, -это состояние "готово") после её влития в `dev`. +это состояние «‎готово») после её влития в `dev`. ### 2.3. Ведение журнала изменений (changelog) @@ -334,6 +334,44 @@ g. Все вопросы по ревью обсуждаются наибыстр использовать такой способ коммуникации, при котором ответ затягивается, а соответственно затягивается и ревью. +#### 2.4.4. Process of task review not related with code management (Github, Gitlab) + +Task like writing documentation in Notion, Confluence and so on. + +Motivation:\ +To decrease number of distracting requests to author of changes to 1 (in positive scenario), +less distracting from work. + +1. Reviewer in code review process fixes wishes and remarks in comments +in thread of message with task in `review` channel. + + ##### Format + + Message: + > [short task description] \ + [link to task] + + Comments: + > 1 [Remark or wish 1] \ + 2: [Remark or wish 2] \ + N: [Remark or wish N] + +2. After reviewer has finished fixing remarks or wishes, he notifies about that author of task. +Also he changes status of task to «open» / «reopened». It is necessary to another reviewers could +make review only on not viewed tasks. + +3. Author of task meets with list of remarks and wishes, makes list of questions and discuss them +with reviewer. At the start of working on fixing author of task changes status to «in progress». + +4. Author of changes marks resolved task using smile: ✔ + +5. After the author of changes has finished improvements of his work and has marked all +points as done, he also ask reviewer about it. + +6. Reviewer marks in points he sures (they are done and not require any changes) by smile ✔. +If reviewer doesn't agree with something, he notifies author of task for fixing and improvements. +And process will start from step 2. In other case task's status changes to «done». + #### 2.4.4. Противоречия и споры в процессе обзора кода a. Споры и затягивание обзора кода не допускаются. @@ -439,7 +477,7 @@ b. В результате необходимо стремиться к отсу #### 2.4.10. Приоритет обзора кода a. Обзор кода не должен задерживать поток задач, соответственно должен быть приоритетным -как для просматривающего изменения, так и для автора изменений. Задача в состоянии "ревью" +как для просматривающего изменения, так и для автора изменений. Задача в состоянии «‎ревью» имеет наивысший приоритет, если по какой-то причине явно не было принято другое решение в виде исключения. From e718c2a72daab2410a6928daceaa03957a2d830c Mon Sep 17 00:00:00 2001 From: Daniil Sitdikov Date: Wed, 11 Sep 2019 14:16:51 +0300 Subject: [PATCH 6/7] doc/process: increased numbers of versions --- doc/process/README.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/process/README.md b/doc/process/README.md index b90c1031..ee4e1a9d 100644 --- a/doc/process/README.md +++ b/doc/process/README.md @@ -372,7 +372,7 @@ points as done, he also ask reviewer about it. If reviewer doesn't agree with something, he notifies author of task for fixing and improvements. And process will start from step 2. In other case task's status changes to «done». -#### 2.4.4. Противоречия и споры в процессе обзора кода +#### 2.4.5. Противоречия и споры в процессе обзора кода a. Споры и затягивание обзора кода не допускаются. @@ -386,7 +386,7 @@ c. Не допускается повторных обсуждений по по уже принятых правил написания кода. Это не исключает возможности договориться о новых при хорошем уровне коммуникаций и взаимопонимания в команде. (см. пункт выше) -#### 2.4.5. Правила для участников, проверяющих код +#### 2.4.6. Правила для участников, проверяющих код a. Закрыв файл после проверки, вы тем самым полностью принимаете этот вариант так, как будто это написали вы. А так же вы уже несёте ответственность за уровень качества и работоспособности кода. @@ -397,7 +397,7 @@ b. Если что-то правится быстро (5-10 секунд) и о то можно уведомить автора об этих изменениях, чтобы он получил дополнительный опыт и учитывал его в дальнейшей работе. -#### 2.4.6. Состав участников обзора кода +#### 2.4.7. Состав участников обзора кода a. Запрос на влитие изменений должен быть сделан на двух участников команды, которые в состоянии понять смысл изменений и подтвердить их корректностью. Не может считаться @@ -431,7 +431,7 @@ d. [?] В качестве варианта ревью, возможно, сто автором с пояснениями. Это может сократить время, необходимое участникам команды на осмысление кода каждому в отдельности. -#### 2.4.7. Написание комментариев в процессе обзора кода +#### 2.4.8. Написание комментариев в процессе обзора кода a. Критиковать код, а не автора. Помните, раз вы увидели этот код - то он уже тоже ваш. @@ -454,7 +454,7 @@ d. Не писать в побудительном наклонении: `Исправь А на Б` ``` -#### 2.4.8. Отношение к комментариям в обзоре кода +#### 2.4.9. Отношение к комментариям в обзоре кода a. Не оправдываться в комментариях: `А, да, точно, я затупил`, `Я невыспался` и т.д. @@ -467,14 +467,14 @@ c. Запомнить ситуацию, усвоить полученный оп d. Если не согласны - обсудить. Не использовать агрессивно-защитные высказывания и пассивное игноирование. Держать в голове всегда цели обзора кода и команды в целом. -#### 2.4.9. Проверка стиля кода +#### 2.4.10. Проверка стиля кода a. У каждого участника должны быть настроены все автоматизированные средства для автоматической проверки и исправлений кода. b. В результате необходимо стремиться к отсутствию комментариев, касающихся стиля кода. -#### 2.4.10. Приоритет обзора кода +#### 2.4.11. Приоритет обзора кода a. Обзор кода не должен задерживать поток задач, соответственно должен быть приоритетным как для просматривающего изменения, так и для автора изменений. Задача в состоянии «‎ревью» @@ -488,7 +488,7 @@ b. Идеальное время влития изменений равно ну c. Запрос на влитие изменений не должен отправляться на участников команды, которые не могут своевременно выполнить обзор кода. -#### 2.4.11. Учёт при планировании +#### 2.4.12. Учёт при планировании a. Время на ревью и исправления должно учитываться при планировании задач на итерацию. From 183c2b971683d252ccd440e6755af8f585dadec1 Mon Sep 17 00:00:00 2001 From: tohasan Date: Thu, 12 Sep 2019 20:34:36 +0300 Subject: [PATCH 7/7] doc/process: corrected en version of the rule about review non-repo task --- doc/process/README.md | 68 +++++++++++++++++++++++----------------- doc/process/README.ru.md | 38 +++++++++++++--------- 2 files changed, 62 insertions(+), 44 deletions(-) diff --git a/doc/process/README.md b/doc/process/README.md index ee4e1a9d..ce0b8ed0 100644 --- a/doc/process/README.md +++ b/doc/process/README.md @@ -41,8 +41,9 @@ b. Сообщение должно описывать состав измене c. Сообщение должно иметь следующий формат: ``` -<номер задачи> <модуль 1>[/<подмолуль>][, ..., <модуль N>[/<подмодуль>]]: <состав и семантика изменения 1>[, -..., <состав и семантика изменения M>][; ...; <модуль K>[/<подмодуль>]: <состав и семантика изменения>] +<номер задачи> <модуль 1>[/<подмолуль>][, ..., <модуль N>[/<подмодуль>]]: +<состав и семантика изменения 1>[, ..., <состав и семантика изменения M>] +[; ...; <модуль K>[/<подмодуль>]: <состав и семантика изменения>] ``` Таким образом, самый простой вид сообщения: @@ -81,7 +82,8 @@ c. Сообщение должно иметь следующий формат: * `<модуль>` и `<подмодуль>` разделяются слешем `/`; * Группы `<модуль>/<подмодуль>` отделяются друг от друга запятой `,`; * `<модуль>/<подмодуль>` и `<состав и семантика изменения>` разделяются двоеточием `:`; - * Группы `<модуль >: <состав и семантика изменения>` отделяются друг от друга точкой с запятой `;`; + * Группы `<модуль >: <состав и семантика изменения>` отделяются друг + от друга точкой с запятой `;`; * Группы `<состав и семантика изменения>` отделяются друг от друга запятой `,` В квадратных скобках `[]` указаны части сообщения, которые могут отсутствовать. @@ -109,15 +111,20 @@ data-collectors // Отсутствует суть изменений #287 common: review fixes -// Нет номера задачи, в указании модуля присутствует название проекта и указана излишняя вложенность -data-collectors/report/pasrer/historical: optimized parsing of the dom to get 2x speed of parsing +// Нет номера задачи, в указании модуля присутствует название проекта +// и указана излишняя вложенность +data-collectors/report/pasrer/historical: optimized parsing of the dom + to get 2x speed of parsing // Хорошо inni/issues#104 common: added script to update dependencies to cure integrity check error -inni/issues#105 instrument: changed source of data from source1 to source2 to get more stable data stream -inni/issues#106 dev/db: changed type of the field `value` of report to store data from different sources; +inni/issues#105 instrument: changed source of data from source1 to source2 + to get more stable data stream +inni/issues#106 dev/db: changed type of the field `value` of report to store data + from different sources; report: implemented new service to get data from some new source of data. -inni/issues#107 common/services: added new service `report data service` to get report data from database +inni/issues#107 common/services: added new service `report data service` to get + report data from database ``` d. Не должно быть вложенности больше `<модуль>/<подмолуль>`, т.е. максимальная точность @@ -131,8 +138,9 @@ d. Не должно быть вложенности больше `<модуль <модуль 1>/<подмодуль 2>: <состав и семантика изменения> // Вариант 2. Сообщение сгруппировано по модулю -<номер задачи> <модуль 1>: <состав и семантика изменения с указанием, что оно сделано в подмодуле 1>, -<состав и семантика изменения с указанием, что оно сделано в подмодуле 2>; +<номер задачи> <модуль 1>: <состав и семантика изменения с указанием, +что оно сделано в подмодуле 1>, <состав и семантика изменения с указанием, +что оно сделано в подмодуле 2>; ``` e. Не должно быть точки в конце сообщения. @@ -262,8 +270,8 @@ c. Для каждого изменения в начале строки дол ``` // Пример описанного изменения - [`DXAPP-571`](https://smekalka.atlassian.net/browse/DXAPP-571) Added - [redux-logger](https://github.com/LogRocket/redux-logger) as redux middleware to get alternative to react native - debugger that slows down app during debug + [redux-logger](https://github.com/LogRocket/redux-logger) as redux middleware + to get alternative to react native debugger that slows down app during debug ``` d. Для записей в журнале изменений применяются те же правила по ограничению на длину строки, @@ -336,16 +344,16 @@ g. Все вопросы по ревью обсуждаются наибыстр #### 2.4.4. Process of task review not related with code management (Github, Gitlab) -Task like writing documentation in Notion, Confluence and so on. +We are talking about tasks like writing documentation in Notion, Confluence and so on. Motivation:\ -To decrease number of distracting requests to author of changes to 1 (in positive scenario), -less distracting from work. +We want to decrease number of distracting requests to the author of changes to the +single one in positive scenario. We want to distract each other less. -1. Reviewer in code review process fixes wishes and remarks in comments -in thread of message with task in `review` channel. +1. A reviewer puts wishes and remarks in comments of the thread of a message +related to the task in `review` channel during the code review process. - ##### Format + **Format** Message: > [short task description] \ @@ -356,21 +364,23 @@ in thread of message with task in `review` channel. 2: [Remark or wish 2] \ N: [Remark or wish N] -2. After reviewer has finished fixing remarks or wishes, he notifies about that author of task. -Also he changes status of task to «open» / «reopened». It is necessary to another reviewers could -make review only on not viewed tasks. +2. After the reviewer has put all remarks and wishes, he notifies the author +of task. Also he changes status of the task to «open» / «reopen». +It is necessary so that other reviewers could make review only non-reviewed tasks. -3. Author of task meets with list of remarks and wishes, makes list of questions and discuss them -with reviewer. At the start of working on fixing author of task changes status to «in progress». +3. The author of task checks out list of remarks and wishes, prepares a list of +questions and discusses them with the reviewer. Before the author of task starts fixing +he changes status of the task to «in progress». -4. Author of changes marks resolved task using smile: ✔ +4. The author of changes marks resolved item using smile: ✔ -5. After the author of changes has finished improvements of his work and has marked all -points as done, he also ask reviewer about it. +5. When the author of changes has finished and has marked all points as done, +he notifies the reviewer too. -6. Reviewer marks in points he sures (they are done and not require any changes) by smile ✔. -If reviewer doesn't agree with something, he notifies author of task for fixing and improvements. -And process will start from step 2. In other case task's status changes to «done». +6. The reviewer marks items that are fixed correctly using smile ✔. +If the reviewer does not agree with something, he requires fixes and improvements +from the author of task. Repeat steps starting from the step 2 until +all the items are «done». #### 2.4.5. Противоречия и споры в процессе обзора кода diff --git a/doc/process/README.ru.md b/doc/process/README.ru.md index aa9b8926..216803ce 100644 --- a/doc/process/README.ru.md +++ b/doc/process/README.ru.md @@ -41,8 +41,9 @@ b. Сообщение должно описывать состав измене c. Сообщение должно иметь следующий формат: ``` -<номер задачи> <модуль 1>[/<подмолуль>][, ..., <модуль N>[/<подмодуль>]]: <состав и семантика изменения 1>[, -..., <состав и семантика изменения M>][; ...; <модуль K>[/<подмодуль>]: <состав и семантика изменения>] +<номер задачи> <модуль 1>[/<подмолуль>][, ..., <модуль N>[/<подмодуль>]]: +<состав и семантика изменения 1>[, ..., <состав и семантика изменения M>] +[; ...; <модуль K>[/<подмодуль>]: <состав и семантика изменения>] ``` Таким образом, самый простой вид сообщения: @@ -81,7 +82,8 @@ c. Сообщение должно иметь следующий формат: * `<модуль>` и `<подмодуль>` разделяются слешем `/`; * Группы `<модуль>/<подмодуль>` отделяются друг от друга запятой `,`; * `<модуль>/<подмодуль>` и `<состав и семантика изменения>` разделяются двоеточием `:`; - * Группы `<модуль >: <состав и семантика изменения>` отделяются друг от друга точкой с запятой `;`; + * Группы `<модуль >: <состав и семантика изменения>` отделяются друг + от друга точкой с запятой `;`; * Группы `<состав и семантика изменения>` отделяются друг от друга запятой `,` В квадратных скобках `[]` указаны части сообщения, которые могут отсутствовать. @@ -109,15 +111,20 @@ data-collectors // Отсутствует суть изменений #287 common: review fixes -// Нет номера задачи, в указании модуля присутствует название проекта и указана излишняя вложенность -data-collectors/report/pasrer/historical: optimized parsing of the dom to get 2x speed of parsing +// Нет номера задачи, в указании модуля присутствует название проекта +// и указана излишняя вложенность +data-collectors/report/pasrer/historical: optimized parsing of the dom + to get 2x speed of parsing // Хорошо inni/issues#104 common: added script to update dependencies to cure integrity check error -inni/issues#105 instrument: changed source of data from source1 to source2 to get more stable data stream -inni/issues#106 dev/db: changed type of the field `value` of report to store data from different sources; +inni/issues#105 instrument: changed source of data from source1 to source2 + to get more stable data stream +inni/issues#106 dev/db: changed type of the field `value` of report to store data + from different sources; report: implemented new service to get data from some new source of data. -inni/issues#107 common/services: added new service `report data service` to get report data from database +inni/issues#107 common/services: added new service `report data service` to get + report data from database ``` d. Не должно быть вложенности больше `<модуль>/<подмолуль>`, т.е. максимальная точность @@ -131,8 +138,9 @@ d. Не должно быть вложенности больше `<модуль <модуль 1>/<подмодуль 2>: <состав и семантика изменения> // Вариант 2. Сообщение сгруппировано по модулю -<номер задачи> <модуль 1>: <состав и семантика изменения с указанием, что оно сделано в подмодуле 1>, -<состав и семантика изменения с указанием, что оно сделано в подмодуле 2>; +<номер задачи> <модуль 1>: <состав и семантика изменения с указанием, +что оно сделано в подмодуле 1>, <состав и семантика изменения с указанием, +что оно сделано в подмодуле 2>; ``` e. Не должно быть точки в конце сообщения. @@ -211,7 +219,7 @@ h. Небольшие изменения (исправление опечатк вызывает сомнение в стабильности, оно должно быть выполнено либо через задачу, либо через запрос на вливание этого изменения, чтобы оно прошло обзор кода (ревью). -i. Задача должна быть переведена в состояние «в работе», когда над ней действительно начата +i. Задача должна быть переведена в состояние «‎в работе», когда над ней действительно начата работа. j. Допускается отправлять в репозиторий только «зелёные файлы», т.е. файлы, по которым @@ -246,7 +254,7 @@ f. После того, как изменения приняты проверя с последующим удалением своей ветки. g. Задача должна быть переведена в состояние следующее состояние задачи (как правило, -это состояние «готово») после её влития в `dev`. +это состояние «‎готово») после её влития в `dev`. ### 2.3. Ведение журнала изменений (changelog) @@ -262,8 +270,8 @@ c. Для каждого изменения в начале строки дол ``` // Пример описанного изменения - [`DXAPP-571`](https://smekalka.atlassian.net/browse/DXAPP-571) Added - [redux-logger](https://github.com/LogRocket/redux-logger) as redux middleware to get alternative to react native - debugger that slows down app during debug + [redux-logger](https://github.com/LogRocket/redux-logger) as redux middleware + to get alternative to react native debugger that slows down app during debug ``` d. Для записей в журнале изменений применяются те же правила по ограничению на длину строки, @@ -345,7 +353,7 @@ g. Все вопросы по ревью обсуждаются наибыстр 1. Рецензент в процессе обзора кода фиксирует свои замечания и пожелания в комментариях под задачей в канале `review`. - ##### Формат + **Формат** Сообщение: > [краткое описание задачи] \