¿Qué miras cuando revisas el pull request de React de otra persona?

Primero la corrección del flujo de datos: dónde vive el estado, si los efectos son necesarios y tienen dependencias honestas, y si las keys son estables. Después los bordes de cara al usuario, que son los estados de carga, vacío y error, más el acceso con teclado y lector de pantalla. Después el rendimiento, solo donde sea medible. El estilo y los nombres van al final, y cualquier cosa que pueda decidir un linter o un formateador no debería ser ni un comentario de revisión.

Leo primero la descripción y los tests, luego el diff, porque quiero saber qué pretende hacer el cambio antes de juzgar cómo lo hace. Mi primera pasada es el flujo de datos. ¿Dónde vive este estado, podría vivir más abajo, ese efecto hace falta de verdad o es estado derivado, son honestas las dependencias o alguien ha silenciado la regla del linter sin decirlo, y son estables las keys de la lista? La segunda pasada son los bordes, que es donde se cuelan la mayoría de los bugs: qué renderiza esto mientras carga, cuando la lista está vacía y cuando la petición falla, y si puedo manejarlo con el teclado. La tercera es el rendimiento, pero solo si puedo señalar un coste real y no una corazonada. Intento marcar los comentarios como bloqueantes o como simple apunte, porque las quisquillosidades sin etiquetar atascan pull requests durante días. Y nunca comento el formato ni el orden de los imports; si importa, va en el linter, no en mi opinión.