El primer bug registrado en un proyecto nuevo debería ser el número uno. Normalmente no lo es.
La mayoría de las herramientas que nacen con un único contador compartido se quedan con él, porque al principio solo hay un proyecto y la diferencia no se nota. Luego llega el segundo cliente, abre su primer proyecto, registra su primer bug y le toca el número #913. Nada está roto. Simplemente da la sensación de haber entrado en el edificio de otro.
Esta semana lancé la numeración por proyecto en BugDump, y el razonamiento detrás sirve más allá de mi producto. Un ID de bug es una de las pocas piezas de tu modelo de datos que la gente dice en voz alta, y eso cambia lo que se le exige.
Lo que cuesta de verdad un contador global
Filtra información. Un número sacado de una secuencia compartida le dice a cualquiera que lo lea, más o menos, cuánto tráfico total tiene el sistema. Dos bugs registrados con un mes de diferencia en tu proyecto revelan cuántos bugs registraron todos los demás entre uno y otro. Es el mismo tipo de problema que los números de factura correlativos, y es la razón por la que las herramientas de facturación dejaron de usarlos.
Se lee como ruido. #913 no significa nada para quien lo mira. No es el bug 913 de nada que pueda ver. El número es lo bastante grande para que cueste retenerlo y lo bastante arbitrario para que no puedas comprobar si tiene sentido.
Desperdicia una señal gratis. Cuando la numeración es por proyecto, el número también es un recuento aproximado. BD-6 significa que este proyecto ha tenido un puñado de bugs. BD-2400 significa algo muy distinto, y lo sabes sin abrir ningún dashboard.
Nada de esto es grave. Muchas herramientas buenas usan un contador global durante años. Pero es un pequeño impuesto que se paga en cada ID, para siempre, y arreglarlo sale barato.
Por qué el prefijo se gana su sitio
La numeración por proyecto crea un problema nuevo: los números dejan de ser únicos. La tarea 42 existe en cada proyecto que tienes.
La ruta de la URL ya lo resuelve, porque lleva el proyecto. Pero una conversación no tiene URL. Alguien dice «¿puedes mirar la 42?» en un canal donde se habla de tres proyectos, y la frase es ambigua de verdad.
Una clave corta delante del número lo arregla justo donde aparece la ambigüedad: en la conversación entre personas. BD-42 no es ambiguo como lo es 42, y cuesta tres caracteres. Jira lleva veinte años acertando en esto, y Linear, Shortcut y Sentry llegaron al mismo sitio cada uno por su cuenta.
La clave debe deducirse, no exigirse. Pedirle a alguien que invente una clave de proyecto durante el registro es un pequeño impuesto en un momento en que intenta hacer otra cosa. Dedúcela del nombre del proyecto (Bug Dump se convierte en BD) y deja que la gente la cambie después en los ajustes, cosa que la mayoría nunca hará.
Las tres decisiones de diseño que importan
Una vez que te decides por números por proyecto con prefijo, tres preguntas deciden si el resultado es agradable o molesto.
1. ¿Se reutilizan los números después de borrar?
No. Nunca deben reutilizarse.
Si borrar la tarea más reciente libera su número para la siguiente, un enlace, un mensaje de commit o un hilo de Slack que mencione BD-9 puede empezar, sin avisar, a apuntar a otro bug. El fallo es silencioso y puede aparecer mucho después, la peor combinación posible.
Mantén un contador que solo suba. Los huecos en la secuencia no son un defecto; son la prueba visible de que las referencias antiguas siguen significando lo que decían.
2. ¿El prefijo es parte de la dirección o decoración?
Esta es la interesante, y las dos respuestas se pueden defender.
Si el prefijo es decoración, BD-42 y 42 son dos formas de escribir la misma dirección y las dos abren la tarea. Cambiar la clave de un proyecto sale gratis: las etiquetas se actualizan en todas partes, los enlaces siguen funcionando y nadie se da cuenta.
Si el prefijo es parte de la dirección, solo funciona la etiqueta actual exacta. Cambiar una clave rompe todos los enlaces que llevan la antigua.
Elegí la segunda, a propósito, después de haber empezado por la primera. El argumento que ganó: una URL con un prefijo que no es la clave de este proyecto es, en cualquier caso realista, un error. Alguien pegó un enlace del proyecto equivocado, se equivocó al teclear o sigue una referencia caducada. Abrir la tarea que tenga ese número en este proyecto no ayuda. Parece que funcionó y, sin avisar, muestra el bug equivocado.
Así que un prefijo equivocado recibe un 404, igual que un número con ceros a la izquierda como BD-007 y que un número que no corresponde a ninguna tarea. El número a secas sigue siendo una dirección permanente que ningún cambio de clave puede romper, y es la forma que el producto pone en cada enlace, correo y payload de webhook que genera.
El coste es real y conviene decirlo claro: cambia una clave y los enlaces compartidos con la antigua dejan de funcionar. Es el precio de no enseñarle nunca a nadie el bug equivocado.
3. ¿Funcionan las dos formas en todas partes?
Deberían. La gente copia la etiqueta que ve, no la que tu app usa en sus enlaces.
Si tu interfaz muestra BD-42 en una tarjeta, entonces BD-42 pegado en la barra de direcciones tiene que funcionar, o habrás creado una pequeña trampa para cualquiera que haga lo obvio. Acepta las dos formas, conserva la que usó el visitante al llegar y genera tú la canónica.
Lo que sigue siendo un número
El prefijo es para las personas. Las máquinas deberían seguir recibiendo enteros.
Los payloads de webhooks, las respuestas de la API y los argumentos de las herramientas MCP de BugDump siguen llevando el número, con la etiqueta visible al lado como un campo aparte. Nada que ya leyera un payload tuvo que cambiar, y nadie tiene que escribir un parser de cadenas para saber a qué bug se refiere un evento.
Vale la pena mantener esa separación a propósito mientras construyes. La etiqueta es cosa de presentación. En cuanto se cuela en tus contratos de integración, cambiar la clave de un proyecto se convierte en un cambio incompatible de la API, y un ajuste cosmético pasa a ser algo que nadie se atreve a tocar.
Migrar sin romper lo que la gente ya envió
La parte incómoda de lanzar esto es que los IDs ya existen y ya circulan: en correos, en el historial del chat y en los tickets de otras personas.
Renumerar las tareas existentes para que cada proyecto empiece limpio en 1 es tentador y es un error. Cada referencia antigua pasa a apuntar a otra cosa sin avisar. La alternativa es más aburrida y es la correcta: deja los números existentes como están, empieza el contador de cada proyecto por encima de su número más alto y deja que los proyectos antiguos lleven IDs salteados para siempre. Los proyectos nuevos empiezan limpios desde 1, los enlaces antiguos siguen significando lo mismo y no hace falta avisar a nadie.
La numeración es una función pequeña. También es una que cada persona del equipo toca decenas de veces al día, lo cual es un buen argumento para dedicar una tarde a hacerla bien en lugar de vivir con #913 indefinidamente.
Te puede interesar
La clave interna que también era el nombre visible — cómo la clave estable de cada prioridad acabó siendo también el valor que recibía el frontend, y qué costó hacer editables las prioridades.
Campos personalizados en un bug tracker: qué añadir y qué evitar — la prueba que separa un campo útil de uno que estará vacío en seis semanas, y los cuatro que compensan.
Niveles de prioridad de bugs: por qué cuatro opciones fijas nunca encajan — para qué sirve una escala de prioridades y cuántos niveles necesitas de verdad.