Revisión por pares doble ciego cuando el artículo cita el repositorio de GitHub del autor para el código

Mi coautor y yo escribimos un artículo y el proyecto implicó la creación de una (pequeña) biblioteca de software. Parte de la novedad del papel es la salida del código, que es un objeto digital que no está destinado a la manipulación manual. Idealmente, el código (código abierto) también sería útil para otros. Una revista a la que estaba considerando enviar esto requiere una revisión por pares doble ciego, pero el repositorio de GitHub donde se almacena el código, al que se hace referencia en el documento, identifica a uno de nosotros simplemente mirando el nombre de usuario en la URL. Por supuesto, podemos ocultar nuestras identidades en el documento como autores, pero realmente necesitamos citar el repositorio de código.

No he tenido que hacer una revisión a doble ciego antes, por lo que no está claro qué debemos hacer. Mi coautor se encontrará con más problemas de este tipo a medida que continúe investigando con una combinación similar de código y papel como resultado.

¿Hay algo que podamos hacer, al menos como un primer intento de calmar las preocupaciones de las revistas?

¿Es esto algo que usted sospecha que será un problema, o ya es un problema (p. ej., los editores rechazaron su artículo)? En el primer caso, sugiero no preocuparse. Mi impresión con la revisión doble ciego es que opera con el "código de honor"; el velo del anonimato del autor se rompe fácilmente y los editores lo saben muy bien. El objetivo del doble ciego es evitar frotar las identidades de los autores en las caras de los árbitros, no descartar por completo la posibilidad de que los descubran.
@darijgrinberg Escribir, "Nuestro código está disponible en GitHub: https://github.com/AuthorName", parece frotar las identidades de los autores en las caras de los árbitros , notando que el repositorio de GitHub... identifica a uno de nosotros [por] el nombre de usuario en la URL .
@user2768: Por lo general, los árbitros no buscan tales citas hasta que ya han leído gran parte del documento. Aun así, los acortadores de enlaces pueden ayudar (solo asegúrate de eliminarlos antes de la versión final).
@darijgrinberg Los acortadores de enlaces nunca deben incluirse en un manuscrito enviado, ya que permiten al autor realizar un seguimiento de quién accede al recurso vinculado. Si el autor puede ver en sus registros que alguien de la red de la Universidad Técnica de Sikinia hizo clic en su enlace, es fácil adivinar quién es el árbitro.
@FedericoPoloni: ¡¡Buen punto!! Mejor solución: Zenodo aloja instantáneas de los repositorios de GitHub, y se puede acceder a ellas mediante identificaciones que no incluyen el nombre del autor (al menos no visiblemente); así que eso podría ser lo correcto (también por razones de conservación a largo plazo).
@Abigail: Vea mi comentario al OP. Hacer que su autoría sea completamente inidentificable bordea lo imposible (la mayoría de las veces, sus árbitros pertenecerán a las 50 personas que estudian su pequeño subtema, y ​​podrán hacer conjeturas sobre quién es usted en función de su visibilidad). intereses, antecedentes y estilo de redacción); lo mejor que puede esperar es que los árbitros no se enfrenten a él si no lo intentan deliberadamente.
Me parece extraño que el Journal solicite una revisión a doble ciego y, sin embargo, supuestamente no permitiría algunos reemplazos temporales de citas para garantizar que, de hecho, es ciego.
Una variante interesante: el repositorio es público desde el día 1. Para cuando finalmente se envíe el documento, es posible que el software ya sea ampliamente conocido en el subcampo, y la revisión doble ciega es imposible. Veo esto mucho en la bioinformática.
Para mí, el comentario de @darijgrinberg es la mejor respuesta, y lo votaría si apareciera como tal. Proporcionar una instantánea separada no funciona: si estuviera revisando el código en un repositorio, estaría mirando tanto el historial como el código en sí. Además, cuando un lector tropieza con un URI de github dentro del documento, probablemente ya haya llegado a algunas conclusiones provisionales de aceptación/revisión/rechazo. Si te encuentras en un campo con animosidades tan intensas que cegar al autor es de alguna manera vital, entonces tal vez deberías hablar con el editor sobre qué árbitros te gustaría que evitaran.
@NormanGray, ¿qué comentario precisamente? Creo que esto es más una medida de reducción de sesgo que una medida de protección del autor dada la revista en cuestión.
@DavidRoberts Ah, ¡buen punto! Era el del 'código de honor', lo que sugiere que el objetivo del cegamiento es reducir las posibilidades de identificar inadvertidamente al autor (por el motivo que sea), en lugar de borrar la posibilidad, a través de acciones que crean fricción sin realmente funcionar completamente: soluciones difíciles de manejar. a algo que puede no ser un problema importante. No estoy 100% de acuerdo con esto, pero creo que se acerca más al corazón real del problema que las respuestas técnicas existentes.

