Size: a a a

2021 April 05

RU

Rostislav U in atinfo chat
ну и разрабы тут вообще нос не суют)
источник

ЕГ

Евгений Горбоконенко... in atinfo chat
Вообще звучит как валидная идея. Код-ревью у разработчиков работает и считается прекрасной практикой. Почему это не должно работать у автотестеров?)
источник

V

Viktor in atinfo chat
Да тут от мнения мало что зависит, если надо ревьювить то блокируйте, если не обязательно, оставьте
источник

RU

Rostislav U in atinfo chat
если коротко ваше мнение, то это: ревью оставить, это повысит качество кода тестов
источник

RU

Rostislav U in atinfo chat
иногда это выглядит как "ходит тестер по лидам и просит апрув" и только кто захотел пошел посмотрел
источник

ЕГ

Евгений Горбоконенко... in atinfo chat
Это один момент. Второй момент - развитие. Это достаточно хороший источник другого мнения, другого взгляда на проблему. Так что дополню)
Ревью оставить, это повысит качество кода тестов и скилл автотестеров как автотестеров. Как написавшего, так и ревьюера
источник

ЕГ

Евгений Горбоконенко... in atinfo chat
А это уже проблема построенных процессов. Если у вас такое происходит часто - эскалируйте. Говорите, что мержи ревьюятся очень долго, потому что, например, у других автотестеров есть свои задачи и есть свои сроки, и нужно выделять время в спринте на это самое ревью
источник

V

Viktor in atinfo chat
Я так понял, ревью носит формальный характер и сводится к нажатию на кнопку,  можно дать права на мерж, а если ревью нужно, то его всегда можно попросить
источник

ИС

Игорь Середа... in atinfo chat
Никогда не знаешь, где они могут сунуть нос. Могут даже и здесь вас найти.
источник

RU

Rostislav U in atinfo chat
вот я и встал в замешательство) чувствую, есть золотая середина, но можно ли усидеть на двух стульях
источник

RU

Rostislav U in atinfo chat
😅
источник

ЕГ

Евгений Горбоконенко... in atinfo chat
Если так, то я бы сказал, что стоит менять подход и вводить нормальное ревью в практику, а не просто кнопку жмакнуть. Но если по каким-то причинам не получится или не получается - тогда оно нафиг не надо, это лишний гемор
источник

ИС

Игорь Середа... in atinfo chat
Выглядит, будто проблема не в самом CR, а в том, как оно у вас организовано. Если нет культуры регулярного просмотра чужих тасок, и каждый делает только то, что ему кажется более важным, то надо поднимать вопрос выше.
источник

ЕГ

Евгений Горбоконенко... in atinfo chat
источник

ИС

Игорь Середа... in atinfo chat
А сама идея здравая. Это не должно выглядеть как "обход коллег, чтобы собрать аппрувы". Это должна быть регулярная процедура, в которой они внимательно (и с чувством собственной ответственности) отсматривают ваши правки и по делу их окмментируют.
источник

ИС

Игорь Середа... in atinfo chat
Можете завести CR-очный чатик и кидать туда (или настроить бота, чтобы кидал) каждый новый MR, который следует проревьюить. Можно заодно пинговать с MR'ами, которые открыты уже сутки (тут подставить нужный период), но так и не получившие аппрув или комментарий.
источник

RU

Rostislav U in atinfo chat
четкая идея)
источник
2021 April 06

ИС

Игорь Середа... in atinfo chat
Но если культура слабая, то через пару-тройку недель на этот чатик начнёт распространяться эффект баннерной слепоты. Поэтому, стоит, конечно, навернуть какой-нибудь фильтр в вашем GitHub/GiLab, через который сразу открываются все MR'ы, требующие внимания. И привить практику, чтобы каждый между своими задачами поглядывал в этот фильтр.
источник

ЕГ

Евгений Горбоконенко... in atinfo chat
Собственно, здравая мысль. Вопрос культуры. Если всем будет пофигу и никто (или, хотя бы, большинство) не захочет поддерживать идею, никакие тех решения не помогут, а будут либо игнориться, либо раздражать и игнориться с удвоенной силой)
источник

RU

Rostislav U in atinfo chat
Ещё ж нужно как-то контролировать чтобы размер МР-а был вменяемым. Вряд ли кто захочет смотреть 100500 файлов
источник