Skip to content

proposal/process-review-no-code-managment-tasks common: added info #72

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Sep 12, 2019
Merged

proposal/process-review-no-code-managment-tasks common: added info #72

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
d551e34
proposal/process-review-no-code-managment-tasks common: added info
Danilqa Sep 5, 2019
64f5da8
proposal/process-review-no-code-managment-tasks common: updated info
Danilqa Sep 5, 2019
5834264
proposal/review-process-node-code-tasks common: fixed process descrip…
Danilqa Sep 8, 2019
1fe1a34
proposal/review-process-node-code-tasks common: removed double quotes…
Danilqa Sep 9, 2019
34d70c4
Merge branch 'dev' into proposal/review-process-no-code-tasks
Danilqa Sep 11, 2019
962f45b
doc/process: supported english language
Danilqa Sep 11, 2019
e718c2a
doc/process: increased numbers of versions
Danilqa Sep 11, 2019
183c2b9
doc/process: corrected en version of the rule about review non-repo task
tohasan Sep 12, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
98 changes: 73 additions & 25 deletions doc/process/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,8 +41,9 @@ b. Сообщение должно описывать состав измене
c. Сообщение должно иметь следующий формат:

```
<номер задачи> <модуль 1>[/<подмолуль>][, ..., <модуль N>[/<подмодуль>]]: <состав и семантика изменения 1>[,
..., <состав и семантика изменения M>][; ...; <модуль K>[/<подмодуль>]: <состав и семантика изменения>]
<номер задачи> <модуль 1>[/<подмолуль>][, ..., <модуль N>[/<подмодуль>]]:
<состав и семантика изменения 1>[, ..., <состав и семантика изменения M>]
[; ...; <модуль K>[/<подмодуль>]: <состав и семантика изменения>]
```

Таким образом, самый простой вид сообщения:
Expand Down Expand Up @@ -81,7 +82,8 @@ c. Сообщение должно иметь следующий формат:
* `<модуль>` и `<подмодуль>` разделяются слешем `/`;
* Группы `<модуль>/<подмодуль>` отделяются друг от друга запятой `,`;
* `<модуль>/<подмодуль>` и `<состав и семантика изменения>` разделяются двоеточием `:`;
* Группы `<модуль >: <состав и семантика изменения>` отделяются друг от друга точкой с запятой `;`;
* Группы `<модуль >: <состав и семантика изменения>` отделяются друг
от друга точкой с запятой `;`;
* Группы `<состав и семантика изменения>` отделяются друг от друга запятой `,`

В квадратных скобках `[]` указаны части сообщения, которые могут отсутствовать.
Expand Down Expand Up @@ -109,15 +111,20 @@ data-collectors <root of project>

// Отсутствует суть изменений
#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. Не должно быть вложенности больше `<модуль>/<подмолуль>`, т.е. максимальная точность
Expand All @@ -131,8 +138,9 @@ d. Не должно быть вложенности больше `<модуль
<модуль 1>/<подмодуль 2>: <состав и семантика изменения>

// Вариант 2. Сообщение сгруппировано по модулю
<номер задачи> <модуль 1>: <состав и семантика изменения с указанием, что оно сделано в подмодуле 1>,
<состав и семантика изменения с указанием, что оно сделано в подмодуле 2>;
<номер задачи> <модуль 1>: <состав и семантика изменения с указанием,
что оно сделано в подмодуле 1>, <состав и семантика изменения с указанием,
что оно сделано в подмодуле 2>;
```

