Esta base de datos probablemente se inspiró en los sistemas de seguimiento de errores.
Con cualquier tipo de seguimiento de problemas o seguimiento de errores, una ocurrencia común es que la persona que informó un error no está satisfecha con la forma en que se resolvió. Por ejemplo, un probador puede informar un error, y un programador puede afirmar que se solucionó, pero cuando el probador verifica, en realidad no está solucionado. El programador podría haber malinterpretado el informe de error y haber solucionado algo diferente, por ejemplo ... esto es sorprendentemente común. O bien, el programador puede pensar que el error no es lo suficientemente importante como para solucionarlo, y el probador puede estar en desacuerdo.
En los sistemas de seguimiento de errores, un programador RESUELVE un error, lo que significa que creen que lo han solucionado o que han decidido no solucionarlo ... de cualquier manera, lo solucionaron.
En la mayoría de los sistemas de seguimiento de errores, cuando se resuelve un error, se reasigna a la persona que lo abrió. Esto tiene dos propósitos:
- Notifica al abridor que se ha solucionado el error
- Le permite al abridor decidir si está satisfecho con la resolución. Si lo son, pueden cerrarlo. Si no lo están, pueden reactivarlo y enviarlo de vuelta.
En otras palabras, el error debe permanecer abierto, incluso después de que se resuelva, hasta que el abridor original decida que está satisfecho con la resolución.