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
Work in progress - Positionen, an denen derzeit gearbeitet wird Entwicklungsprozess - Übersicht, wie Positionen von de-RSE e.V. erarbeitet werden
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. |
Autor/inn/en: Hartwig Anzt, Felix Bach, Stephan Druskat, Frank Löffler, Axel Loewe, Bernhard Y. Renard, Gunnar Seemann, Alexander Struck, Elke Achhammer, Piush Aggarwal, Franziska Appel, Michael Bader, Lutz Brusch, Christian Busse, Gerasimos Chourdakis, Piotr W. Dabrowski, Peter Ebert, Bernd Flemisch, Sven Friedl, Bernadette Fritzsch, Maximilian D. Funk, Volker Gast, Florian Goth, Jean-Noël Grad, Sibylle Hermann, Florian Hohmann, Stephan Janosch, Dominik Kutra, Jan Linxweiler, Thilo Muth, Wolfgang Peters-Kottig, Fabian Rack, Fabian H.C. Raters, Stephan Rave, Guido Reina, Malte Reißig, Timo Ropinski, Joerg Schaarschmidt, Heidi Seibold, Jan P. Thiele, Benjamin Uekerman, Stefan Unger, Rudolf Weeber
Abstract: The term Research Software Engineer, or RSE, emerged a little over 10 years ago as a way to represent individuals working in the research community but focusing on software development. The term has been widely adopted and there are a number of high-level definitions of what an RSE is. However, the roles of RSEs vary depending on the institutional context they work in. At one end of the spectrum, RSE roles may look similar to a traditional research role. At the other extreme, they resemble that of a software engineer in industry. Most RSE roles inhabit the space between these two extremes. Therefore, providing a straightforward, comprehensive definition of what an RSE does and what experience, skills and competencies are required to become one is challenging. In this community paper we define the broad notion of what an RSE is, explore the different types of work they undertake, and define a list of foundational competencies as well as values that outline the general profile of an RSE. Further research and training can build upon this foundation of skills and focus on various aspects in greater detail. We expect that graduates and practitioners will have a larger and more diverse set of skills than outlined here. On this basis, we elaborate on the progression of these skills along different dimensions. We look at specific types of RSE roles, propose recommendations for organisations, and give examples of future specialisations. An appendix details how existing curricula fit into this framework. |
Autor/inn/en: Florian Goth, Renato Alves, Matthias Braun, Leyla Jael Castro, Gerasimos Chourdakis, Simon Christ, Jeremy Cohen, Stephan Druskat, Fredo Erxleben, Jean-Noël Grad, Magnus Hagdorn, Toby Hodges, Guido Juckeland, Dominic Kempf, Anna-Lena Lamprecht, Jan Linxweiler, Frank Löffler, Michele Martone, Moritz Schwarzmeier, Heidi Seibold, Jan Philipp Thiele, Harald von Waldow, Samantha Wittke
Einleitung: Diese Muster-Leitlinie bietet einen Rahmen für die Entwicklung, Verwaltung und Weitergabe von Software an der jeweils nutzenden Universität, Hochschule oder dem Forschungszentrum. Sie eignet sich auch für standortübergreifende Verbundforschungsvorhaben, insbesondere wenn die Projektbeteiligten der verschiedenen Universitäten, Hochschulen und Forschungszentren kompatible Fassungen nutzen. |
Autor/inn/en: Andreas Czerniak, Adrian Ehrenhofer, Bernadette Fritzsch, Maximilian Funk, Florian Goth, Reiner Hähnle, Carina Haupt, Marco Konersmann, Jan Linxweiler, Frank Löffler, Alexander Lüpges, Sebastian Nielebock, Bernhard Rumpe, Ina Schieferdecker, Tobias Schlauch, Robert Speck, Alexander Struck, Jan Philipp Thiele, Matthias Tichy, Inga Ulusoy, Scientific Software Center
Folgende Positionen sind derzeit in Arbeit.
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.
[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.[Call for Reviews]
) bekanntgegeben, mit Link zum Pull Request/Issue. Die Mitgliedschaft wird zur Begutachtung bis zu einem geeigneten Termin aufgerufen.[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.