Positions

As de-RSE e.V. - Society for Research Software, we develop and take positions on different aspects of research software, and on topics that affect the people, groups, structures and institutions involved in research software. In doing so, we take the viewpoint of a heterogeneous community, which includes Research Software Engineers across the spectrum of roles and concepts, and represent them in the public discourse.

Our positions are developed in open community processes, which are actively shaped by our members. This process model includes open calls for collaboration, collaborative development, and open review processes upon which decisions are based.

When members of de-RSE e.V. represent the Society in public, they take the accepted positions in relevant discourse.

Table of contents

Position papers - official positions of de-RSE e.V. - Society for Research Software
Work in progress - Positions which are currently under development Development process - An overview of how positions are developed within de-RSE e.V.

Position papers

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.

Position 002 - Foundational Competencies and Responsibilities of a Research Software Engineer

First page of the position 002 PDF. 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.

Position 003 - GI- und de-RSE Muster-Leitlinie zur Effizienten Entwicklung von Forschungssoftware

Abstract: 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.

Work in progress

The following positions are currently developed.

Development process

The development process for positions of the Society has been developed by its members and can be changed by its members if the need arises. It has three phases, which are set up as follows.

1. Call and work phase

  1. Call for Collaboration: Initiators of a position announce the topic on the Society’s mailing list (list@de-rse.org, with subject [Call for contributions]), and invite all members to collaborate. The call names main authors of the position text, and explains the prerequisites for authorship.
  2. Collaboration: Collaboration starts on a - preferably public - platform of the initiators’ choice (*Pad, repository, hackmd.io, Overleaf, etc.). At the same time, the project is presented and linked to on the de-rse.org website under “Positions” > “Work in progress” (per Pull Request against the Positions pages (en/de) on https://github.com/DE-RSE/de-rse.github.io).

2. Review phase

  1. Publication: Once a draft is deemed ready for publication, it is published for review:
    • If the position is to be published on the de-RSE website under “Positions”, a respective pull request (PR) is created against https://github.com/DE-RSE/positions/ (Draft files in a dedicated subfolder).
    • If the position is to be published in another format, a respective issue is created on https://github.com/DE-RSE/projekte, which contains a link to the draft.
  2. Call for reviews: The draft publication is announced on the mailing list (liste@de-rse.org, with subject [Call for Reviews]), and the link to the respective issue/PR is provided. All members are invited to review the draft until a suitable date.
  3. Reviews: Members review the draft publicly in the PR/issue. Should the draft initiate a controversial discussion, the PR/issue is marked with the label [Kontroverse]. Controversial discussions/reviews are those which, in a peer review process, would lead to a rejection or “major revision” decision.

3. Decision phase

  1. Decision: The board decides if the developed position is to be classified as an “official” position of de-RSE e.V. - Society for Research Software:
    • When review discussions are not labeled as controversial, decisions on a position are made by at least one member of the board.
    • When review discussions are labeled as controversial, the board aims to make a decision by consensus. If no consensual agreement can be arrived at, the board makes a decision based on a simple majority vote.
  2. Implementation: An approval for publication as a position of de-RSE e.V. is implemented either by merging and closing the respective issue or pull request and publication of the position on the website, or through an approval comment in and subsequent closing of the respective issue or pull request. If a position draft is not approved, the board can either return the draft to the authors for revision, and note this in the respective issue/PR together with indication of necessary changes, or reject the draft, and close the respective issue/PR with a suitable comment, in which case the position will not be published.

Impressum (legal notice) | Edit on GitHub | Atom 1.0 Feed | | Mastodon profile