A
Это не будет ошибкой?
Size: a a a
2021 January 30
E
Это не будет ошибкой?
Зачем спрашивал тогда?)
VY
Это не будет ошибкой?
Почему? Нет не будет. Если проблема одинаковая, реашается одинаково, зачем плодить однотипные баги
A
Понял, спасибо большое
S
здесь нет однозначно верного ответа. Обычно такие вещи решаются с разработчиками.
Общая практика заводить много багов в 1 - плохо. Но ситуации разные бывают
Общая практика заводить много багов в 1 - плохо. Но ситуации разные бывают
A
Ну я вообще согласен, что заводить отдельный баг на каждую непереведенную статью на сайте немного глупо, а с разрабами связи не имею
VY
Тогда делайте баг со списком.
АН
Всем привет) какие вопросы тут можно обсуждать?
SB
Всем привет) какие вопросы тут можно обсуждать?
Про тестирование и его автоматизацию. Если судить по описанию
АН
Про тестирование и его автоматизацию. Если судить по описанию
Спасибо)
АН
Народ, может кто нашёл хороший аналог browsermob proxy для java? Они перестали коммиты делать в 17 году( писали мне как-то browser up proxy, так в итоге на запрос документации у разработчиков уже недели две жду ответ ( может кто ещё что использовал хорошее в этом плане?
X
Ну я вообще согласен, что заводить отдельный баг на каждую непереведенную статью на сайте немного глупо, а с разрабами связи не имею
ну а если ситуация будет такая - что у разработчика было немного времени до конца рабочего дня и он взялся за эту багу со списком непереведенных страниц, но не успел исправить все страницы, как потом указывать что готово, что нет по исправлениям? комментом в том же баге?
X
двоякая ситуация - когда нет избычности в дублировании похожего - теряется наглядность
X
и наоборот плодить одинаковое, но за то четко видно что исправлено что нет
AG
ну а если ситуация будет такая - что у разработчика было немного времени до конца рабочего дня и он взялся за эту багу со списком непереведенных страниц, но не успел исправить все страницы, как потом указывать что готово, что нет по исправлениям? комментом в том же баге?
Кажется, что нет примерно никакой проблемы в том, что бы в дескрипшене тикета отметить что сделано, а что нет.
AG
Если уж комменты по каким-то причинам не устраивают.
X
Кажется, что нет примерно никакой проблемы в том, что бы в дескрипшене тикета отметить что сделано, а что нет.
Спасибо, буду знать) Прокомментировала так были сомнения на этот счёт
AG
Ну, всё упирается, как обычно, в договорённости внутри команды и здравый смысл.
Если вам нужно сделать н одновременных и однотипных исправлений в н мест - лично я не вижу никаких проблем в заведении на это одного тикета.
Если заранее известно, что это будут делать по кускам, разные люди в разное время - логичнее разнести на разные задачи (в прочем, ничего не мешает разработчику это сделать самому).
Если вам нужно сделать н одновременных и однотипных исправлений в н мест - лично я не вижу никаких проблем в заведении на это одного тикета.
Если заранее известно, что это будут делать по кускам, разные люди в разное время - логичнее разнести на разные задачи (в прочем, ничего не мешает разработчику это сделать самому).
N
ну а если ситуация будет такая - что у разработчика было немного времени до конца рабочего дня и он взялся за эту багу со списком непереведенных страниц, но не успел исправить все страницы, как потом указывать что готово, что нет по исправлениям? комментом в том же баге?
Закрыть таску с коментом, что было сделано, что нет. И повесить новую багу с оставшимися страницами. А вообще многое зависит от процесса.
X
Nikita
Закрыть таску с коментом, что было сделано, что нет. И повесить новую багу с оставшимися страницами. А вообще многое зависит от процесса.
Да, тоже как вариант