Я догадываюсь кто будет первым в долгосрочной перспективе, но не скажу :-)
А если серьезно, я не очень понимаю как принципы 4-6 применить к разработке коробочного ПО (речь идет именно о нем, насколько я понял). Это нужно уж _очень_ крепко довести клиента, чтоб он так эмоционально реагировал на глюки, а не просто молча свалил. Может, просто не стоит доводить ?
Меня самого один раз почти довели до подобного состояния: контора многократно рассылала спам с предложением отписать разработчикам почтой, сообщить впечатления о продукте на их форуме и т.п. Отписал и сообщил раз 5, за месяц ни одного ответа (спам-фильтр проверял). У других пользователей на форуме была та же история, т.е. саппорт просто забил.
По поводу "каждому изменению в репозитарии соответствует свой тикет" - у нас вполне выдерживается такая методика.
1) Теоретически, при коммите может срабатывать hook, которые проверят наличие указанной баги в багтрекере и даже то, что handler-ом этой баги является тот самый разработчик, который commit-ит код. Сам такое писал, но реально использовать не пришлось - вполне помогает фраза "просто надо так делать".
2) Если коммит относится к нескольким связанным багам, то указываем их все. Соответственно в багтрекере для каждой из багов будет выведен список измененных файлов и список связаных багов.
Вообще связь commit-ов с багами - штука очень полезная, т.к. позволяет:
1) По строчке исходника получить номер ревизии (svn annotate), а по номеру ревизии - к какой баге это относится. Очень помогает при ответе на вопрос "кто и зачем это сделал".
2) Многие исправления разработчиков можно заворачивать назад вообще не тестируя, т.к. по diff-у видно что поменяли не все файлы, забыли перенести правки из trunk в branch и т.п.
3) Если в багтрекере можно учитывать время, то сразу понятно как соотносится время работы над задачей с объемом изменений.
А вот рассылка всем содержимого commit-ов - это в самом деле спам, не могу представить зачем оно может быть нужно в таком виде.
А если серьезно, я не очень понимаю как принципы 4-6 применить к разработке коробочного ПО (речь идет именно о нем, насколько я понял). Это нужно уж _очень_ крепко довести клиента, чтоб он так эмоционально реагировал на глюки, а не просто молча свалил. Может, просто не стоит доводить ?
Меня самого один раз почти довели до подобного состояния: контора многократно рассылала спам с предложением отписать разработчикам почтой, сообщить впечатления о продукте на их форуме и т.п. Отписал и сообщил раз 5, за месяц ни одного ответа (спам-фильтр проверял). У других пользователей на форуме была та же история, т.е. саппорт просто забил.
1) Теоретически, при коммите может срабатывать hook, которые проверят наличие указанной баги в багтрекере и даже то, что handler-ом этой баги является тот самый разработчик, который commit-ит код. Сам такое писал, но реально использовать не пришлось - вполне помогает фраза "просто надо так делать".
2) Если коммит относится к нескольким связанным багам, то указываем их все. Соответственно в багтрекере для каждой из багов будет выведен список измененных файлов и список связаных багов.
Вообще связь commit-ов с багами - штука очень полезная, т.к. позволяет:
1) По строчке исходника получить номер ревизии (svn annotate), а по номеру ревизии - к какой баге это относится. Очень помогает при ответе на вопрос "кто и зачем это сделал".
2) Многие исправления разработчиков можно заворачивать назад вообще не тестируя, т.к. по diff-у видно что поменяли не все файлы, забыли перенести правки из trunk в branch и т.п.
3) Если в багтрекере можно учитывать время, то сразу понятно как соотносится время работы над задачей с объемом изменений.
А вот рассылка всем содержимого commit-ов - это в самом деле спам, не могу представить зачем оно может быть нужно в таком виде.