Esta pregunta solo puede ser respondida realmente por el líder de su proyecto, o por quien esté a cargo del "proceso de emisión de boletos".
Pero déjame preguntarte de otra manera: ¿por qué no grabarías un error que parcheste?
La única razón insondable que veo es que el esfuerzo por presentar el informe de error, cometerlo y cerrarlo, es un orden de magnitud mayor que el tiempo para corregir el error.
En este caso, el problema no es que el error sea tan fácil de solucionar, sino que el papeleo lleva demasiado tiempo. Realmente no debería. Para mí, la sobrecarga para crear un boleto de Jira es presionar c
, luego ingresar un breve resumen de 1 línea y presionar Enter
. La descripción ni siquiera es general, ya que puedo cortar y pegar eso en el mensaje de confirmación, junto con el número de problema. Al final, . c <Enter>
y el problema está cerrado. Eso se reduce a 5 pulsaciones de teclas sobre la cabeza.
No sé sobre usted, pero eso es lo suficientemente pequeño como para que sea una política incluso en proyectos pequeños para registrar cada corrección de errores de esta manera.
El beneficio es obvio: hay bastantes personas que pueden trabajar fácilmente con un sistema de tickets como Jira, pero no con el código fuente; También hay informes generados desde el sistema de tickets, pero no desde la fuente. Definitivamente desea que sus correcciones de errores estén allí, para aprender sobre posibles desarrollos, como una afluencia cada vez mayor de pequeñas correcciones de errores de 1 línea, que podrían proporcionarle una idea de los problemas del proceso o lo que sea. Por ejemplo, ¿por qué tiene que hacer tan pequeñas correcciones de errores a menudo (suponiendo que suceda a menudo)? ¿Puede ser que tus pruebas no sean lo suficientemente buenas? ¿La corrección del error fue un cambio de dominio o un error de código? Etc.