а ничего страшного, что я сказал - что все зависит от процессов ?
1) если процесс таков, что сразу после коммита идет деплой на стенд.. - иду проверяю
2) если деплой не сразу после коммита, а в опред время - иду смотреть коммит и жду деплоя для фикса или сам запускаю деплой.
3) а что если есть KPI(не дай бог конечно) ?
в общем.. заводить баг ради того чтобы завести, такое себе удовольствие..
но если разраб говорит, что он пофиксил..
1) если у меня норм отношения с ним и он на протяжении нашей совместной работы проявил себя как ответственный чел, то я могу не заводить.
2) если разраб бурогоз и за ним постоянно лезут баги, то могу не париться и завести задачу в джире.
3) а еще я могу быть сильно занят - тем самым заведенный баг поможет мне не забыть об ошибке.
короче вариантов много..
но вы дальше заводите задачки ради задачек
я как-то спросил у людей из очень большой и известной компании на счет процессов и в частности упомянул про создание тикетов на каждую ошибку. Мне ответили, что у них просто принято открывать тикет и не ради тикета, а ради прозрачности. Чтобы не было такого, что человек работает, но подтвердить над чем работает не может. Это вот он сегодня помнит и знает детали, а через неделю не факт и через месяц подавно. И по нормальному, на каждую ошибку должны быть сделаны действия предотвращающие ее появление снова. К тому же очень велика вероятность ситуации, когда попросил что-то исправить, тикет не завел. Человек начинает работать, прилетает P1 и надо срочно работать над ним из-за приоритета, а потом и ты и он случайно забываете об этом. Кароч, в их ответе я понял, что лучше открыть тикет, чем не открыть его) (по крайней мере это более масштабируемое решение)