Zusammenfassung

  • Bugzilla 2.14 änderte 2001 Regeln, nach denen Stimmen bei neuen Abstimmungseinstellungen oder einem Produktwechsel gelöscht worden waren.
  • Quoten und automatische Statuswechsel lagen bei der Administration; für die Reparatur blieben Zuständigkeit, Priorität, Abhängigkeiten und Zielversion wichtig.

Eine Fehlerdatenbank sollte ein gutes Gedächtnis haben. Das frühe Bugzilla konnte sich jedoch auf eigenwillige Weise an einen Fehler erinnern: Der Bericht blieb erhalten, seine Stimmen gingen beim Umzug zu einem anderen Produkt verloren. Die Softwarestörung hatte ihre neue Adresse. Die Unterstützer standen draußen.

Im Februar 2000 meldete Matthew Tuck Fehler 28882. Nach seiner Schilderung hatte eine Änderung der Abstimmungsregeln einen von ihm unterstützten Bericht aus den ersten zehn Plätzen verdrängt. Bei mehreren Nutzern waren sämtliche Stimmen für diesen Bericht verschwunden. Sein Vorschlag war bescheiden: Wer über der neuen Höchstzahl liegt, wird auf diese Zahl gekürzt. Eine kleinere Portion musste schließlich noch keine leere Schüssel ergeben.

Die Diskussion machte das Problem hinter der einfachen Zahl sichtbar. Den Beitrag eines Nutzers zu einem einzelnen Fehler konnte man am neuen Maximum abschneiden. Wurde dagegen sein gesamtes Kontingent für ein Produkt kleiner, musste jemand auswählen, welchen seiner Anliegen Stimmen entzogen würden. Dafür brauchte es eine Regel über die Auswahl, bevor gerechnet werden konnte.

Eine vorläufige Überschreitung bekam Bleiberecht

Die Veröffentlichungsnotizen zu Version 2.14 beschrieben 2001 die Lösung. Pro Person und Fehler galt weiterhin die jeweilige Obergrenze; darüberliegende Stimmen wurden gekürzt, der Nutzer informiert. Lag seine Gesamtsumme für ein Produkt über dem erlaubten Kontingent, blieben die Stimmen zunächst bestehen. Weitere Änderungen waren nur zur Beseitigung dieser Überschreitung möglich. Diese Version unternahm nichts Zusätzliches, um die Bereinigung zu erzwingen.

Damit durfte die Summe vorübergehend unordentlich aussehen. Dafür blieb eine bereits abgegebene Präferenz erhalten. Auch das Verschieben eines Berichts in ein anderes Produkt löschte nicht länger automatisch alle Stimmen. Die Verwaltung musste mit den Wünschen arbeiten, die schon da waren.

Die Beschwerde selbst hatte inzwischen das Verfahren aus nächster Nähe kennengelernt: im Februar 2001 als ungültig geschlossen, noch am selben Tag wieder geöffnet, im August als behoben markiert. Selbst die Reparatur der Beteiligung musste auf ihre Bearbeitung warten.

Im Administrationshandbuch der 2002 erschienenen Version 2.16 stehen die Stellschrauben. Für jedes Produkt ließen sich das persönliche Kontingent, das Maximum pro Person und Fehler sowie eine Schwelle für den automatischen Wechsel von UNCONFIRMED zu NEW festlegen. Ein persönliches Kontingent von null schaltete die Abstimmung aus. Eine Schwelle von null schaltete den automatischen Wechsel aus. Hinter dem öffentlich sichtbaren Zähler stand eine ziemlich wirksame Einstellungsseite.

Die Werkbank hatte ihren eigenen Kalender

Das Benutzerhandbuch derselben Version führte außerdem Verantwortliche, Priorität, Schweregrad, Zielversion und Abhängigkeiten auf. Mit der Priorität ordnete der Bearbeiter seine eigenen Fehler. Eine Korrektur konnte erst möglich werden, nachdem eine andere erledigt war. Viele Stimmen machten den Wunsch sichtbar; die verfügbare Arbeitszeit musste jemand verteilen.

Bugzilla gab Beschwerden einen dauerhaften Ort im Netz. Dort konnten andere den gleichen Fehler finden, Unterstützung hinzufügen und Veränderungen verfolgen. Diese Form der Beteiligung brauchte verlässliche Buchführung, sobald Kategorien oder Regeln wechselten. Ein Abstimmungsfeld war schnell beschrieben. Dass die Stimmen auch den nächsten Verwaltungsakt überlebten, erforderte eigene Sorgfalt.