e. Не должно быть точки в конце сообщения.
Expand Down Expand Up @@ -211,10 +219,10 @@ h. Небольшие изменения (исправление опечатк
вызывает сомнение в стабильности, оно должно быть выполнено либо через задачу, либо через
запрос на вливание этого изменения, чтобы оно прошло обзор кода (ревью).

i. Задача должна быть переведена в состояние "в работе", когда над ней действительно начата
i. Задача должна быть переведена в состояние «‎в работе», когда над ней действительно начата
работа.

j. Допускается отправлять в репозиторий только "зелёные файлы", т.е. файлы, по которым
j. Допускается отправлять в репозиторий только «зелёные файлы», т.е. файлы, по которым
пройдены все инспекции кода.

k. Перед отправкой изменений в репозиторий должны выполняться автоматизированный
Expand All @@ -228,7 +236,7 @@ l. Добавленные изменения должны быть покрыт
a. В файле `CHANGELOG.md` в корне проекта присутствует запись о сделанных изменениях.
[Ведите Changelog](https://keepachangelog.com/ru/1.0.0/)

b. Задача должна быть перведена в состояние "ревью".
b. Задача должна быть перведена в состояние «ревью».

c. Должно быть выполнено саморевью задачи, т.е. просмотр своих изменений перед тем,
как предложить сделать это другим участникам команды. На этом шаге, как правило,
Expand All @@ -246,7 +254,7 @@ f. После того, как изменения приняты проверя
с последующим удалением своей ветки.

g. Задача должна быть переведена в состояние следующее состояние задачи (как правило,
это состояние "готово") после её влития в `dev`.
это состояние «‎готово») после её влития в `dev`.

### 2.3. Ведение журнала изменений (changelog)

Expand All @@ -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. Для записей в журнале изменений применяются те же правила по ограничению на длину строки,
Expand Down Expand Up @@ -334,7 +342,47 @@ g. Все вопросы по ревью обсуждаются наибыстр
использовать такой способ коммуникации, при котором ответ затягивается, а соответственно
затягивается и ревью.

#### 2.4.4. Противоречия и споры в процессе обзора кода
#### 2.4.4. Process of task review not related with code management (Github, Gitlab)

We are talking about tasks like writing documentation in Notion, Confluence and so on.

Motivation:\
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. 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**

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 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. 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. The author of changes marks resolved item using smile: ✔

5. When the author of changes has finished and has marked all points as done,
he notifies the reviewer too.

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. Противоречия и споры в процессе обзора кода

a. Споры и затягивание обзора кода не допускаются.

Expand All @@ -348,7 +396,7 @@ c. Не допускается повторных обсуждений по по
уже принятых правил написания кода. Это не исключает возможности договориться о новых
при хорошем уровне коммуникаций и взаимопонимания в команде. (см. пункт выше)

#### 2.4.5. Правила для участников, проверяющих код
#### 2.4.6. Правила для участников, проверяющих код

a. Закрыв файл после проверки, вы тем самым полностью принимаете этот вариант так, как будто это
написали вы. А так же вы уже несёте ответственность за уровень качества и работоспособности кода.
Expand All @@ -359,7 +407,7 @@ b. Если что-то правится быстро (5-10 секунд) и о
то можно уведомить автора об этих изменениях, чтобы он получил дополнительный опыт и учитывал
его в дальнейшей работе.

#### 2.4.6. Состав участников обзора кода
#### 2.4.7. Состав участников обзора кода

a. Запрос на влитие изменений должен быть сделан на двух участников команды, которые
в состоянии понять смысл изменений и подтвердить их корректностью. Не может считаться
Expand Down Expand Up @@ -393,7 +441,7 @@ d. [?] В качестве варианта ревью, возможно, сто
автором с пояснениями. Это может сократить время, необходимое участникам команды на
осмысление кода каждому в отдельности.

#### 2.4.7. Написание комментариев в процессе обзора кода
#### 2.4.8. Написание комментариев в процессе обзора кода

a. Критиковать код, а не автора. Помните, раз вы увидели этот код - то он уже тоже ваш.

Expand All @@ -416,7 +464,7 @@ d. Не писать в побудительном наклонении:
`Исправь А на Б`
```

#### 2.4.8. Отношение к комментариям в обзоре кода
#### 2.4.9. Отношение к комментариям в обзоре кода

a. Не оправдываться в комментариях: `А, да, точно, я затупил`, `Я невыспался` и т.д.

Expand All @@ -429,17 +477,17 @@ c. Запомнить ситуацию, усвоить полученный оп
d. Если не согласны - обсудить. Не использовать агрессивно-защитные высказывания и
пассивное игноирование. Держать в голове всегда цели обзора кода и команды в целом.

#### 2.4.9. Проверка стиля кода
#### 2.4.10. Проверка стиля кода

a. У каждого участника должны быть настроены все автоматизированные средства для
автоматической проверки и исправлений кода.

b. В результате необходимо стремиться к отсутствию комментариев, касающихся стиля кода.

#### 2.4.10. Приоритет обзора кода
#### 2.4.11. Приоритет обзора кода

a. Обзор кода не должен задерживать поток задач, соответственно должен быть приоритетным
как для просматривающего изменения, так и для автора изменений. Задача в состоянии "ревью"
как для просматривающего изменения, так и для автора изменений. Задача в состоянии «‎ревью»
имеет наивысший приоритет, если по какой-то причине явно не было принято другое решение
в виде исключения.

Expand All @@ -450,7 +498,7 @@ b. Идеальное время влития изменений равно ну
c. Запрос на влитие изменений не должен отправляться на участников команды, которые
не могут своевременно выполнить обзор кода.

#### 2.4.11. Учёт при планировании
#### 2.4.12. Учёт при планировании

a. Время на ревью и исправления должно учитываться при планировании задач на итерацию.

Expand Down
Loading