Résumé

  • En 2001, Bugzilla a modifié un mécanisme qui supprimait les votes lors de changements de paramètres ou de produit.
  • Les quotas et le passage automatique à un nouvel état relevaient de l'administration ; les corrections exigeaient toujours un responsable et une place dans son programme.

Le déménagement d'un dossier est rarement un grand événement démocratique. Dans les premières versions de Bugzilla, il pouvait pourtant faire disparaître tout son électorat. Un problème changeait de produit, ses votes s'effaçaient. Le logiciel avait gardé le bogue avec une admirable fidélité. Pour les gens qui souhaitaient sa correction, le service était moins soigneux.

La plainte conservée sous le numéro 28882 remonte à février 2000. Matthew Tuck y raconte qu'un changement de politique de vote a fait dégringoler un ticket auparavant classé parmi les dix premiers. Certaines contributions ont été entièrement retirées. Il propose de ramener les allocations au nouveau plafond. Une réduction de quota pouvait très bien s'arrêter avant zéro.

La discussion finit par poser un problème plus intéressant que le compteur lui-même. Réduire la quantité attribuée à un seul bogue était assez simple. Réduire l'enveloppe totale d'un utilisateur obligeait à choisir parmi plusieurs préférences. Quel dossier allait perdre ses voix ? La commodité administrative avait besoin d'un principe de sélection.

Le droit de garder un compte provisoirement désordonné

La version 2.14, publiée en 2001, a retenu deux traitements. Les votes d'une personne sur un bogue seraient ramenés au plafond applicable, avec notification. En cas de dépassement du total autorisé pour un produit, les allocations seraient conservées. L'utilisateur pourrait ensuite modifier ses votes pour régulariser la situation. Cette version ne prévoyait pas d'autre mesure pour l'y contraindre.

Ce petit désordre accepté avait une utilité : il sauvait un choix déjà exprimé. La réaffectation d'un bogue à un autre produit cessait aussi d'enlever automatiquement tous ses votes. Le classement devenait capable de déplacer un problème avec une partie essentielle de son histoire.

L'histoire de la correction elle-même est savoureuse. Le ticket 28882 avait été fermé comme invalide en février 2001, puis rouvert le même jour. Il a finalement été déclaré corrigé en août. Même la réparation du vote avait dû trouver son chemin dans la file des réparations.

Le guide d'administration livré avec Bugzilla 2.16, en 2002, détaille les commandes. Chaque produit pouvait avoir un quota par utilisateur, un plafond par utilisateur et par bogue, ainsi qu'un seuil de votes faisant passer automatiquement un rapport de UNCONFIRMED à NEW. Un quota nul désactivait le vote ; un seuil nul désactivait cette promotion. La participation publique avait donc un tableau de réglages et quelqu'un pour le tenir.

Le succès dans les urnes laisse du travail sur l'établi

Le guide utilisateur de cette version réservait d'autres champs à la personne chargée de corriger, à ses priorités, à la gravité, à la version visée et aux dépendances entre problèmes. Une correction attendue pouvait être retenue par une autre. La visibilité d'une demande et les heures disponibles devaient se rencontrer quelque part.

Bugzilla donnait ainsi une adresse durable au mécontentement et une forme comptable au soutien. C'était déjà beaucoup pour une page web. Pour que le résultat reste utile, il fallait conserver les préférences pendant les réorganisations, puis montrer comment elles entraient dans le travail quotidien. Le bogue avait obtenu des électeurs. Il lui fallait encore trouver un réparateur.