Positionen

Als de-RSE e.V. - Gesellschaft für Forschungssoftware entwickeln und beziehen wir Positionen zu verschiedenen Aspekten rund um Forschungssoftware und zu Themen, die involvierte Personen, Gruppen, Strukturen und Institutionen betreffen. Hierbei nehmen wir den Standpunkt einer heterogenen Community ein, die Research Software Engineers über das gesamte Spektrum der Rollen und Selbstverständnisse umfasst und übernehmen deren Vertretung im öffentlichen Diskurs.

Unsere Positionen sind das Ergebnis öffentlicher Community-Prozesse, den alle Mitglieder der Gesellschaft aktiv gestalten. Dieses Prozessmodell beinhaltet offene Calls for Contribution, kollaborative Entwicklung, öffentliche Gutachtenprozesse und darauf basierende Entscheidungen.

Vertreten Mitglieder von de-RSE e.V. berechtigterweise die Gesellschaft in der Öffentlichkeit, vertreten sie in relevanten Diskursen auch die angenommenen Positionen.

Inhalt
Positionspapiere - offizielle Positionen von de-RSE e.V. - Gesellschaft für Forschungssoftware
Entwicklungsprozess - Übersicht, wie Positionen von de-RSE e.V. erarbeitet werden

Positionspapiere

Position 001 - An Environment for Sustainable Research Software in Germany and Beyond: Current State, Open Challenges, and Call for Action (2020)

First page of the position 001 PDF. Abstract: Research software has become a central asset in academic research. It optimizes existing and enables new research methods, implements and embeds research knowledge, and constitutes an essential research product in itself. Research software must be sustainable in order to understand, replicate, reproduce, and build upon existing research or conduct new research effectively. In other words, software must be available, discoverable, usable, and adaptable to new needs, both now and in the future. Research software therefore requires an environment that supports sustainability. Hence, a change is needed in the way research software development and maintenance are currently motivated, incentivized, funded, structurally and infrastructurally supported, and legally treated. Failing to do so will threaten the quality and validity of research. In this paper, we identify challenges for research software sustainability in Germany and beyond, in terms of motivation, selection, research software engineering personnel, funding, infrastructure, and legal aspects. Besides researchers, we specifically address political and academic decision-makers to increase awareness of the importance and needs of sustainable research software practices. In particular, we recommend strategies and measures to create an environment for sustainable research software, with the ultimate goal to ensure that software-driven research is valid, reproducible and sustainable, and that software is recognized as a first class citizen in research. This paper is the outcome of two workshops run in Germany in 2019, at deRSE19 - the first International Conference of Research Software Engineers in Germany - and a dedicated DFG-supported follow-up workshop in Berlin.

Entwicklungsprozess

Der Entwicklungsprozess für die Positionen der Gesellschaft wurde durch die Mitglieder gestaltet und kann bei Bedarf durch die Mitglieder verändert werden. Er verläuft in drei Phasen, die wie folgt gestaltet sind.

1. Aufruf- und Arbeitsphase

  1. Call for Collaboration: Initiatorinnen und Initiatoren einer Position kündigen das Thema auf der Mailingliste der Gesellschaft (liste@de-rse.org, mit Thema [Call for Contribution]) an und rufen die Mitglieder zur Mitarbeit auf. Dabei werden Hauptautorinnen und -autoren des Positionstextes benannt und die Bedingungen für Mitautorschaft erläutert.
  2. Zusammenarbeit: Zusammenarbeit beginnt auf einer bevorzugt öffentlichen Plattform nach Wahl der Initiatorinnen und Initiatoren (*Pad, Repository, hackmd.io, Overleaf, o.ä.). Das Projekt wird gleichzeitig vorgestellt und verlinkt auf der de-rse.org Website unter “Positionen” > “Work in progress” (per Pull Request gegen die Positionen-Seiten (de/en) auf https://github.com/DE-RSE/de-rse.github.io).

2. Begutachtungsphase

  1. Veröffentlichung: Nach Fertigstellung eines zur Veröffentlichung vorgeschlagenen Entwurfs wird dieser zur Begutachtung freigegeben:
    • Soll die Position auf der de-RSE-Website unter “Positionen” veröffentlicht werden, wird ein entsprechender Pull Request (PR) gegen https://github.com/DE-RSE/positions/ gestellt (Entwurfsdateien in einem dedizierten Unterordner).
    • Ist eine andere Veröffentlichungsform vorgesehen, wird ein entsprechendes Issue auf https://github.com/DE-RSE/projekte eröffnet, das einen Link zum Entwurf enthält.
  2. Call for Reviews: Die Entwurfsveröffentlichung wird wiederum über die Mailingliste (liste@de-rse.org, mit Thema [Call for Reviews]) bekanntgegeben, mit Link zum Pull Request/Issue. Die Mitgliedschaft wird zur Begutachtung bis zu einem geeigneten Termin aufgerufen.
  3. Begutachtung: Die Mitgliedschaft begutachtet öffentlich den Entwurf im PR/Issue. Sollte der Entwurf eine kontroverse Diskussion initiieren, ist der PR/Issue mit einem Label [Kontroverse] zu markieren. Kontroverse Diskussionen/Gutachten sind solche, die in einem Peer-Review-Verfahren zu einer ablehnenden Entscheidung oder eine “Major revision” führen würden.

3. Entscheidungsphase

  1. Entscheidung: Der Vorstand entscheidet, ob die vertretenen Positionen als “offizielle” Position von de-RSE e.V. - Gesellschaft für Forschungssoftware eingestuft werden:
    • Bei Diskussionen, die nicht als kontrovers gekennzeichnet wurden, wird die Entscheidung von mindestens einem Vorstandsmitglied getroffen.
    • Bei kontroversen Diskussionen/Gutachten entscheidet der Vorstand in einer Vorstandssitzung nach Möglichkeit im Konsens. Kann eine Einigung nicht gefunden werden, entscheidet der Vorstand mit einfacher Mehrheit.
  2. Umsetzung: Eine Freigabe zur Veröffentlichung als Position des de-RSE e.V. wird umgesetzt entweder als Mergen und Schließen des entsprechenden Pull Request und Veröffentlichung der Position auf der Website, oder als Imprimatur-Kommentar (“Freigabe”) und Schließen des entsprechenden Issue. Erfolgt keine Freigabe, kann der Vorstand den Entwurf zur Überarbeitung zurück an die Autorenschaft geben, dies wird im entsprechenden Issue/PR per Kommentar vermerkt. Hierbei sind Hinweise zu benötigten Änderungen zu geben. Alternativ kann der Vorstand den Entwurf ablehnen. Hierbei werden Issue/PR mit entsprechendem Kommentar geschlossen und es erfolgt keine Veröffentlichung.