В любом проекте, который активно использует трекер ошибок, всегда существует опасность превращения трекера в самостоятельный дискуссионный форум, несмотря на то, что списки рассылки действительно лучше. Обычно это начинается вполне невинно: кто-нибудь комментирует проблему, скажем, возможным решением или частичным патчем. Кто-нибудь другой видит это, понимает, что с решением есть проблема, и присоединяет другое примечание, указывающее на проблему. Первый отвечает, снова комментируя проблему... и так далее.

Проблема заключается, во-первых, в том, что трекер ошибок - очень нескладное место для дискуссий, а во-вторых, в том, что это может пройти мимо внимания других людей - в конце концов, они ожидают, что дискуссии по разработке происходят в соответствующем списке рассылки, и там они их и ищут. Они могут быть вообще не подписаны на список, связанный с изменением проблем, а если и подписаны, могут не следить за ним слишком внимательно.

Но когда точно процесс дал сбой? Случилось ли это тогда, когда первый участник присоединил своё решение к проблеме - должен ли он был вместо этого послать сообщение в список рассылки? Или это случилось, когда второй участник ответил в трекере, а не в списке?

Не существует единственно правильного ответа, но существует общий принцип: если вы просто добавляете данные к проблеме, делайте это в трекере, но если вы начинаете разговор, то делайте это в списке рассылки. Иногда непросто отличить одно от другого, просто доверьтесь вашему чутью. Например, когда присоединяете патч, содержащий противоречивое решение, ожидайте, что у людей появятся вопросы по этому поводу. Так что даже если вы в обычной ситуации присоединили бы патч к проблеме (предположим, что вы не хотите или не имеете права делать прямые commit'ы), в данном случае вы возможно захотите опубликовать сообщение в список рассылки. В любом случае, настанет момент, когда одна из сторон может сказать, что надо перейти от простого добавления данных к настоящему разговору - в примере, которым начинался данный раздел, это мог быть второй респондент, который, найдя проблему в патче, мог предвидеть, что готов начаться реальный разговор, и поэтому его надо вести соответствующим способом.

Пользуясь математической аналогией, если информация выглядит так, что она будет быстро сходиться, помещайте её прямо в трекер ошибок; если будет расходиться, то список рассылки или IRC-канал будут более подходящим местом.

Это не означает, что в трекере никогда не должно быть никаких переговоров. Запрос у первого респондента подробностей о том как воспроизвести проблему, например, представляется быстро сходящимся процессом. Ответ вряд ли породит новые проблемы; он просто должен конкретизировать информацию, которая уже выложена. Нет необходимости обременять список рассылки этим процессом, решите это серией комментариев в трекере. Аналогично, если вы точно уверены, что ошибка зарегистрирована неверно (например, не является ошибкой), то можете сказать об этом прямо в трекере. Можно даже указывать на небольшие проблемы в предложенном решении возможно, если они не блокируют решение в целом.

С другой стороны, если вы поднимаете философские проблемы, связанные с областью распространения ошибки или желаемым поведением, можете быть уверены, что другие разработчики захотят присоединиться. Дискуссия наверное будет расходиться до того, как сойтись, так что делайте это в списке рассылки.

Всегда указывайте ссылку на трекере, если вы решили написать в список рассылки. Для кого-то, кто следит за проблемой, важно не потерять дискуссию, даже если сам трекер не место для неё. Для человека, который открывает тему, это может казаться утомительным, но ПО с открытым кодом - это в своей основе культура ответственного письма: гораздо более важно сделать вещь понятной для десятков сотен людей, которые могут прочитать об ошибке, чем для трёх или пяти человек, которые пишут в связи ней.

Хорошо взять важные выводы или резюме из дискуссии в списке рассылки и вставить их в трекер, если это будет удобно для читающих. Общая идиома такова: откройте дискуссию в списке, поместите в трекер ссылку на открытую тему, а по окончании обсуждения вставьте полученное резюме в трекер (вместе со ссылкой на сообщение, содержащее это резюме), чтобы любой, просматривающий проблему мог легко понять, к какому выводу пришли, не кликая больше никуда. Отметим, что обычной проблемы дублирования данных здесь нет, потому что и архивы, и комментарии в трекере обычно всё равно статические, неизменяемые данные.