Comentarios de revisión que se corrigen

Un comentario de revisión tiene que contestar, sin que el desarrollador pregunte, cuatro cosas: dónde está el problema, por qué camino llega el dato hasta hacer daño, qué le pasaría a una persona concreta si nadie lo arregla y qué cambio concreto se propone. Añadir la severidad, si bloquea la fusión y una referencia como el CWE ayuda a priorizar y a buscar más.

El tono importa tanto como el contenido. Se habla del código y no de quien lo escribió, y cuando no se está seguro se pregunta en lugar de afirmar. Un comentario que acierta pero ofende acaba discutido; uno que no explica el camino del dato acaba en un «no veo el problema». En los dos casos el código se queda igual.

Abre el laboratorio y lee guia-comentarios.txt y después comentarios-PR-790.txt. Fíjate en los que se cerraron sin cambio y en por qué. Un falso positivo bien explicado por el desarrollador no es un fracaso del desarrollador: casi siempre es un comentario escrito antes de hacer la traza.

Un bloqueo que no se arregla es tiempo perdido de las dos partes. Mide cuántos de los comentarios que se marcaron como bloqueantes terminaron con el código corregido.

La guía dice en qué dos casos un comentario bloquea la fusión. Recorre los bloqueantes y comprueba, uno por uno, si cumplen alguna de las dos condiciones. Un bloqueo que la guía no respalda gasta la confianza del equipo en los bloqueos que sí importan.

Ese mismo comentario lleva semanas pendiente, y la respuesta del desarrollador dice por qué: no sabe qué tiene que mirar. Supón que, al hacer la traza, la línea 88 resulta ser la que, cuando falla el guardado, devuelve al navegador el mensaje de error completo de la base de datos, con nombres de tablas y columnas. Elige la versión que sigue la guía del equipo.