Respuestas (5)

Censure el nombre del repositorio y proporcione el código a los árbitros como un archivo auxiliar.

Si los árbitros quieren, esta ofuscación se elude fácilmente: tome cualquier parte no trivial del código (un nombre de función expresivo o un comentario es suficiente) y colóquelo en Google.
@NichtJens en la era de arxiv, esto a menudo también funciona con títulos en papel, y está bien. Los autores solo tienen la responsabilidad de permitir que el revisor proceda a doble ciego.
Está bien, veo lo que quieres decir. El equivalente al repositorio citado sería mencionar la preimpresión en el envío (por ejemplo, "Una preimpresión de este artículo está disponible como arxiv:1234.12345").
@NichtJens aún peor, porque el número arXiv no incluye el nombre del autor.
FWIW, uso esto regularmente para crear una copia de un repositorio de Git sin ningún historial en ../repo-name-copy desde dentro de ese repositorio: git -C "$(git rev-parse --show-toplevel)" checkout-index --all --prefix="../$(basename "$(git rev-parse --show-toplevel)")-copy/". También puede querer grep -r -e 'Author Name' -e 'Other Author Name'en el directorio resultante y hacer algo como sed -i 's/Jane Doe/Author 1/g;s/Joe Bloggs/Author 2/g' PATHreemplazar nombres.
@ l0b0 Normalmente usaría git archive HEAD > filename.zipen lugar de su comando complicado --- ¿cuál es la ventaja de este método?
@FedericoPoloni git rev-parse --show-toplevelle brinda el directorio de nivel superior del repositorio, por lo que este comando funcionará cuando se ejecute en cualquier lugar dentro del repositorio. Aparte de eso, supongo que depende de si desea una copia de la estructura del directorio o un archivo.
@Federico Personalmente, simplemente reviso el repositorio en la forma en que quiero que sea y luego elimino la carpeta .git, pero es bueno saber que también hay un comando para eso;) (¿cómo funciona el archivo con los submódulos, por ejemplo?)
@Voo No tengo idea --- Yo mismo no soy un gurú de git.

  • Haga una copia del repositorio disponible en una URL anónima, por ejemplo, usando Google Drive con una cuenta nueva.

  • Envíe una copia del depósito con su manuscrito (si la revista lo permite), o envíe el depósito al editor por correo electrónico.

Si los árbitros quieren, esta ofuscación se elude fácilmente: tome cualquier parte no trivial del código (un nombre de función expresivo o un comentario es suficiente) y colóquelo en Google.
@NichtJens Del mismo modo, el árbitro puede colocar una oración o dos (del papel) en Google y encontrar la preimpresión. Como se señaló en otro comentario, el velo del anonimato del autor se rompe fácilmente y los editores lo saben muy bien .
¡Exactamente! ¿No sería eso un problema también para las revisiones doble ciego? EDITAR: Aparentemente es: statmodeling.stat.columbia.edu/2018/01/15/…
@NichtJens El objetivo de la revisión por pares doble ciego no es hacer que sea imposible que las personas eliminen el cegamiento, sino hacerlo más difícil sin algún esfuerzo por parte de los revisores o autores. Ningún sistema es perfecto, y el sistema necesita operar con una suposición mínima de comportamiento ético por parte de los revisores, incluyendo no esforzarse por encontrar deliberadamente quiénes son los autores.
Está bien, veo lo que quieres decir. Gracias por aclararlo.
@NichtJens como revisor, el sistema es más para que pueda evitar ser sesgado involuntariamente: no intentaré buscar a los autores, porque no me importa, sin embargo, si veo un nombre que reconozco en parte superior del documento o en la URL de github, no hay nada que pueda hacer para no verlo.
@Abigail Bueno, el registro de cambios podría ofuscarse fácilmente... Es lo que ya se propuso aquí .

