Revisiones ciegas, ¿sí o no?

En la PyConES toda la vida hemos hecho revisiones “doble ciego”: quien revisa no sabe quién escribió la propuesta y quien escribió la propuesta no sabe quién revisa. Los motivos:

  • Por imitación
  • Para evitar que dieran charla “los de siempre”
  • Para evitar sesgos de género

Sin embargo, el otro día me encontré con esto:

And I’d especially like to thank the reviewer who pointed out all the issues with my abstract and gave me a nice behumblement that really fed into the structure of this talk. (And, thanks to the un-blinded process, I actually do know who to thank!)

https://matthewturk.github.io/2019-07-11-getting-lost-in-community-building/

Pregunté a Matthew y parece que la SciPy no hace revisiones ciegas:

Y en su lugar, lo que tienen es una guía que lista los sesgos y tratan de compensarlos de otras maneras:

https://www.scipy2019.scipy.org/chair-reviewer-guidelines

No hacer revisiones ciegas, en retrospectiva, tiene varias ventajas:

  • Muchas propuestas van “identificadas” con enlaces a repositorios de GitHub, o porque los proyectos son tan concretos que se sabe quién los hace. Hacer revisiones no ciegas pone las mismas condiciones para todo el mundo.
  • Se puede dar un feedback más personalizado y posiblemente más humano

Pero me parece que hace falta una gran cantidad de revisores, o por lo menos gente que se tome el proceso en serio y que ponga comentarios elaborados. No basta “no se entiende”.

¿Qué opináis?

Las revisiones ciegas son realmente justas para cualquier persona independientemente de su género, edad y experiencia. Además que el esfuerzo extra a la hora de rellenar todos los campos de la ficha sirve para descartar las propuestas impulsivas e irrelevantes.

Me parece una cuestión muy interesante, la verdad. Las revisiones ciegas responden a que sabemos que somos hijas de nuestros sesgos y que difícilmente los vamos a evitar. SciPy pone el dedo en la llaga, acepta que los sesgos son un problema y pone en marcha mecanismos para evitar que ensucien el proceso.

Estaría bien saber (si es posible) qué porcentaje de propuestas se quedan fuera (en función del género). Esto ayudaría a saber si estamos sufriendo los sesgos aunque creamos que no. Igual creemos que tenemos protección por hacer las revisiones ciegas y resulta que no es así. Y en la misma línea, ¿qué tal son los porcentajes en la SciPy?

También estaría bien saber qué aceptación tiene en candidatas y candidatos el hecho de que las revisiones sean ciegas o no.

Finalmente, como bien dices, hicimos las revisiones ciegas por imitación, pero podemos probar a imitar otras iniciativas y medir qué impacto tienen.

El objetivo de iterar sobre las revisiones es mejorar el proceso, hacerlo más justo y equitativo, ¿algo así? Si un cambio basado en hipótesis honestas y ciertas pruebas proporciona esto, creo que lo suyo es probar otros mecanismos que abran la puerta a más colectivos y a tantísimo talento que se nos queda oculto.

En cualquier caso, muchísimas gracias por traer esta cuestión a la palestra :slight_smile:

El tema de la revisión ciega no lo veo ni positivo ni negativo.

@Andros comenta que una evaluación ciega es justa. Cuando alguien enlaza a un repo un poco específico está poniendo nombres y apellidos a la propuesta. Esa propuesta deja de ser ciega. ¿Eso va en perjuicio de los que siguen estando ocultos? Lo que no veo, como comento, es que esto acabe siendo positivo o negativo para el que evalua y/o para el evaluado.

@Yami comenta que es buena idea iterar en el proceso de las revisiones para hacerlo más justo y equitativo. Me encantaría tener una definición clara de ‘justo y equitativo’. Ese sería un buen principio que podría ayudar a los revisores. ¿‘Justo y equitativo’ en base a la calidad técnica de las charlas y talleres del congreso de turno?, ¿‘Justo y equitativo’ en base a la calidad del respeto a las personas que participan en el congreso de turno?, ¿‘Justo y equitativo’ en base a las oportunidades que se le brindan a nuevas personas que se acercan a la comunidad del congreso de turno?, ¿‘Justo y equitativo’ en base al equilibrio del congreso de turno, que tenga un poco de todo, no que sea solo el mejor técnicamente, o el mejor en comunidad, o el mejor en representar minorías,…?,… Quizá este sería un tema para valorar por parte de la JD y quizá se podría crear un grupo de trabajo de larga duración para tener una opinión formada sobre qué es lo que se quiere a la hora de evaluar. Tenemos propuestas de otros años y de este, se podrían hacer experimentos probando con propuestas ciegas y no ciegas con grupos de evaluadores diversos durante los próximos meses a ver si se llega a alguna conclusión.

Por tanto, en relación a esto, se puede probar una evaluación no ciega en próximas ocasiones a ver si es más positivo, en general, pero intentaría ir un poco más a la raíz del tema (que no problema), ¿qué es lo que queremos para PyConES y cómo lo vamos a evaluar?

Gracias, @astrojuanlu por traer el tema.

Personalmente creo que un proceso de revisión abierta traslada una carga de responsabilidad y de madurez al reviewer que antes “asumía” el método ciego. Sobre todo el juzgar lo que es justo y lo que no, y como bien dice @kikocorreoso son conceptos muy subjetivos y difusos que todavía hay que definir muy bien.

Echando un ojo a la organización del SciPy que linkeó @astrojuanlu, y a la organización de la SciPy2018, he podido observar que en ambas ocasiones sólo hay dos miembros del Program Committee y ambas veces han sido personas conocidas y maduras (hasta donde he podido investigar, que he tenido poco tiempo :stuck_out_tongue_winking_eye:)

En el caso de la pycones, si no me equivoco, cada año hay diferentes revisores, y un número grande de ellos. Y estos revisores permanecen en el anonimato.

Quizás podríamos investigar más acerca del proceso de revisión de principio a fin y de su contexto, y ver si este modelo de revisión abierto nos conviene o tenemos que hacer más cambios para que podamos adoptarlo de forma exitosa.

TLDR: Pienso que el éxito de un proceso de revisión u otro dependen más en la organización del evento y del contexto del mismo que del proceso en sí. Como si de una tecnología se tratara, cada proceso tiene sus ventajas e inconvenientes y dependen del caso de uso de cada un@.