Summary

  • Bugzilla's 2001 release changed rules that had erased votes when voting settings changed or a bug moved between products.
  • Users could express demand and, under configured rules, advance a report's status; developers still had priorities, dependencies and target versions to manage.

A software bug could survive a change of address while its supporters disappeared. Early Bugzilla had a remarkably effective way of thinning a crowd: move the report to another product, or change the voting rules, and its votes could be wiped away. The problem stayed. The paperwork developed amnesia.

In February 2000, Matthew Tuck filed bug 28882 about the voting policy. He reported that a favoured ticket had fallen from the top ten after a rule change, with voters removed. His proposed remedy was simple: when a new limit reduced the votes a person could assign to a bug, reduce their allocation to that limit. Throwing the whole allocation away was a rather enthusiastic interpretation of “less”.

The complaint had its own journey through the tracker. It was closed as invalid in February 2001, reopened that day and eventually marked fixed in August. During the discussion, a harder question emerged. A lower allowance for one bug was easy to apply. If somebody's total allowance across a product shrank, which of their chosen bugs should lose support? The software could count. Choosing on a user's behalf required a policy.

A ballot that could survive a filing change

The 2.14 release notes recorded the new bargain. A person's votes on an individual bug would be clipped to the applicable maximum, with notification. If a change left that person above the total permitted for a product, the system would preserve the excess. They could then update their votes only to resolve the over-allocation. That version imposed no further action to make them do so.

This was a practical compromise with a small untidy edge. A temporarily excessive total was allowed to remain because preserving expressed preferences mattered. The tracker acquired a memory, and administrators acquired a reconciliation problem. Moving a report between products also stopped automatically stripping it of all its votes. Refiling could now carry more of the audience along.

The machinery behind the audience is visible in the administration guide shipped with version 2.16 in 2002. An administrator set the allowance per person for each product, the maximum a person could put on one bug, and the threshold for automatically moving a report from UNCONFIRMED to NEW. Setting the personal allowance to zero switched voting off. Setting the status threshold to zero switched that automatic move off. Quite a lot of public participation fitted inside a product settings page.

The calendar had another keeper

Votes supplied a useful signal to the people doing the work. Bugzilla's user guide for the same release also described an assignee responsible for the fix, a priority field for ordering that person's bugs, severity, a target version and dependencies. A much-wanted repair could depend on another repair. Someone still needed to write and check it.

The distinction had a very ordinary consequence: a growing vote count could make demand more visible while the calendar stayed crowded. Readers could inspect the report, add support and follow its changes; the work still travelled through people with particular responsibilities. In this early corner of the participatory web, the ballot box needed both a reliable memory and a neighbouring workbench. Building the first did not staff the second.