Resumen

  • Bugzilla 2.14 sustituyó el borrado de votos asociado a cambios de producto o de configuración por reglas que conservaban más información.
  • Los administradores fijaban cuotas y umbrales; los responsables de corregir seguían organizando prioridades, dependencias y versiones previstas.

En febrero de 2000, Matthew Tuck pidió a Bugzilla algo bastante razonable: si iban a reducirle los votos, que le dejaran los que todavía cabían. En el informe 28882 explicó que una modificación de las reglas había hundido en la clasificación un problema que apoyaba. Según su relato, antes figuraba entre los diez primeros; después, algunos participantes habían desaparecido por completo del recuento.

El gestor de errores había encontrado una forma demasiado cómoda de cuadrar las cuentas. Cuando cambiaba la política de votación, o un problema pasaba a otro producto, podían borrarse todos sus votos. El fallo informático seguía haciendo su trabajo. Las personas que querían arreglarlo tenían que volver a hacerse notar.

Reducir un límite requiere elegir

La reclamación tuvo una vida movida: se cerró como inválida en febrero de 2001, se reabrió ese mismo día y acabó marcada como resuelta en agosto. En la conversación apareció una dificultad concreta. Recortar el apoyo de una persona a un solo problema hasta un nuevo máximo era sencillo. Recortar su bolsa total de votos exigía decidir qué problemas perdían los suyos. El ordenador podía hacer la resta; alguien tenía que escoger a quién le tocaba.

Las notas de la versión 2.14 describieron el arreglo de 2001. Los votos por persona y problema se ajustarían al máximo aplicable, avisando al usuario. Si este quedaba por encima de su cuota total en un producto, se conservaría el exceso. Solo podría modificar sus votos para corregir esa situación. La versión no añadía otra medida que lo obligara a regularizarla.

El resultado tenía una imperfección deliberada: durante un tiempo, las cuentas podían mostrar más votos de los permitidos. A cambio, conservaban las preferencias expresadas. Cambiar un informe de producto también dejaba de vaciar automáticamente su apoyo. Era una mejora pequeña en apariencia y bastante seria para quien ya se había molestado en participar.

El público elegía sus molestias; la administración, las reglas

El manual de administración incluido en Bugzilla 2.16, de 2002, permite ver las palancas. Cada producto tenía una cuota por persona, un máximo por persona para cada problema y un umbral opcional que cambiaba automáticamente el estado de UNCONFIRMED a NEW. Una cuota de cero apagaba la votación. Un umbral de cero apagaba ese cambio automático. La participación cabía en una pantalla de configuración, con bastante poder para quien la administraba.

El manual de uso de la misma versión reservaba otros campos para el trabajo: responsable, prioridad, gravedad, versión objetivo y dependencias. El responsable usaba la prioridad para ordenar sus problemas. Las dependencias mostraban qué arreglo esperaba a otro. Un contador muy concurrido podía señalar una necesidad mientras todas las horas del programador seguían ocupadas.

La web ofrecía así un lugar donde reunir peticiones y seguirlas. También dejaba a la vista el recorrido entre querer una corrección y disponer de ella. La historia de los votos perdidos muestra cuánto dependía esa participación de operaciones humildes: conservar un dato, explicar un recorte, trasladar bien un expediente. Para escuchar al público, primero convenía que el archivador dejara de comerse sus papeletas.