Кратко

  • В версии 2.14 Bugzilla изменила обработку голосов, которые прежде удалялись при смене настроек голосования или переносе бага между продуктами.
  • Администраторы задавали квоты и пороги смены статуса; исполнители распоряжались очередностью работы, зависимостями и целевыми версиями.

У программной ошибки мог смениться адрес, а у её сторонников — внезапно исчезнуть право на существование в счётчике. Ранняя Bugzilla при переносе записи в другой продукт удаляла её голоса. Ошибка оставалась на месте в смысле последствий для пользователя. Исчезала просьба поскорее её исправить. Канцелярия работала решительнее ремонтной бригады.

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

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

Сохранить лишнее, чтобы не потерять нужное

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

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

Сам запрос прошёл занятный путь. В феврале 2001 года его закрыли как недействительный, в тот же день открыли снова, а в августе отметили исправленным. Устройство для сбора пожеланий успело испытать на себе ожидание исполнения собственного пожелания.

Руководство администратора из выпуска 2.16 2002 года показывает, кто управлял счётчиком. Для каждого продукта задавались квота на человека, максимум на один баг и порог автоматического перехода из UNCONFIRMED в NEW. Нулевая личная квота выключала голосование. Нулевой порог выключал автоматический переход. Публичное участие получало свои возможности из формы настроек, доступной администрации.

У ремонта было собственное расписание

В руководстве пользователя того же выпуска перечислены исполнитель, приоритет, серьёзность, целевая версия и зависимости. Исполнитель использовал приоритет для порядка своих задач. Один баг мог ждать исправления другого. Много голосов помогало увидеть спрос, а часы разработчика по-прежнему приходилось распределять.

Веб дал жалобе постоянную страницу: её могли найти, поддержать и проследить за изменениями. Сохранить пользу этой страницы помогала будничная дисциплина — переносить данные вместе с записью, объяснять сокращения и показывать ответственного за дальнейшую работу. У ранней Bugzilla было достаточно настоящих ошибок. Терять по дороге людей, которые хотели их исправления, было лишним удовольствием.