Domanda:
Revisione tra pari in doppio cieco quando il documento cita il repository GitHub dell'autore per il codice
David Roberts
2019-08-08 12:26:07 UTC
view on stackexchange narkive permalink

Io e il mio coautore abbiamo scritto un articolo e il progetto prevedeva la creazione di una (piccola) libreria software. Parte della novità del documento è l'output del codice, che è un oggetto digitale non destinato alla manipolazione manuale. Il codice (open source) sarebbe idealmente utile anche per gli altri. Un giornale a cui stavo pensando di inviarlo richiede una revisione tra pari in doppio cieco, ma il repository GitHub in cui è memorizzato il codice, a cui si fa riferimento nel documento, identifica uno di noi semplicemente guardando il nome utente nell'URL. Ovviamente possiamo oscurare la nostra identità nel documento come autori, ma abbiamo davvero bisogno di citare il repository di codice.

Non ho mai dovuto fare una revisione in doppio cieco prima, quindi non è chiaro cosa dovremmo fare. Il mio coautore si imbatterà in più problemi di questo tipo mentre continuano la ricerca con un simile mix di codice e carta come output.

C'è qualcosa che possiamo fare, almeno come primo tentativo di lenire le preoccupazioni dei giornali?

È qualcosa che * sospetti * sarà un problema, o è * già * un problema (ad esempio, gli editori hanno rifiutato il tuo articolo)?Nel primo caso, suggerisco di non preoccuparti.La mia impressione con la revisione in doppio cieco è che operi sul "codice di riconoscimento";il velo dell'anonimato dell'autore è facilmente spezzato e gli editori lo sanno bene.Lo scopo del doppio cieco è evitare di sfregare le identità degli autori sui volti degli arbitri, per non escludere completamente la possibilità che loro le scoprano.
@darijgrinberg Scrivendo, "Il nostro codice è disponibile su GitHub:` https: // github.com / AuthorName`, "sembra come _rubare le identità degli autori nelle facce degli arbitri_, notando _il repository GitHub ... identifica uno di noi [da] il nome utente in url_.
@user2768: Di solito, gli arbitri non cercano tali citazioni finché non hanno già letto gran parte dell'articolo.Anche così, gli abbreviazioni di link possono aiutare (assicurati solo di rimuoverli prima della versione finale).
Gli abbreviazioni di link @darijgrinberg non dovrebbero ** mai ** essere inclusi in un manoscritto inviato, perché consentono all'autore di tenere traccia di chi accede alla risorsa collegata.Se l'autore può vedere nei propri registri che qualcuno della rete dell'Università Tecnica di Sikinia ha cliccato sul suo link, è facile indovinare chi sia l'arbitro.
@FedericoPoloni: Buon punto !!Soluzione migliore: [Zenodo] (https://zenodo.org/) ospita istantanee di repository GitHub e sono accessibili tramite ID che non includono il nome dell'autore (almeno in modo non visibile);quindi potrebbe essere la cosa giusta da fare (anche per ragioni di conservazione a lungo termine).
Rilevante (e forse un duplicato?): [Come rendere anonima l'autocitazione del repository del codice sorgente nella revisione tra pari in doppio cieco IEEE?] (Https://academia.stackexchange.com/q/63527/17254)
@Abigail: Vedi il mio commento all'OP.Rendere la tua paternità completamente non identificabile confina con l'impossibile (il più delle volte, i tuoi arbitri apparterranno alle 50 persone che studiano il tuo piccolo sottoargomento e saranno in grado di fare ipotesi plausibili su chi sei in base al tuo visibileinteressi, background e stile di scrittura);il meglio che puoi sperare è che gli arbitri non si confrontino con esso se non ci provano deliberatamente.
Trovo strano che il Journal richieda una revisione in doppio cieco ma presumibilmente non consentirebbe alcune sostituzioni temporanee delle citazioni per garantire che sia effettivamente cieco.
Una variante interessante: il repository è pubblico dal primo giorno. Quando il documento viene finalmente inviato, il software potrebbe essere già ampiamente conosciuto nel sottocampo e la revisione in doppio cieco è impossibile.Lo vedo molto nella bioinformatica.
Per me, il commento di @darijgrinberg's è la risposta migliore e lo voterei se apparisse come tale.Fornire un'istantanea separata non funziona: se stavo rivedendo il codice in un repository, è la cronologia che guarderei tanto quanto il codice stesso.Inoltre, quando un lettore si imbatte in un URI GitHub all'interno del documento, probabilmente è già giunto a conclusioni provvisorie di accettazione / revisione / rifiuto.Se ti trovi in un campo con animosità così intense che accecare l'autore è in qualche modo vitale, allora dovresti forse parlare con l'editore di quali arbitri vorresti che evitassero.
@NormanGray quale commento precisamente?Penso che questa sia più una misura di riduzione dei pregiudizi che una misura di protezione dell'autore data la rivista in questione.
@DavidRoberts Ah, buon punto!Era il `` codice d'onore '', suggerendo che l'obiettivo dell'accecamento è quello di ridurre le possibilità di identificare inavvertitamente l'autore (per qualsiasi motivo), piuttosto che cancellare la possibilità, attraverso azioni che creano attrito senza effettivamente funzionare completamente - soluzioni ingombrantia qualcosa che potrebbe non essere un grosso problema.Non sono d'accordo al 100% con questo, ma penso che si avvicini al vero cuore del problema rispetto alle risposte tecniche esistenti.
Cinque risposte:
Federico Poloni
2019-08-08 12:33:23 UTC
view on stackexchange narkive permalink

Censura il nome del repository e fornisci il codice agli arbitri come file ausiliario.

Se gli arbitri lo vogliono, questo è un offuscamento facilmente aggirabile: prendi qualsiasi parte non banale del codice (un nome di funzione espressivo o un commento è sufficiente) e rilascialo in google.
@NichtJens nell'era di arxiv, questo spesso funziona anche con i titoli cartacei, ed è ok.Gli autori hanno solo la responsabilità di consentire al revisore di procedere in doppio cieco.
OK, capisco cosa intendi.L'equivalente del repo citato sarebbe menzionare la pre-stampa nella presentazione (ad esempio "Una pre-stampa di questo documento è disponibile come arxiv: 1234.12345.").
@NichtJens anche peggio, perché il numero arXiv non include il nome dell'autore.
FWIW, lo uso regolarmente per creare una copia di un repository Git senza alcuna cronologia su ../repo-name-copy dall'interno di quel repository: `git -C" $ (git rev-parse --show-toplevel) "checkout-index --all --prefix = "../$ (basename" $ (git rev-parse --show-toplevel) ") - copy /" `.Potresti anche voler `grep -r -e 'Author Name' -e 'Other Author Name' 'nella directory risultante, e fare qualcosa come` sed -i' s / Jane Doe / Author 1 / g; s / JoeBloggs / Author 2 / g "PATH" per sostituire i nomi.
@l0b0 Normalmente userei `git archive HEAD> filename.zip` invece del tuo complicato comando --- qual è il vantaggio di questo metodo?
@FedericoPoloni `git rev-parse --show-toplevel` ti dà la directory di primo livello del repository, quindi questo comando funzionerà se eseguito ovunque all'interno del repository.Oltre a questo, immagino che dipenda dal fatto che tu voglia una copia della struttura della directory o un archivio.
@Federico Personalmente devo semplicemente controllare il repository nella forma che voglio che sia e quindi eliminare la cartella .git, ma è bene sapere che c'è un comando anche per quello;) (come fa l'archivio a gestire i sottomoduli, ad esempio?)
@Voo Nessuna idea --- Non sono un guru git me stesso.
user2768
2019-08-08 13:19:54 UTC
view on stackexchange narkive permalink

  • Rendi disponibile una copia del repository a un URL anonimo, ad esempio utilizzando Google Drive con un nuovo account.

  • Invia una copia del repository con il tuo manoscritto (se consentito dalla rivista), in alternativa, invia il repository all'editore tramite e-mail.

Se gli arbitri vogliono, questo è un offuscamento facilmente aggirabile: prendi qualsiasi parte non banale del codice (un nome di funzione espressivo o un commento è sufficiente) e rilascialo in google.
@NichtJens Allo stesso modo, l'arbitro può inserire una o due frasi (dal foglio) in Google e trovare il prestampa.Come notato in un altro commento, _il velo dell'anonimato dell'autore si spezza facilmente e gli editori lo sanno bene_.
Esattamente!Non sarebbe un problema anche per le revisioni in doppio cieco?EDIT: Apparentemente lo è: https://statmodeling.stat.columbia.edu/2018/01/15/hey-heres-new-reason-journal-reject-paper-annoying-already-preprint-server/
@NichtJens Lo scopo della revisione tra pari in doppio cieco non è di rendere impossibile alle persone eliminare l'accecamento, ma di renderlo più difficile senza alcuno sforzo da parte dei revisori o degli autori.Nessun sistema è perfetto, e il sistema ha bisogno di funzionare con una minima assunzione di comportamento etico da parte dei revisori, incluso il non fare di tutto per scoprire deliberatamente chi sono gli autori.
OK, capisco cosa intendi.Grazie per il chiarimento.
@NichtJens come revisore, il sistema è più così che posso * evitare * di essere involontariamente di parte - non cercherò di cercare gli autori, perché non mi interessa, tuttavia, se vedo un nome che riconoscoin cima al foglio o nell'URL di GitHub, non posso fare nulla per non vederlo.
@Abigail Bene, il registro delle modifiche ** potrebbe ** essere [offuscato] (https://stackoverflow.com/questions/3463854/how-do-i-remove-an-author-from-a-git-repository) facilmente... È quello che è stato già proposto qui.
anjama
2019-08-08 23:09:47 UTC
view on stackexchange narkive permalink

Sono letteralmente nella tua stessa situazione in questo momento e mi sono imbattuto in questo repository / servizio su GitHub pochi giorni fa:. Poiché il codice e i nomi sono già pubblici, fornisce solo un livello base di offuscamento. Tuttavia, fintanto che i revisori sono onesti e non cercano attivamente di scoprire i nomi degli autori, allora dovrebbe impedire loro di scoprire accidentalmente chi sei.

Oltre a ciò, l'approccio più efficace non è rilasciarlo pubblicamente fino a dopo la revisione, e invece fornire il codice / documentazione / qualsiasi cosa privatamente attraverso il giornale. La mia preoccupazione con questo approccio è che dipende dalla rimozione di qualsiasi associazione di nomi dal materiale. Quindi cosa succede se un revisore rifiuta il manoscritto, quindi pubblica il codice o parti di esso come proprio prima di te? La mancanza di un record pubblico da parte tua potrebbe rendere un po 'un mal di testa da risolvere.

In definitiva, non c'è molto che puoi fare con i revisori che cercano intenzionalmente di aggirare l'anonimato. Anche senza il tuo nome da nessuna parte, se hai pubblicato prima, qualcuno potrebbe ancora avere un'idea abbastanza chiara di chi sei attraverso il contenuto e gli schemi nel manoscritto stesso.

"l'approccio più efficace non è rilasciarlo pubblicamente fino a dopo la revisione", <- troppo tardi
@DavidRoberts ho visto.Ho incluso quel secondo paragrafo più per chiunque potrebbe inciampare su questa domanda in futuro
Se agli autori viene concesso, anche se con mezzi separati, l'accesso a una copia anonima del codice, perché dovrebbe essere evitata anche una pubblicazione pubblica del codice?
@CurtJ.Sampson Se i revisori devono fare una ricerca sul web per un termine o un concetto nel documento, la documentazione nel repository potrebbe inserire i risultati della ricerca, specialmente se si tratta di un'area di ricerca specializzata.In alternativa, un revisore potrebbe voler vedere quale altro lavoro è stato fatto e assicurarsi che il documento lo citi correttamente.Infine, un revisore potrebbe cercare il codice stesso per assicurarsi che qualcun altro non abbia pubblicato il codice (per assicurarsi che si tratti di lavoro originale e non di codice plagiato / che viola un copyright)
Avere sia una registrazione dell'invio, sia l'inserimento del codice in un repository git pubblico (anche se il codice non è * ancora * pubblico), preserva idealmente i tempi degli autori.È possibile impostare arbitrariamente i timestamp in git, ma il repository pubblico dovrebbe avere la propria contabilità per il repository.Inoltre, è possibile rendere pubblico solo l'ultimo o una serie di hash di commit o un altro checksum della base di codice.
user2258552
2019-08-09 05:21:26 UTC
view on stackexchange narkive permalink

La cosa più semplice da fare (che sono sorpreso non sia stata suggerita prima ed è ragionevolmente comune) è creare un account GitHub anonimo e duplicare lì il tuo codice (caricare il codice in un unico commit, non duplicare il repository stesso perché non vuoi che il tuo vero nome utente sia presente nella cronologia dei commit).

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

Esiste Anonymous GitHub, un server proxy per supportare la navigazione anonima dei repository Github:

https://anonymous.4open.science/

Utilizzo:

  1. Compila l'URL del repository Github.
  2. Completa l'elenco dei termini che verranno resi anonimi. L'anonimizzazione del contenuto viene eseguita sostituendo tutte le occorrenze di parole in un elenco con "XXX". L'elenco di parole in genere contiene il nome dell'istituto, i nomi degli autori, gli accessi, ecc.
  3. Definisci se desideri una data di scadenza per il tuo repository anonimo. Puoi tenerlo per sempre, rimuovere il repository dopo una data specifica o reindirizzare l'utente al repository GitHub.

Di conseguenza, viene creato un URL univoco con il contenuto del tuo repository, per esempio, http://anonymous.4open.science/repository/840c8c57-3c32-451e-bf12-0e20be300389/.



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...