摘要

  • Bugzilla 2.14 改变了旧有处理方式：修改投票设置、把缺陷移到另一个产品时，系统开始尽量保留已有票数。
  • 管理员决定票额和自动确认门槛；修复负责人通过优先级、依赖关系和目标版本安排工作。

给软件问题投票，原本是件很朴素的事：这个毛病烦了我很久，请先看一眼。早期 Bugzilla 却给这份心愿附赠了一项意外风险。管理员整理分类，把问题移到另一个产品下面，票可能就没了。漏洞安然搬家，支持者被落在了原地。

2000 年 2 月，Matthew Tuck 提交了第 28882 号报告。他抱怨，一次投票规则变动让自己支持的问题从前十名掉了下去，一些人的票被全部移除。他要的修正相当克制：新规则允许投得更少，那就减到新上限，何必一把归零。限量供应被执行成了清仓处理。

这份关于缺陷系统的缺陷报告，也体验了一遍系统的脾气。2001 年 2 月，它被关闭，理由是无效；同一天又被重新打开。到 8 月，记录才标为修复。中间的讨论提出了真正棘手的一步：降低一个人对单个问题的票额，系统可以直接截短；降低他在整个产品里的总票额，究竟该牺牲他投给哪一个问题的票？加减法到了这里，必须等人制定规则。

宁可账面暂时超额，也给选择留个位置

2.14 版发行说明写下了处理办法。每人对单个问题的票数超过新上限，就减到上限，并通知本人。如果调整后，一个人在某产品下的总票数超额，系统先保留这些票；此后他只能通过解决超额问题来更新投票。这个版本没有另外采取措施，强迫用户立刻完成调整。

因此，账本可以暂时不整齐，用户已经表达的偏好先留下。把问题移到另一个产品，也不再自动清掉全部票数。一次看似普通的记录整理，终于学会连同记录背后的意见一起搬运。

2002 年随 2.16 版发布的管理手册展示了这套投票的实际开关。每个产品可以分别设置每人总票额、每人给单个问题的最高票数，以及将问题从 UNCONFIRMED（未确认）自动推进到 NEW（新问题）的票数门槛。总票额设为零，投票就关闭；门槛设为零，自动推进就关闭。用户在页面上点票，管理员在另一张页面上决定这些票能做多少事。

票箱旁边，还得摆张工位

同版用户手册列出了修复工作的其他部件：谁负责处理、负责人怎样排列自己的优先级、问题有多严重、计划在哪个版本完成，以及它依赖哪些问题先解决。票数另有一个字段。一个问题很受关注，可能仍在等另一项修复，也可能仍在等有空动手的人。

网页让抱怨有了固定地址，也让支持变得可累计、可查看。排期随后必须面对有限的人手和互相牵制的任务。Bugzilla 这段小历史的趣味，恰在于它把两种麻烦摆在了一起：开发者既要修软件，也要修收集修复愿望的办法。群众已经帮忙把手举起来了，系统至少该记住是谁举的。