Generell gilt beim Global Parkinson’s Genetics Program (GP2) der Grundsatz „keine Überraschungen“. Analysen, Projekte und Manuskripte werden offen und transparent untereinander koordiniert und kommuniziert. GP2 möchte, dass die Daten und der Code so weitreichend und frei wie möglich genutzt werden, und fordert eine Standardisierung des Codes in allen Analyseteams. Für alle GP2-Mitglieder und externen Nichtmitglieder, die Analysen mit GP2-Daten durchführen, betont GP2 die Notwendigkeit eines sauberen, organisierten und replizierbaren Codes, welcher der wissenschaftlichen Gemeinschaft frei zugänglich ist. Der Code muss den Standardisierungsleitlinien entsprechen, GP2 ist zu nennen und der Code wird der Gemeinschaft über GitHub zur Verfügung gestellt.

Einführung

Das Global Parkinson’s Genetics Program (GP2) ist ein internationales Vorhaben zur Erlangung signifikanter Erkenntnisse hinsichtlich der genetischen Grundlagen der Parkinson-Krankheit und zur Demokratisierung des Zugangs zu den entsprechenden Ergebnissen und Daten. GP2 wird durch die Initiative „Aligning Science Across Parkinson’s“ (ASAP, https://gp2.org/) finanziert und gliedert sich in die strategische Zielsetzung dieses Programms ein, um Zusammenarbeit zu fördern, Ressourcen zu generieren und Daten zu demokratisieren. Die Verbreitung von GP2-Code und -Daten gehört zu den wichtigsten Zielen von GP2, und ASAP unterstützt die weitreichende, schnelle und freie Veröffentlichung von Ergebnissen. 

Übersicht 

Durch diese Richtlinien soll gewährleistet werden, dass: 

1. GP2-Code und -Arbeitsschritte von unter Leitung des GP2-Forschungsverbundes durchgeführten Analysen werden vollumfänglich, korrekt und unverzüglich veröffentlicht.

2. GP2-Code und -Arbeitsschritte von unter Leitung des GP2-Forschungsverbundes durchgeführten Analysen sind standardisiert, organisiert und öffentlich auf GitHub verfügbar.

Die Code-Standardisierungsleitlinien ergänzen die Veröffentlichungsrichtlinien von GP2. Bezüglich der Klärung ungewöhnlicher Situationen durch den GP2-Forschungsverbund verweisen Sie bitte auf dieses Dokument. 

Die Code-Standardisierungsrichtlinien beschreiben das Erfolgsmodell für die Standardisierung von Codes, welches für die vom GP2-Steuerungskomitee und dem GP2-Forschungsverbund geleiteten Analysen übernommen wird und die vom GP2-Forschungsverbund geleiteten Publikationen ergänzt. Externen Forscher*innen, die GP2-Daten verwenden, wird dringend nahegelegt, diese Methoden ebenfalls anzuwenden, um hochkarätige Analysen und Open Science, also frei zugängliche Forschungsergebnisse, zu gewährleisten. Da sich Python/Jupyter anstelle von R für Analysen in unserem Bereich immer mehr durchsetzen, liegt auch in diesem Dokument der Schwerpunkt auf Python. Uns ist bewusst, dass viele GP2-Forscher*innen nach wie vor mit R oder anderen Tools arbeiten, und wir unterstützen auch weiterhin einen organisierten, frei zugänglichen und replizierbaren Code innerhalb der GP2-Gemeinschaft. 

Als weitere Motivation bedenken Sie bitte, dass das Bereinigen des Codes zwar mühsam ist, aber so wird GP2 seinen Code einrichten, und Sie sind aufgefordert, diese Standards ebenfalls zu befolgen. Ist der Code nicht sauber/klar und aus sich selbst heraus verständlich, stellt sich die Frage, ob er wirklich die gewünschte Funktion erfüllt. Sauberer Code bedeutet auch, dass später weniger Zeit aufgewendet werden muss, um Analysen und Konzepte wieder und wieder zu erklären – ein Gewinn für beide Seiten. Ein sauberer Code ermöglicht Replizierbarkeit und Transparenz. GP2 ist dem Gedanken der Open Science (frei zugängliche Wissenschaft), der Zusammenarbeit durch Transparenz des Codes und der Inklusivität verpflichtet.

Im Folgenden beschreiben wir einige grundlegende Informationen und Arbeitsabläufe in Bezug auf Python als primäre Programmiersprache, Anaconda als bevorzugte Python-Distribution, PEP8 als zu verwendende Python-Programmierstruktur, die Speicherung in der Google-Cloud-Umgebung und die Durchführung von Analysen in der Cloud-Umgebung von Terra. Wichtig ist es ferner, für jede Analyse ein so genanntes README-Dokument mit einer übersichtlichen Darstellung von Arbeitsabläufen und Zielsetzungen zu haben. Nach diesen Standards arbeitet GP2 und hofft, dass sie auch in der Wissenschaftsgemeinde generell eingehalten werden.

Zunächst einige grundsätzliche Anmerkungen zu Python und zum Programmieren im Allgemeinen.

1. Sämtliche computergestützten Analysen für GP2 erfolgen zumeist in Terra, The AnVIL von NHGRI oder ähnlichen cloud-basierten Systemen.

a. Für Projekte oder Gruppen mit begrenzten logistischen bzw. finanziellen Möglichkeiten bieten wir analytische und finanzielle Unterstützung.

2. Python3+ ist für GP2-Analysen die Haupt-Programmiersprache, für R und andere Programmiersprachen gibt es in begrenztem Umfang ebenfalls Unterstützung. Dadurch kann der aktuelle Code-Bestand der LNG Data Science Group des National Institute on Aging besser genutzt werden.

3. Um das Arbeiten mit Terra zu lernen, richten Sie sich ein AMP-PD-Konto ein. Das bietet einen guten Einstieg.

a. Dort gibt es hervorragende „Getting-Started“-Notizbücher (wo man programmieren und den Code ausführen kann) sowie Arbeitsbereiche und eine Menge Daten, die man nutzen kann. b. Die „Getting-Started“-Dokumente auf Terra.bio sind auch sehr gut.

4. Um Phyton innerhalb von zwei Wochen wirklich gut zu lernen …

a. Gehen Sie dies einmal täglich durch.

b. Gehen Sie dies einmal pro Woche durch (von unseren Freunden bei der NSA über FOIA).

c. Google Colabs bietet auch eine übersichtliche und stressfreie Umgebung, um sich die Notizbuchstruktur zu erschließen und mit Python vertraut zu machen.

5. Ein guter Code ist einfach, klar und verwendet eine standardisierte Grammatik – gewissermaßen wie ein Rezept.

a. Google Style Guides sind ein guter Ausgangspunkt.

b. PEP8 ist die bevorzugte „Grammatik“ für Python.

c. Visual Studio Code ist bei GP2 der bevorzugte Editor, da es dort Erweiterungen gibt, um den Programmierstil zu standardisieren. Arbeiten Sie aber einfach mit dem Editor, mit dem Sie sich am wohlsten fühlen.

6. Die Hauptsprache des Support-Teams ist Python3. Wenn Sie die gleichen Tools verwenden wie wir, können wir sowohl Tools mit Ihnen teilen als auch Ihre Projekte viel effizienter unterstützen.

a. Alle internen Bausteine für Tools und Programmierung sind in Python3.

b. Gemeinsam genutzte GP2-Ressourcen sind für die große Mehrheit der Projekte in Python3.

Anaconda/Python für die lokale Nutzung herunterladen 

1. Wenn man lokal in Python programmiert, ist es wichtig, mit der Anaconda-Distribution zu arbeiten, um eine vollwertige Python3-Umgebung sicherzustellen. LNG hat eine Anleitung zur Einrichtung von Anaconda zusammengestellt. Das Dokument finden Sie hier.

Wichtigste Punkte und Übersicht

1. Sie müssen über eine Methode zur Versionskontrolle verfügen, um Programmierunfälle zu vermeiden. Man kann sich das wie eine Art elektronisches Laborbuch vorstellen. Das GP2-Projektlabor hat seinen eigenen GitHub für vorwärtsgerichtete Pipelines. Hier ist getreu dem GP2-Motto alles öffentlich zugänglich.

a. Wenn etwas noch nicht bereit für die Öffentlichkeit ist, ist das auch in Ordnung! Erstellen Sie ein privates Repository und wenn der Code vollständig ist, haben Sie die Möglichkeit, ihn an einen öffentlichen Ort zu verschieben.

b. Bei GitHub sind Versionskontrolle und Zusammenarbeit sehr einfach, besonders mit der neuen Desktop-Oberfläche. Weiterführende Dokumentation zur Einführung findet sich hier.

2. Es ist unerlässlich, eine README-Datei zu erstellen. Über unsere READMEs kommunizieren wir nicht nur mit anderen, sondern sie sind auch Dokumente, die ständig geändert werden. Folgende Informationen sind dort aber immer enthalten:

a. Autoren, Mitwirkende, Projektname, Projektzielsetzung, vorgeschlagene Arbeitsabläufe für Analysen, Startdatum, Datum der letzten Aktualisierung, Arbeitsverzeichnispfade, Dateipfade

b. Ein kostenloser und hervorragender Markdown-Editor zur Erstellung von README-Dateien ist stackedit.io

3. Das GP2-Analyseteam arbeitet gemeinsam in Google Colabs an experimentellen Proof-of-Concept-Codes, um die kostenlosen GPUs zu nutzen sowie bei Bedarf in der lokalen Jupyter-Umgebung Inhalte einfach teilen und ändern zu können.

4. Generell gilt, wenn eine Gruppe von mehr als 2 oder 3 Personen gemeinsam an einem Projekt arbeitet, wird eine Versionskontrolle benötigt.

5. Bevor ein Projekt bzw. Manuskript mit dem GP2-Netzwerk geteilt wird, ist eine Versionskontrolle und eine Art von transparenter und verständlicher Programmierressource erforderlich.

a. Dieser Code wird vor der Freigabe zur Veröffentlichung geprüft, wenn GP2-Ressourcen in Form analytischer oder finanzieller Unterstützung genutzt wurden.

Code organisieren

1. Eine Möglichkeit, wie man seinen Code organisieren kann, wird hier erklärt.

a. Auf dieser Seite wird behandelt, wie man Funktionen und Module erstellt oder anderweitig seinen Code gut gliedern kann.

b. Ihr Code muss sich nicht nach diesen Vorgaben richten, wenn Sie sich damit nicht wohlfühlen, aber er sollte in irgendeiner Form intuitiv nachvollziehbar organisiert sein.

c. Betrachten Sie Ihren Code als Teil Ihres Manuskripts. Wenn ein Gutachter Ihr Manuskript nicht versteht, wie soll es dann den Open-Science-Standards von GP2 standhalten? Das Gleiche gilt für den Code.

d. Zwar gibt es bei GP2 für die Programmierung keine starren Formatvorgaben, aber bemühen Sie sich bitte unbedingt, klar zu strukturieren.

Code-Standardisierung in Python

1. Wir befolgen so genau wie möglich (Python Enhancement Proposal) für das Programmieren in Python die PEP8-Standards. PEP8 ist ein Dokument, in dem beschrieben wird, wie man am besten in Python programmiert, um einen besser lesbaren und konsistenteren Code zu produzieren.

a. Umfangreiche, aber zugleich gut verständliche Informationen dazu finden sich hier.

b. Die meisten integrierten Entwicklungsumgebungen (IDEs) verfügen über ein Plugin, das die Einhaltung dieses Standards unterstützt.

i. Ein Beispiel hierfür ist das autopep8-Plugin von Visual Studio Code.

2. In Notebook-Dateien haben wir Vorlagen für Textbausteine, die wir verwenden, um uns selbst und die Nutzer*innen daran zu erinnern, welche Motivation hinter den Projekten steht. Beim Arbeiten mit Notizbüchern ist Markdown sehr nützlich, um Nutzer*innen Orientierung zu bieten und zu dokumentieren, was ausgeführt wurde.

a. Hier ist unsere aktuelle Textvorlage.

i. Man kann sie je nach Bedarf anpassen.

ii. Der allgemeine Rahmen sollte für einen Code im Zusammenhang mit Projekten verwendet werden, die direkte Unterstützung von GP2 erhalten. Das sorgt für Übersichtlichkeit und hilft bei der Fehlerbehebung.

Bewährte Praktiken beim Arbeiten mit Cloud-Plattformen

1. Als Teil von AMP-PD und wahrscheinlich auch für GP2 werden wir die PlattformTerra nutzen, um Analyse-Pipelines zu schreiben, zu optimieren und auszuführen.

a. Terra wurde durch das Broad Institute und das MIT entwickelt, setzt auf kommerzielle Cloud-Infrastruktur(en, Mehrfachoptionen) und bietet eine komplette interaktive Python3-Umgebung in Notebook-Struktur (die Jupyter sehr ähnelt).

i. Wenn man mit dem Cloud Computing nicht vertraut ist, bietet Google hier eine hervorragende Einführung in die Fachsprache mit Erläuterungen zentraler Begriffe wie Projekt, Bucket, Container und anderer wichtiger Ausdrücke, die man für die weitere Arbeit beherrschen sollte.

ii. Terra-spezifische Beispiele hat das AMP-PD-Team hier zusammengestellt.

iii. Einige Grundlagen zum Umgang mit Dateien in der Cloud-Infrastruktur finden sich in diesem praktischen Spickzettel.

iv. Die bewährten Praktiken von Google zur Benennung, Datenspeicherung und Datenverwaltung finden sich hier.

2. Es gibt 2 entscheidende Unterschiede zwischen der Ausführung von Analysen lokal oder in der Cloud.

a. Lokal zahlen Sie selbst für den Speicher (entweder auf dem eigenen Computer oder im Cluster einer Institution), in der Cloud wird der Speicherplatz bezahlt (z.B. durch AMP-PD oder GP2).

b. Lokal bezahlen Sie nicht für die Ausführung von Analyse-Pipelines (bzw. Sie bezahlen zwar nicht auf dem eigenen Computer, aber je nach Institution wird für das Cluster bezahlt), während in der Cloud Nutzer*innen für jede ausgeführte Analyse bezahlen (etwa über ihre PIs oder Institutionen).

3. Die AMP-PD- und GP2-Analyseteams haben eine Reihe unterschiedlicher Analyse-Pipelines geschrieben (Link), die optimiert werden können.

a. Da man für die Umgebung, die man einrichtet, und die Datenmenge, auf die man zugreift, bezahlt, ist die bestmögliche Konzipierung und Planung der Analysen ein wichtiger Faktor.

i. Ein Beispiel für Laufzeit-Kosten zur Orientierung findet sich hier.

b. Die Cloud-Umgebung kann immer im Backend aktualisiert werden. Daher ist es wichtig, die Buckets, auf die man Zugriff hat, zu protokollieren und zu versionieren, um später direkt darauf verweisen zu können.

c. Sie bezahlen für die Umgebung, die Sie eingerichtet haben, sowie für die Nutzungsdauer. Halten Sie diese daher an oder löschen sie gleich ganz, wenn sie nicht genutzt wird. So bezahlen Sie nur für das, was Sie auch genutzt haben.

Zum Schluss ein Wort an unsere Freund*innen in den Nasslaboren

Transparenz, freier Zugang und Reproduzierbarkeit sind nicht nur Grundsätze der computergestützten Analysen. Wir empfehlen dringend Tools wie protocols.io oder ein Rocket Notebook zu verwenden, um Laboraufgaben und Experimente zu standardisieren. Die Complex Disease-Data Analysis Working Group und die Complex Disease-Data and Code Dissemination von GP2 wünschen sich beide vorgeschriebene Nasslaborpraktiken, die ihre Arbeit auf der digitalen Ebene widerspiegeln. Wir drängen auch darauf, dass die Praktiken der Probenbeschaffung- und -benennung online standardisiert und transparent sind, auch wenn dies nicht direkt in unseren Arbeitsbereich fällt.

Danksagung/Acknowledgements

In allen Manuskripten, Vorabdrucken und Abstrakts/Postern, die auf der Nutzung von GP2-Datenanalyse-Pipelines beruhen, müssen ASAP und GP2 in der Danksagung (Acknowledgements) in der nachfolgenden Form genannt werden:

„Der zur Erstellung dieser Pipeline verwendete Code stammt vom Global Parkinson’s Genetics Program (GP2). GP2 wird durch die Initiative Aligning Science Against Parkinson’s (ASAP) finanziert und durch die Stiftung The Michael J. Fox Foundation for Parkinson’s Research umgesetzt (www.gp2.org). Eine vollständige Liste der GP2-Mitglieder findet sich unterwww.gp2.org.“ Die Michael J. Fox Foundation, ASAP und das GP2 Steering Committee behalten sich das Recht vor, die Bedingungen aus dieser Vereinbarung zu ändern. Dies können sie tun, indem sie eine Mitteilung über derartige Änderungen auf dieser Seite veröffentlichen. Vorgenommene Änderungen gelten unmittelbar ab Veröffentlichung (sofern nicht anders angegeben). Sie sollten diese Seite regelmäßig besuchen, um die aktuellen Bedingungen der Nutzungsvereinbarung zu prüfen.

Verhaltenskodex für Code-Programmierer*innen: Bitte tragen Sie dem konzeptionellen Rahmen für das gemeinsame Arbeiten an Programmierprojekten bei GP2 Rechnung.