Anonimowe pakiety R na CRAN lub Github do załączonych ślepych recenzji recenzowanych przesłanych manuskryptów

Question

Czy istnieje sposób na anonimowe udostępnianie pakietu R, który będzie działać na systemach Unix, Mac i/lub Windows (najlepiej wszystkie 3 i z łatwością mając go na CRAN)?

Posiadanie pakietu R na CRAN, aby można było powielać analizy i demonstrować metodykę, a udostępnianie może znacznie przyspieszyć przegląd manuskryptu przesłanego do czasopisma naukowego/statystycznego (według mnie i doświadczenia).

Jeśli ten dziennik wymaga niewidocznych recenzji, w jaki sposób mogę udostępnić pakiet R w sposób, który powoduje, że opinia jest zaślepiona (tradycyjnie plik DESCRIPTION zawiera moje imię i nazwisko oraz adres e-mail, który odsłania recenzję)?

myślałem z poniższych opcji, z których wszystkie mają wady:

1. przejść przez cały proces składania CRAN z pseudonimem (fałszywego imienia i wyrzucenie konta e-mail) bez stosowania GitHub (moja nazwa użytkownika github jest mój nazwisko). Po odtajnieniu recenzji/zaakceptowaniu papieru zmień informacje o wyrzucaniu na poprawne informacje. Nie mam pewności co do tej etykiety lub tego, w jaki sposób polityka CRAN mogłaby uznać tę praktykę.
2. Zapakuj pakiet R bez udziału CRAN lub Github i ufaj, że recenzent jest zainteresowany i zdolny do zainstalowania go ze źródła na systemie UNIX. Istnieje duża różnica między tym, a możliwością pisania install.packages() i library() w systemie, który zna recenzent, a ręczne tworzenie zipów na wszystkich platformach jest nużące.
3. Nie rób paczki, po prostu wyślij fragmenty kodu i dane i podaj w manuskrypcie pakiet R nadchodzący (co jest słabszym stwierdzeniem niż "tutaj jest pakiet R, który jest już na CRAN", kolejną wadą jest to, że wymienione w pozycji 2).

Wspominałem o CRAN i Githubie, ponieważ najlepiej znam te transakcje. Jestem otwarty na inne rozwiązania.

Answer 1

Nie ma potrzeby w ogóle mieć pakiet na CRAN, i tam żaden sposób złożyć pakiety anonimowo CRAN. Takie zgłoszenie byłoby dużym problemem dla CRAN pod względem łatwości konserwacji. CRAN nie jest po prostu odpowiednią platformą do tego.

Github ma podobne problemy, ale zasadniczo można utworzyć osobne konto Github bez podawania informacji identyfikujących.

Jednak to tylko rozwiązuje większy problem: jak naprawdę nie można zidentyfikować kodu? Ogólniej rzecz biorąc, cała idea podwójnie zaślepionej oceny partnerskiej jest nękana problemami identyfikowalności badań. Nie sądzę, że istnieje dobre rozwiązanie (szczególnie obejmujące przegląd kodu, ale nawet ogólnie), w którym badania są anonimowe. W związku z tym nie uważam, że warto wydawać energię, próbując uczynić anonimowe zgłoszenie kodu, ze szkodą dla jakości oprogramowania (konserwacji).

W przypadkach, w których pożądana jest anonimowa wzajemna anonimowa analiza, obecnie najlepszą opcją jest przesłanie kodu do usługi umożliwiającej anonimowe archiwizowanie, takiej jak Figshare lub przesłanie archiwum jako materiału uzupełniającego do dziennika.Nie należy oczekiwać, że recenzent wykona prosty proces, aby wykonać prostą próbę wykonania prostego kodu. W przeciwnym razie mogą nie być kwalifikowani do sprawdzenia kodu.

---

W rzeczywistości nie jest to nawet wskazane (wręcz przeciwnie, uważam, że zaśmiecania skrzyni ko zupełnie przeciwny skutek, choć „CRAN” ma „niepełna” w nazwie, idealnie całej jego zawartości powinny być w formie odpowiednio użytecznych pakietów, innymi słowy: jakość, a nie ilość).