요약

  • 2001년 Bugzilla 2.14는 투표 설정 변경이나 제품 간 이동 때 표를 지우던 처리를 바꾸고 기존 선택을 더 많이 보존했다.
  • 관리자는 투표 한도와 자동 상태 변경 조건을 정했다. 실제 수정에는 담당자, 우선순위, 의존 관계와 목표 버전이 필요했다.

문제 보고서를 다른 서랍으로 옮겼을 뿐인데, 고쳐 달라고 손든 사람들이 장부에서 사라진다. 초기 Bugzilla에서 일어날 수 있었던 일이다. 버그를 다른 제품으로 옮기면 그 버그에 모인 표가 전부 지워졌다. 오류는 여전히 사용자를 괴롭혔지만, 사용자의 지지는 이삿짐에서 빠졌다.

2000년 2월 Matthew Tuck은 28882번 보고서를 올렸다. 투표 정책이 바뀐 뒤 자신이 지지하던 문제가 상위 열 개 목록에서 밀려났고, 여러 사람의 표가 통째로 없어졌다는 내용이었다. 제안은 소박했다. 허용량을 줄였다면 새 상한까지만 줄여 달라는 것이다. 한도를 낮추라는 주문을 시스템은 제법 과감하게 수행하고 있었다.

이 요청 역시 기다리고 되돌아오는 과정을 겪었다. 2001년 2월 유효하지 않다는 이유로 닫혔다가 같은 날 다시 열렸고, 8월에 수정된 것으로 기록됐다. 논의 도중에는 더 까다로운 질문이 나왔다. 한 버그에 줄 수 있는 표를 줄이는 일은 쉽다. 한 사람이 제품 전체에 쓸 수 있는 표를 줄인다면, 그가 선택한 여러 버그 중 어디서 표를 빼야 할까. 계산하기 전에 선택의 주인을 정해야 했다.

숫자가 잠시 넘쳐도 선택은 남겨 두기

2.14 버전의 출시 기록은 2001년에 채택한 방식을 설명한다. 한 사람이 특정 버그에 준 표가 상한을 넘으면 상한까지 줄이고 당사자에게 알린다. 반면 제품 안에서 쓴 총표수가 허용량을 넘으면 그 표를 보존한다. 이후 투표를 수정할 때는 초과 상태를 해결해야 한다. 이 버전은 사용자가 정리하도록 강제하는 추가 조치를 두지 않았다.

장부가 잠시 덜 말끔해지는 대신 이미 표현된 선호가 남았다. 다른 제품으로 옮길 때 모든 표를 자동으로 지우는 처리도 사라졌다. 분류를 정리하는 사람이 참여자의 기억까지 정리해 버리는 일을 줄인 셈이다. 보존을 택하자 나중에 맞춰야 할 숫자가 생겼다. 그 정도 번거로움은 투표를 받은 쪽이 맡을 만했다.

2002년 2.16 버전에 포함된 관리자 설명서는 투표의 조절 장치를 보여 준다. 제품마다 한 사람의 총허용량, 한 버그에 줄 수 있는 최대치, UNCONFIRMED에서 NEW로 자동 전환하는 기준 표수를 정할 수 있었다. 개인 허용량을 0으로 두면 투표가 꺼졌다. 전환 기준을 0으로 두면 자동 전환이 꺼졌다. 사용자가 누르는 버튼 뒤에는 관리자가 정하는 조건들이 있었다.

표가 모인 다음에는 사람이 필요했다

같은 버전의 사용자 설명서에는 수정 담당자, 우선순위, 심각도, 목표 버전과 의존 관계도 나열돼 있다. 담당자는 우선순위로 자신의 작업 순서를 정했다. 어떤 수정은 다른 문제가 먼저 해결돼야 진행할 수 있었다. 투표는 요구를 더 잘 보이게 만들었고, 개발 시간은 별도로 배분해야 했다.

웹의 보고서는 불만이 찾아갈 고정 주소를 만들었다. 같은 문제를 겪는 사람이 찾아와 표를 더하고 진행 상황을 볼 수 있었다. 그 참여가 쓸모를 유지하려면 분류를 옮길 때 선택도 함께 옮기고, 줄어든 숫자는 설명하고, 다음 작업을 맡을 사람을 정해야 했다. 버그를 수리하는 사람들에게는 투표함의 기억을 수리하는 일도 붙어 있었다.