Question:
Examen en double aveugle par les pairs lorsque le papier cite le dépôt GitHub de l'auteur pour le code
David Roberts
2019-08-08 12:26:07 UTC
view on stackexchange narkive permalink

Mon co-auteur et moi avons écrit un article et le projet impliquait la création d'une (petite) bibliothèque de logiciels. Une partie de la nouveauté du papier est la sortie du code, qui est un objet numérique non destiné à une manipulation manuelle. Le code (open source) serait idéalement également utile pour les autres. Un journal auquel j'envisageais de soumettre cela nécessite un examen par les pairs en double aveugle, mais le dépôt GitHub où le code est stocké, référencé dans l'article, identifie l'un de nous simplement en regardant le nom d'utilisateur dans l'URL. Nous pouvons bien sûr obscurcir nos identités dans l'article en tant qu'auteurs, mais nous devons vraiment citer le référentiel de code.

Je n'ai jamais eu à faire de revue en double aveugle auparavant, et ce que nous devrions faire n'est donc pas clair. Mon co-auteur va se heurter à d'autres problèmes de ce type alors qu'il poursuit ses recherches avec un mélange similaire de code et de papier en sortie.

Y a-t-il quelque chose que nous pouvons faire, au moins comme première apaiser les soucis des journaux?

Est-ce quelque chose que vous * soupçonnez * sera un problème, ou est-ce * déjà * un problème (par exemple, les éditeurs ont refusé votre article)?Dans le premier cas, je suggère de ne pas s'inquiéter.Mon impression avec la révision en double aveugle est qu'elle fonctionne sur le «code des honneurs»;le voile de l'anonymat des auteurs est facilement brisé et les éditeurs en sont bien conscients.L'intérêt du double-aveugle est d'éviter de frotter les identités des auteurs sur le visage des arbitres, de ne pas exclure complètement la possibilité qu'ils les découvrent.
@darijgrinberg En écrivant, "Notre code est disponible sur GitHub:` https: // github.com / AuthorName`, "semble" frotter les identités des auteurs dans les visages des arbitres_, en notant _le dépôt GitHub ... identifie l'un de nous [par] le nom d'utilisateur dans l'url_.
@user2768: Habituellement, les arbitres ne recherchent pas de telles citations avant d'avoir déjà lu une grande partie du journal.Même ainsi, les raccourcisseurs de liens peuvent aider (assurez-vous simplement de les supprimer avant la version finale).
Les raccourcisseurs de lien @darijgrinberg ne doivent ** jamais ** être inclus dans un manuscrit soumis, car ils permettent à l'auteur de savoir qui accède à la ressource liée.Si l'auteur peut voir dans ses journaux que quelqu'un du réseau de l'Université technique de Sikinia a cliqué sur son lien, il est facile de deviner qui est l'arbitre.
@FedericoPoloni: Bon point !!Meilleure solution: [Zenodo] (https://zenodo.org/) héberge des instantanés des dépôts GitHub, et ils sont accessibles par des identifiants qui n'incluent pas le nom de l'auteur (du moins pas visiblement);c'est peut-être la bonne chose à faire (pour des raisons de préservation à long terme également).
Pertinent (et peut-être un doublon?): [Comment anonymiser l'auto-citation du référentiel de code source dans l'examen par les pairs IEEE en double aveugle?] (Https://academia.stackexchange.com/q/63527/17254)
@Abigail: Voir mon commentaire sur l'OP.Rendre votre paternité complètement non identifiable aux frontières de l'impossible (la plupart du temps, vos arbitres feront partie des 50 personnes qui étudient votre petit sous-sujet, et ils pourront faire des suppositions éclairées sur qui vous êtes en fonction de votre visibilitéintérêts, parcours et style d'écriture);le mieux que vous puissiez espérer est que les arbitres n'y soient pas confrontés s'ils n'essaient pas délibérément de le faire.
Je trouve étrange que le Journal demande un examen en double aveugle, alors qu'il ne serait pas censé autoriser certains remplacements temporaires de citations pour garantir qu'il est effectivement aveugle.
Une variante intéressante: le référentiel est public dès le premier jour. Au moment où l'article est finalement soumis, le logiciel est peut-être déjà largement connu dans le sous-champ, et la révision en double aveugle est impossible.Je vois beaucoup cela en bioinformatique.
Pour moi, le commentaire d'@darijgrinberg's est la meilleure réponse, et je voterais pour s'il apparaissait comme tel.Fournir un instantané séparé ne fonctionne pas: si je révisais le code dans un dépôt, c'est l'historique que je regarderais autant que le code lui-même.De plus, au moment où un lecteur tombe sur un URI github dans le papier, il est probablement déjà arrivé à des conclusions provisoires d'acceptation / de révision / de rejet.Si vous vous trouvez dans un domaine avec des animosités si intenses qu'il est en quelque sorte vital d'aveugler l'auteur, alors vous devriez peut-être parler à l'éditeur des arbitres que vous aimeriez qu'ils évitent.
@NormanGray quel commentaire précisément?Je pense qu'il s'agit davantage d'une mesure de réduction des biais qu'une mesure de protection de l'auteur étant donné la revue en question.
@DavidRoberts Ah, bon point!C'était celui du `` code d'honneur '', suggérant que le but de l'aveuglement est de _abaisser_ les chances d'identifier l'auteur par inadvertance (pour une raison quelconque), plutôt que d'effacer la possibilité, par des actions qui créent des frictions sans vraiment fonctionner complètement - des solutions peu maniables.à quelque chose qui peut ne pas être un problème majeur.Je ne suis pas d'accord à 100% avec cela, mais je pense que cela se rapproche davantage du véritable cœur du problème que les réponses techniques existantes.
Cinq réponses:
Federico Poloni
2019-08-08 12:33:23 UTC
view on stackexchange narkive permalink

Censurer le nom du dépôt et fournir le code aux arbitres sous forme de fichier auxiliaire.

Si les arbitres le souhaitent, il est facile de contourner l'obfuscation: prenez n'importe quelle partie non triviale du code (un nom de fonction expressif ou un commentaire suffit) et déposez-la dans Google.
@NichtJens à l'ère d'arxiv, cela fonctionne souvent avec les titres papier aussi, et c'est ok.Les auteurs ont juste la responsabilité de permettre à l'examinateur de procéder en double aveugle.
OK, je vois ce que tu veux dire.L'équivalent du référentiel cité serait de mentionner la pré-impression dans la soumission (par exemple "Une pré-impression de ce document est disponible sous le nom arxiv: 1234.12345.").
@NichtJens encore pire, car le numéro arXiv n'inclut pas le nom d'un auteur.
FWIW, je l'utilise régulièrement pour créer une copie d'un dépôt Git sans historique à ../repo-name-copy à partir de ce dépôt: `git -C" $ (git rev-parse --show-toplevel) "checkout-index --all --prefix = "../$ (basename" $ (git rev-parse --show-toplevel) ") - copy /" `.Vous pouvez également utiliser `grep -r -e 'Nom de l'auteur' -e 'Autre nom de l'auteur' dans le répertoire résultant, et faire quelque chose comme` sed -i 's / Jane Doe / Auteur 1 / g; s / JoeBloggs / Author 2 / g 'PATH' pour remplacer les noms.
@l0b0 Normalement, j'utiliserais `git archive HEAD> filename.zip` au lieu de votre commande compliquée --- quel est l'avantage de cette méthode?
@FedericoPoloni `git rev-parse --show-toplevel` vous donne le répertoire de niveau supérieur du référentiel, donc cette commande fonctionnera lorsqu'elle est exécutée n'importe où dans le référentiel.Autre que cela, je suppose que cela dépend si vous voulez une copie de la structure du répertoire ou une archive.
@Federico Personnellement, je récupère simplement le référentiel sous la forme que je veux qu'il soit, puis je supprime le dossier .git, mais il est bon de savoir qu'il existe une commande pour cela aussi;) (comment l'archive traite-t-elle les sous-modules par exemple?)
@Voo Aucune idée --- je ne suis pas un gourou moi-même.
user2768
2019-08-08 13:19:54 UTC
view on stackexchange narkive permalink

  • Rendre une copie du référentiel disponible sur une URL anonyme, par exemple en utilisant Google Drive avec un nouveau compte.

  • Envoyez une copie du dépôt avec votre manuscrit (si autorisé par la revue), ou envoyez le dépôt à l'éditeur par e-mail.

Si les arbitres le souhaitent, il est facile de contourner l'obfuscation: prenez n'importe quelle partie non triviale du code (un nom de fonction expressif ou un commentaire suffit) et déposez-la dans google.
@NichtJens De même, l'arbitre peut déposer une phrase ou deux (du papier) dans Google et trouver la pré-impression.Comme indiqué dans un autre commentaire, _le voile de l'anonymat des auteurs est facilement brisé et les éditeurs en sont bien conscients_.
Exactement!Ne serait-ce pas également un problème pour les avis en double aveugle?EDIT: Apparemment, c'est: https://statmodeling.stat.columbia.edu/2018/01/15/hey-heres-new-reason-journal-reject-paper-annoying-already-preprint-server/
@NichtJens Le but de l'examen en double aveugle par les pairs n'est pas de rendre impossible pour les gens de supprimer l'aveuglement, mais de le rendre plus difficile sans un effort de la part des critiques ou des auteurs.Aucun système n'est parfait, et le système doit fonctionner avec une hypothèse minimale de comportement éthique de la part des examinateurs, y compris ne pas se démener pour trouver délibérément qui sont les auteurs.
OK, je vois ce que tu veux dire.Merci de clarifier.
@NichtJens en tant que critique, le système est plus pour que je puisse * éviter * d'être involontairement biaisé - je n'essaierai pas de rechercher les auteurs, car je m'en fiche, cependant, si je verrais un nom que je reconnaissur le papier ou dans l'url de github, je ne peux rien faire pour ne pas le voir.
@Abigail Eh bien, le journal des modifications ** pourrait ** être [obscurci] (https://stackoverflow.com/questions/3463854/how-do-i-remove-an-author-from-a-git-repository) facilement... C'est ce qui a déjà été proposé ici.
anjama
2019-08-08 23:09:47 UTC
view on stackexchange narkive permalink

Je suis littéralement dans la même situation que vous en ce moment et je suis tombé sur ce référentiel / service sur GitHub il y a quelques jours:. Étant donné que votre code et vos noms sont déjà publics, il ne fournit qu'un niveau d'obfuscation de base. Cependant, tant que les critiques sont honnêtes et n'essaient pas activement de trouver les noms des auteurs, cela devrait les empêcher de découvrir accidentellement qui vous êtes.

Au-delà de cela, l'approche la plus efficace est de ne pas le publier publiquement avant d'avoir été révisé, mais plutôt de fournir le code / la documentation / quoi que ce soit en privé via le journal. Ma préoccupation avec cette approche est qu'elle dépend de la suppression de toute association de nom du matériel. Alors, que se passe-t-il si un critique rejette le manuscrit, puis publie le code ou des parties de celui-ci comme leur propre avant vous? L'absence de dossier public de votre part pourrait vous compliquer la tâche.

En fin de compte, vous ne pouvez pas faire grand-chose à propos des critiques qui tentent intentionnellement de contourner l'anonymat. Même sans votre nom nulle part, si vous avez déjà publié, quelqu'un pourrait potentiellement avoir une assez bonne idée de qui vous êtes grâce au contenu et aux modèles du manuscrit lui-même.

"L'approche la plus efficace consiste à ne le publier publiquement qu'après examen," <- trop tard
@DavidRoberts j'ai vu.J'ai inclus ce deuxième paragraphe plus pour quiconque pourrait tomber sur cette question à l'avenir
Si les auteurs ont accès, par des moyens distincts, à une copie anonyme du code, pourquoi devrait-on également éviter une publication publique du code?
@CurtJ.Sampson Si les réviseurs ont besoin de faire une recherche sur le Web pour un terme ou un concept dans l'article, la documentation du référentiel pourrait y mettre les résultats de la recherche, surtout s'il s'agit d'un domaine de recherche spécialisé.Alternativement, un réviseur voudra peut-être voir quels autres travaux ont été effectués et s'assurer que l'article les cite correctement.Enfin, un réviseur peut rechercher le code lui-même pour s'assurer que quelqu'un d'autre n'a pas publié le code (pour s'assurer qu'il s'agit d'un travail original, et non d'un code plagié / violant un droit d'auteur)
Avoir à la fois un enregistrement de soumission, ainsi que placer le code dans un référentiel git public (même si le code n'est pas * encore * public), préserve idéalement le timing des auteurs.Il est possible de définir arbitrairement des horodatages dans git, mais le référentiel public doit avoir sa propre comptabilité pour le référentiel.De plus, on peut rendre public uniquement le dernier ou une série de hachages de validation ou une autre somme de contrôle de la base de code.
user2258552
2019-08-09 05:21:26 UTC
view on stackexchange narkive permalink

La chose la plus simple à faire (ce qui, je suis surpris, n'ait pas été suggérée auparavant, et est raisonnablement courante) est de créer un compte GitHub anonyme et d'y dupliquer votre code (téléchargez le code en un seul commit, ne dupliquez pas le référentiel lui-même car vous ne voulez pas que votre vrai nom d'utilisateur soit présent dans l'historique des commit).

beatngu13
2020-01-28 01:08:32 UTC
view on stackexchange narkive permalink

Il existe Anonymous GitHub, un serveur proxy pour prendre en charge la navigation anonyme dans les dépôts Github:

https://anonymous.4open.science/

Utilisation:

  1. Remplissez l'URL du dépôt Github.
  2. Complétez la liste des termes qui seront anonymisés. L'anonymisation du contenu se fait en remplaçant toutes les occurrences de mots dans une liste par "XXX". La liste de mots contient généralement le nom de l'institution, les noms des auteurs, les identifiants, etc.
  3. Définissez si vous souhaitez une date d'expiration pour votre référentiel anonyme. Vous pouvez le conserver indéfiniment, supprimer le référentiel après une date spécifique ou rediriger l'utilisateur vers le référentiel GitHub.

En conséquence, une URL unique est créée avec le contenu de votre référentiel, pour exemple, http://anonymous.4open.science/repository/840c8c57-3c32-451e-bf12-0e20be300389/.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...