Estoy literalmente en la misma situación que tú en este momento, y encontré este repositorio/servicio en GitHub hace unos días: . Dado que su código y nombres ya son públicos, solo proporciona un nivel básico de ofuscación. Sin embargo, siempre que los revisores sean honestos y no intenten activamente averiguar los nombres de los autores, entonces debería evitar que descubran accidentalmente quién es usted.

Más allá de eso, el enfoque más efectivo es no publicarlo hasta después de la revisión y, en su lugar, proporcionar el código/documentación/lo que sea de forma privada a través de la revista. Mi preocupación con este enfoque es que depende de eliminar cualquier asociación de nombres del material. Entonces, ¿qué sucede si un revisor rechaza el manuscrito y luego publica el código o partes del mismo como propio antes que usted? La falta de un registro público de su parte podría hacer que resolverlo sea un dolor de cabeza.

En última instancia, no hay mucho que pueda hacer con respecto a los revisores que intencionalmente intentan eludir el anonimato. Incluso sin su nombre en ninguna parte, si ha publicado antes, alguien podría tener una idea bastante buena de quién es usted a través del contenido y los patrones en el manuscrito.

"el enfoque más efectivo es no publicarlo hasta después de la revisión", <-- demasiado tarde
@DavidRoberts lo vi. Incluí ese segundo párrafo más para cualquiera que pueda tropezar con esta pregunta en el futuro.
Si los autores tienen acceso, aunque por medios separados, a una copia anónima del código, ¿por qué debería evitarse también la publicación del código?
@CurtJ.Sampson Si los revisores necesitan realizar una búsqueda en la web de un término o concepto en el documento, la documentación en el repositorio podría incluir los resultados de la búsqueda, especialmente si se trata de un área de investigación especializada. Alternativamente, un revisor podría querer ver qué otro trabajo se ha realizado y asegurarse de que el documento lo esté citando correctamente. Finalmente, un revisor puede buscar el código en sí para asegurarse de que otra persona no haya publicado el código (para asegurarse de que sea un trabajo original y no un código plagiado o que viole los derechos de autor)
Tener un registro de envío, junto con poner el código en un repositorio público de git (incluso si el código aún no es público), idealmente preserva el tiempo de los autores. Es posible establecer marcas de tiempo arbitrariamente en git, pero el repositorio público debe tener su propia contabilidad para el repositorio. Además, uno puede hacer público solo el último o una serie de hashes de confirmación u otra suma de verificación de la base de código.

Lo más simple que puede hacer (que me sorprende que no se haya sugerido antes, y es razonablemente común) es crear una cuenta anónima de GitHub y duplicar su código allí (cargue el código en una sola confirmación, no duplique el repositorio en sí) ya que no desea que su nombre de usuario real esté presente en el historial de confirmaciones).

Existe Anonymous GitHub, un servidor proxy para admitir la navegación anónima de los repositorios de Github:

https://anónimo.4open.ciencia/

Uso:

  1. Complete la URL del repositorio de Github.
  2. Complete la lista de términos que serán anonimizados. La anonimización del contenido se realiza reemplazando todas las apariciones de palabras en una lista por "XXX". La lista de palabras normalmente contiene el nombre de la institución, los nombres de los autores, los inicios de sesión, etc.
  3. Defina si desea una fecha de vencimiento para su repositorio anónimo. Puede mantenerlo para siempre, eliminar el repositorio después de una fecha específica o redirigir al usuario al repositorio de GitHub.

Como resultado, se crea una url única con el contenido de su repositorio, por ejemplo, http://anonymous.4open.science/repository/840c8c57-3c32-451e-bf12-0e20be300389/ .

Revisión por pares doble ciego cuando el artículo cita el repositorio de GitHub del autor para el código
RespuestasAquíPolítica de privacidad1y, 0v