Blog

Identifying the Foundational Competencies of a Research Software Engineer

The TeachingRSE collaboration, October 8, 2024

Only a little over a decade ago, the term Research Software Engineer (RSE) didn’t exist. Now we find ourselves in a position where the term is increasingly widely accepted and research institutions are hiring RSEs to provide the vitally important skills that they need to support and undertake modern research.

What defines an RSE?

So what, or who, exactly is an RSE? Ask three people for a definition of RSE, and aside from the common words “software” and “research”, you’re likely to get three different answers! This is because the space in which RSEs work, and the work that they might do, is not always straightforward to define, and so are their foundational competencies.

RSEs inhabit a previously “hidden space” - the wide gap between the work of researchers in an academic institution and the work of professional service staff whose roles can include everything from finance and student administration to managers of enterprise computing infrastructure. While the work of an RSE, of course, includes software development, RSEs at one end of the spectrum representing this hidden space will have roles that look very much like that of a researcher or academic. At the other end of the spectrum, the role of an RSE will look very much like that of a professional software engineer working in an industry environment. While an RSE undoubtedly writes software, their role is defined by a much wider range of skills, competencies and experience.

Generic definitions of an RSE can be helpful - a common such definition generally highlights that “an RSE is someone who applies specialist software development skills to support and undertake research tasks”. Nonetheless, while not incorrect, this definition masks a vast amount of complexity that warrants a greater discussion.

The foundational competencies of an RSE

Given this complicated and rapidly developing space, the authors of arXiv:2311.11457 (update: now for open peer-review at F1000Research), the teachingRSE collaboration, set out to better understand and to identify the foundational competencies of a Research Software Engineer.

The initial team of Heidi Seibold, Jeremy Cohen, Florian Goth, Philipp Schäfer and Samantha Wittke ran a workshop session, “Teaching and Learning Research Software Engineering”, at the German RSE conference in Paderborn, Germany in February 2023 (deRSE23) which initiated the discussions to understand what exactly the competencies of an RSE are. The community was integrated early-on through multiple workshops (at deRSE23 in Paderborn, un-deRSE23 in Jena, and deRSE24 in Würzburg). While largely based around a core group of members of the German RSE community - de-RSE - the collaboration also had international input to ensure representation of the wider international perspective in resulting outputs.

The length of time spent on this work and the very wide range of inputs and perspectives provided serves to highlight the inherent complexity in identifying the foundational competencies and responsibilities of a Research Software Engineer.

The paper

First page of the position 002 PDF.

“Foundational Competencies and Responsibilities of a Research Software Engineer” works through the process of understanding what makes up the role of an RSE. It starts with some general background and terminology before highlighting what the collaboration worked out as the key values of an RSE - what RSEs are trying to achieve in their role and the values that underpin that work. The authors then look at the competencies themselves, identified through extensive discussion and debate about what RSEs do and how they do it. These skills are grouped into those that relate directly to software, those that are more research related and those that are communication focused. The collaboration identifies these three areas as the core of what an RSE provides - specialist, high-quality software engineering knowledge, an understanding of the research environment (potentially working as a direct contributor to research itself), and the ability to communicate well and work highly effectively with researchers who may not have a computational background, IT savvy personnel who may not have a research background, and managers who may have neither.

After defining the foundational competencies, the authors consider career levels - what should RSEs be expected to know and at what level of detail at different career stages? Recognising that researchers and academics increasingly expect to be able to apply some technical skills themselves the collaboration pins down the RSE skills that researchers and academics might want to learn to support this.

Finally, focusing on the fact that RSEs can have a range of very different roles, the authors look at RSE specialisations, highlighting a number of different roles that RSEs might hold that involve the application of specialist knowledge in related areas. This includes domain-specific RSEs, who have, and use, specialist research domain knowledge, in addition to technical skills. The authors also describe a number of other technical specialisations including data, infrastructure, High Performance Computing and Machine Learning-focused RSEs.

Find out more, join the discussion

A pre-print has been adopted as the second official position paper of de-RSE. As part of the goal to further develop the discussion on this work, to take the findings to a wider audience, and develop further research in this area, the authors are also exploring journal publication options for the final version of the paper. If you’d like to join the teachingRSE collaboration and participate in the discussions and future work, get in touch with find our contact details in our github repository.

Update (2024-12-02)

The paper is now published at F1000 under the doi 10.12688/f1000research.157778.1 veröffentlicht and is awaiting peer review.

This blog post is published under the CC BY 4.0 license. Re-posts are encouraged and should link back to the original.

Evaluation of RSE performance

Bernadette Fritzsch, Jan Philipp Dietrich, December 6, 2023

Research software development plays an increasingly prominent role in today’s research landscape. However, there are still no clear career paths for individuals with a dedicated focus on research software, often referred to as Research Software Engineers (RSEs). RSEs often work as traditional researchers, given their background in research, but this strategy typically involves a goal conflict.

While focusing on research software can enhance its quality and, consequently, the quality of the associated research, these efforts often do not result in traditional publications. Publications are the conventional performance indicators that significantly influence further career progression within the academic system.

Therefore, the question of a career path for RSEs is directly tied to the question of an appropriate evaluation of RSE performance. This issue was chosen as the focal point for a session at the un-deRSE Conference in Jena, where we explored the best ways to evaluate RSEs. Can RSEs be evaluated using the same criteria as traditional scientists, or do we need entirely different metrics? The direct outcomes of this discussion can be viewed at https://pad.gwdg.de/ghuWQ2E9Tomo19Cwe67aXw.

In an engaging conversation, it became evident that even the traditionally used indicators are subject to criticism and selecting suitable performance metrics for RSEs is challenging if not impossible. However, a general direction for meaningful evaluation emerged.

Broadly speaking, three core areas were identified as playing a role in the performance evaluation of an RSE:

Given that the term RSE encompasses a spectrum of diverse job profiles with varying allocations between scientific work and software development, the weighting of these indicators is flexible. In this regard, indicators relevant to traditional scientists may also apply to RSEs. Although RSEs focus on research software, their ultimate goal is to generate high-quality scientific output.

However, a sole focus on traditional indicators falls short. Research software is not only a means to conduct research but is also an outcome of research itself. Therefore, research software should be considered as a specific type of scientific output and appropriately accounted for in the evaluation. With the increasing prevalence of research software publications, this is now feasible.

In discussions, a third aspect was highlighted, which may initially seem unexpected but is an essential component of an RSE’s role upon closer inspection. This pertains to communication. RSEs must be capable of explaining software engineering concepts to traditional scientists while also understanding and explaining the domain-specific questions and associated problems of scientists. Thus, being proficient in programming is not sufficient for an RSE; effective communication and the ability to comprehend scientific inquiries are equally vital.

By considering these three areas, a more comprehensive evaluation of RSE performance should be possible. This could pave the way for the development of new career paths for RSEs in academia parallel to those for traditional scientists, ensuring the continued integration of RSE expertise within the academic system.

deRSE23

Frank Löffler, April 25, 2023

Since 2019, there should have been at least one major de-RSE meeting every year. However, due to the pandemic, four years passed before the community could meet in person again this year.

At the end of February, around 150 RSEs came together in Paderborn, appropriately enough at the Heinz Nixdorf MuseumsForum, for the deRSE23 conference. The range of topics was naturally very broad: from software and community management, software licences, to automation and artificial intelligence in music. Those who didn’t get enough from that could also attend the subsequent software engineering conference SE-23, with which the de-RSE23 organisation collaborated.

The conference opened on the first day with a keynote address on “Engineering Software Ergonomics” by Reinhard Keil, in which the participants were introduced to non-technical, but also important properties of software and its development. In three parallel sessions, projects and communities were presented and future plans and visions were discussed until the poster session in the evening. During the well-attended poster and demo session, the Young RSE Award was presented, which this time went to Yudong Sun, but was also intended to highlight the work of all young participants. The day ended with the conference dinner, which ended at 10 pm yet did not mean an end to the discussions. Some of the participants arrived back at the hotel after midnight and still made it back at 9 a.m. the next day in order not to miss the second keynote.

This time, the RSEs were introduced to the advantages of the AWS Cloud and especially its Development Kit, before topics such as Cloud Technologies, but also Software Management Plans and Musicology continued in parallel sessions into the afternoon. Officially, this was the end of de-RSE23 in the early evening.

More than half of the participants, and thus far more than expected, took up the offer of a third day, on which the programme consisted less of lectures and more of workshops. Here, RSE-related communities such as the Software Carpentries and the Alliance Initiative met. Work was done on a text about setting up RSE groups at research institutions in Germany. Topics such as training and documentation in the RSE environment were also on the agenda. For many, it was then time to head home late on Wednesday afternoon, after three exciting, interesting, communication-rich but also long and exhausting days.

However, as so often, the three days were not nearly enough to discuss everything or work on all the topics of interest in the RSE environment, so there will be another opportunity to do so in 2023, and this time with even more opportunity to exchange ideas and work together on concrete projects. For this very purpose, RSEs will come together for a second time this year from 26 to 29 September, this time for the un-deRSE23 Unconference at the Dornburg Castles near Jena. In contrast to the de-RSE23, the focus here will be on workshops and discussion panels, the topics of which will be determined by the participants themselves: partly before, partly just at the event. The number of participants is limited due to the size of the castle, so if you want to be there, you should submit as soon as possible.

deRSE23 in numbers:

Material:

Call for Contribution - deRSE23 the RSE Conference 2023 in Germany

Stephan Janosch in behalf the deRSE23 organisers, October 12, 2022

deRSE23, the third conference in Germany addressing research software and the people behind it within the German research landscape will be held at the Heinz Nixdorf Forum (HNF) in Paderborn on February 20-21, 2023.

The organising committee welcomes submissions for talks, posters and demos in English or German languange for the deRSE23 conference. The aim is to reflect the diverse community of research software engineers by seeking input from all levels of experience and across a variety of domains, geographic locations, genders, and ethnicities.

Timeline

If your submission is accepted, at least one of the authors is expected to attend the conference to present. Please note that conference fees apply at registration.

Conference sessions, themes and types of contribution

deRSE23 has no pre-defined thematic tracks. Instead, sessions will be inductively created by the programme committee from the submissions. If your submission addresses a topic that you think is of interest to the community of people involved in research software, we would love to see it submitted! We also prepared a bazaar, where you can connect with others and start a contribution collaboration. Please note the formats section below.

Who should submit?

We welcome submissions from any and all people who have an interesting take on research software development, including:

We’re aiming for a well-balanced programme that includes a wide variety of perspectives to reflect the diversity of the RSE community and its activities showcasing that software can be a language that furthers communication across the established domain boundaries. Similar conferences in other countries in the past found that social sciences and humanities were under-represented so we’d particularly like to encourage speakers from those areas to apply. We are not just looking for seasoned presenters or people who are already well known. Thus, speakers from under-represented backgrounds and at early career stages are highly encouraged to submit a proposal.

We will select talks and workshops through a single-blind review process, i.e., reviewers will see authors’ names and affiliations. This supports software-related submissions better than a double-blind process.

First-time presenter?

We want you to present! It’s important that the programme includes people who don’t normally publish papers, or give talks at academic conferences. We want your voice to be heard as part of the RSE community.

It’s not intimidating! deRSE23 is about learning from each other in a supportive atmosphere. Your perspective is welcome and needed, and presenting will be a great chance to start a wider discussion of issues you care about.

We can help! We can offer mentoring and other support with preparing your presentation. Please email us if you require advice or clarification before making a submission. We aim to offer one-on-one mentoring to help successful applicants prepare their talk, poster or workshop. If you would like a mentor to help you just tick the respective box when submitting your proposal/registration.

Contact

If you have any questions about the conference, or the submission of proposals, please contact the conference organisers at derse23orga@listserv.dfn.de.

Technicalities

The focus of deRSE23 is on community. Therefore, instead of asking you to submit an academic abstract following a specific structure, submissions to deRSE23 are a bit more free form.

For conference management we use the free french service sciencesCONF by the CCSD (Centre pour la Communication Scientifique Directe). You need to create an account there, then simply fill out the submission form. The form includes a field for the description of your submission (“abstract”, 750 characters max!).

Submitting a contribution does not automatically register you for the conference, please remember to register your participation.

Formats

competition for young RSE prize

If your RSE career just has started, you can participate for the young RSE prize 2023. Any of the formats below are valid. What is a young RSE? We consider people with a phd or master thesis from 2020 and onwards young RSE. Winners will be highlighted and will receive some trophy money.

Talks

Talks may have a length of 15-30 mins., including time for Q&A and discussion, depending on the number of talks in the respective session. If your talk is accepted, you will be notified about the length of the talk by the session chair.

Posters

Posters are used to present an overview of an idea, a project, a collaboration, etc. Posters must be in portrait orientation and maximally up to A0 size (max. height: 1189mm; max. width: 841mm). Please be prepared to give a very short presentation about the contents of your poster in a “lightning talk”. This will help attendees of the poster session identify the posters and people they want to look at and talk to.

Demos

As an alternative to a printed poster you demonstrate your contribution to a limited number of people during the poster session. You will get a table and some space around it.

Workshops, etc

For workshops note that there is a workshop centric event planned for summer - deRSE Unconference 2023. If you would like to run interactive and educative sessions please contact the organisers.

We are looking forward to your contributions!

RSECon22: Collaborating on the automation of research software publication with rich metadata

Oliver Bertuch (Forschungszentrum Jülich, ORCID), Stephan Druskat (German Aerospace Center (DLR), ORCID), Michael Meinel (German Aerospace Center (DLR), ORCID), Oliver Knodel (Helmholtz-Zentrum Dresden-Rossendorf (HZDR), ORCID), September 29, 2022

This post is being cross-posted on the Software Sustainability Institute blog.

Publishing your research software in a publication repository is the first step on the path to making your (research) software FAIR! But the publication of the software itself is not quite enough: To truly enable findability, accessibility and reproducibility, as well as making your software correctly citable and unlock credit for your work, your software publication must come with rich metadata to support these goals.

But where will this metadata come from? And who should compile and publish it? Will RSEs have to become metadata experts as well?

Project

HERMES (HElmholtz Rich MEtadata Software publication) is a project funded by the Helmholtz Metadata Collaboration that runs until June 2023.

We argue that source code repositories and connected platforms often already provide many useful metadata, even if they may be distributed over heterogeneous sources. Providing an open source software toolchain, we aim to help harvest these metadata, process and collate them, and prepare them for deposition in publication repositories.

Recap: Workshop Let’s talk FAIR for research software at SE2022

Martin Stoffers, Tobias Schlauch, René Caspart, Alexander Struck, June 2, 2022

In our workshop at SE2022 we discussed practices in and handling of research software development and how this relates to the FAIR principles for Research Software [Lamprecht2020, Katz2021]. In the first part of the workshop we introduced the three topics, “Foundations of Research Software Publication”, “FAIR in HPC” and, “Findable Research Software”. The second part of the workshop was organized as a World Café where we discussed these topics in three sessions. In this blog post we want to summarize the findings of these sessions and of the workshop as a whole.

Foundations of Research Software Publication

The first session focused on subjects covered in the HIFIS workshop “Foundations of Research Software Publication”. In the first part, we asked what new subjects should be addressed in a new or extended workshop version. Here we uncovered three more subjects that may be good candidates to improve the workshop’s content. These subjects are “Maintenance and life cycle management for Research Software”, “Contributions and Community” and, “When not to write your own software”. All three subjects are strongly related to the core values of the FAIR principles. In addition, the provided feedback suggested that the current workshop title might be very appealing to research software engineers but might not raise interest in other intended groups such as PhD candidates or scientists. Beside investigating this issue further, one solution might be to host dedicated workshops with different titles but mostly similar content. We also concluded that our workshop could benefit from a more modular concept were subjects can be interchanged depending on the required skills of the audience.

Life cycle management in Research Software Engineering. Credit: Stephan Janosch
Life cycle management in Research Software Engineering. Credit: Stephan Janosch

In the second part, we asked what specific topics current subjects such as, “Documentation”, “Licenses”, “Citations/Findability”, and “Release management/Publication” and newly suggested subjects could benefit from. Within the subject “Release management”, teaching the use and importance of standardized installations processes was raised. In the subject of “When not to write your own software” the importance to teach tools and techniques to select third-party software and the aspect of findability for research software were discussed. Especially the latter was further discussed in our session of “Findable Research Software”. Based on the feedback, the subject of “Contributions and Community” should be extended to cover topics like “Code of Conducts” or “Contributor Agreements” in future workshops. Questions raised were: “How to handle contributions?” or “How to encourage contributions for community building?”. Especially “Contributor Agreements” was reported as topic with high uncertainties for single researchers or RSEs with respect to legal frameworks and rules within research organisations. Lastly, the subject of “Maintenance / Life Cycle Management” was actively discussed across groups. It was mostly perceived as a big challenge in research software engineering. Participants mentioned questions about long-term code ownership, missing funding for maintenance, and maintaining of software with feature creep [Elliott2007] as challenges. The complexity of life cycle management was put into perspective using a drawing created by Stephan Janosch, which outlines important aspects of the whole process. One particular problem mentioned in this context was that it is often easier to use and cite older releases instead of adapting code in newer releases. One open question raised from this discussion was: “How do we create incentives for scientists to help maintain the software they rely on?”. We think life cycle management is an important topic that needs to be coverd in future workshops. However, further research on life cycle mangement in research software engineering is needed before we can provide sufficient training material on this topic.

FAIR in HPC

The second session covered the topic FAIR in HPC, with a specific focus on Accessibility. Together with the participants we discussed experiences and ideas related to the usage of HPC clusters in research software engineering, but also research in general. In the first part, we asked the participants about their experiences with using HPC systems for their work. A commonly raised topic was the issue of different setups at different HPC systems. In addition, restrictions in the accessibility of Internet resources and data transfer were mentioned. Researchers experience increasingly more difficulties in including the HPC systems in custom workflows, e.g. due to tightening of security and 2FA, resulting in an stronger dependence on provided services. In the second part, we asked the participants about their ideas for either improving existing infrastructures and services or new, not yet widely available, services to support their everyday work. The participants noted that an increased homogenization of HPC clusters would be apprecicated to improve the Interoperability for different clusters. Specifically for RSEs, a better integration with common tools, such as continous integration, and related workflow management was voiced. Going beyond the demands specific to the software development aspect of RSE, general workflow-management tools and specifically a better integration and support for electronic lab notebooks (ELN) was also voiced. In the context of FAIR, ELNs play an important role, as they allow researchers to more easily and efficiently keep track of their work and results. Such information may ease Reusability.

Findable Research Software

Why did you (not) search for software?

We entered the world cafe with this two-fold question after a short introduction of the idea. Among the reasons for people actively searching for software, we want to highlight the following:

That spun off discussions with heavy opinions on when to not search for software. Most prominent arguments were:

Studies and policies related to software publishing [Akhmerov2021, Hucka2018, al Noamany2018, Howison2015] document these and some other reasons why code may not be shared.

The actual search for software was conducted as reported in previous papers, e.g. Howison2015:

There was agreement, that an evaluatory ‘trial & error’ phase for found software is required. We hope that certain other locations, like language-specific repositories, e.g. CRAN for R, are also in use although not mentioned.

How to improve Findability?

We also asked the participants to populate a wishlist that would improve the(ir) current situation. From the wide range of suggestions, a few stand out:

Findability Conclusion

While the number of participants is not representative for Research Software Engineering, the shared notions reflect commonly accepted views and strengthen conclusions of recent papers. Several stakeholders have an interest in improved findability of software and some act on it. Examples include the FAIR for Research Software [FAIR4RS] working group at RDA.

Concluding Thoughts

The audience appreciated the workshop topics and the format. As organizers we received valuable input in all three sessions. In particular, we were able to map some activities to FAIR principles and raise awareness for many of its aspects. We recommend this format and venue to gather input for your projects. A future de-RSE conference will also be a promising platform.

Further Reading

Anna-Lena Lamprecht et al., “Towards FAIR Principles for Research Software,” ed. Paul Groth, Paul Groth, and Michel Dumontier, Data Science 3, no. 1 (June 12, 2020): 37–59, doi: 10.3233/DS-190026. https://doi.org/10.3233/DS-190026.

Daniel S. Katz, Morane Gruenpeter, and Tom Honeyman, “Taking a Fresh Look at FAIR for Research Software,” Patterns 2, no. 3 (March 2021): doi: 10.1016/j.patter.2021.100222, https://doi.org/10.1016/j.patter.2021.100222.

Ruijter, Maria Cruz, Paula Martinez- Lavanchy, Mark Schenk, Margot Spaargaren, and Marta Teperek (2021). TU Delft Research Software Policy. en. doi: 10.5281/ZENODO.4629662. url: https://zenodo.org/record/4629662.

B. Elliott, “Anything is possible: Managing feature creep in an innovation rich environment,” 2007 IEEE International Engineering Management Conference, 2007, pp. 304-307, doi: 10.1109/IEMC.2007.5235049. url: https://doi.org/10.1109/IEMC.2007.5235049.

AlNoamany, Yasmin and John A. Borghi (Sept. 2018). “Towards computational repro- ducibility: researcher perspectives on the use and sharing of software”. In: PeerJ Com- puter Science 4, e163. doi: 10.7717/peerj-cs.163. url: https://doi.org/10.7717/peerj-cs.163.

Howison, James and Julia Bullard (May 2015). “Software in the scientific literature: Problems with seeing, finding, and using software mentioned in the biology literature”. In: Journal of the Association for Information Science and Technology 67.9, pp. 2137– 2155. doi: 10.1002/asi.23538. url: https://doi.org/10.1002/asi.23538.

Hucka, Michael and Matthew J. Graham (July 2018). “Software search is not a science, even among scientists: A survey of how scientists and engineers find software”. In: Journal of Systems and Software 141, pp. 171–191. doi: 10.1016/j.jss.2018.03.047. url: https://doi.org/10.1016/j.jss.2018.03.047.

Marshall, James J., Steve Olding, Robert E. Wolfe, and Victor E. Delnore (2006). “Soft- ware Reuse Within the Earth Science Community”. In: Proceedings IGARSS 2006 - 2006 IEEE International Geoscience and Remote Sensing Symposium; July 31, 2006 - August 04, 2006; Denver, CO; United States. url: https://ntrs.nasa.gov/search.jsp?R=20060027793.

Smith, Arfon M., Daniel S. Katz, and Kyle E. Niemeyer and (2016). “Software citation principles”. In: PeerJ Computer Science 2, e86. doi: 10.7717/peerj-cs.86. url: https://doi.org/10.7717/peerj-cs.86.

rSE22 - Call for Contributions

Stephan Janosch, rSE22 programme committee, October 4, 2021

In June 2019, research software developers from all over Germany met for the first time for a central conference at deRSE19 in Potsdam. Ideas and plans for follow-up conferences in 2020 and 2021 were unfortunately thwarted by the pandemic. Therefore, de-RSE e.V. is now joining forces with colleagues from software engineering and organising a separate track on research software for SE 2022 of the Gesellschaft für Informatik (GI) in February 2022.

The organising committee is looking forward to submissions for workshops, talks and posters, as well as for splinter meetings and informal “Birds-of-a-Feather (BoF)” discussion meetings. The aim of the conference is to map the diverse community of research software engineers through participation of all levels of experience across disciplines, locations, genders and origins.

Timeline

Conference sessions, topics and submission types

rSE22 is a track of the SE 2022 Conference of the GI with a focus on research software. The sessions within the track will be put together by the programme committee based on the submissions. If you have a work on a topic that could be of general interest to the research software community, we look forward to your submission!

Who can submit?

We welcome submissions in German or English from anyone with an interesting contribution to research software. These include but are not limited to:

Our aim is to have a balanced programme that reflects the diversity of perspectives and the diversity of the RSE community and its activities. Similar conferences outside Germany have found that the humanities and social sciences have been underrepresented there, so we would like to explicitly invite RSE activists from these fields to submit.

We are not only looking for experienced, well-known or PhD speakers. Therefore, we would like to explicitly invite all individuals from underrepresented groups and early career researchers to submit as well!

Submissions will be reviewed in a “single-blind” process, which accommodates software-related submissions. This means that reviewers will be able to see the names and institutions of origin of authors.

Contact

If you have any questions about the conference in general or specifically about submission, please contact the conference committee: SE_2022@informatik.hu-berlin.de.

Contributions

The focus of rSE22 lies on the community. Therefore, we do not ask for formal academic abstracts, but. instead are looking for a brief description of the contribution.

Submissions of this years conference are managed via EasyChair. Click ->here<- to start your submission. For the submission you first need to register an account in EasyChair. After successful login you then have to click on “make a new submission” and select the “SE2022 Research Software Engineering Track” to get to the submission page.

We are looking for submissions in English as well as in German and will assume that the language of the abstract will also be the preferred language for the contribution. Additional notes can be provided as part of the contribution description.

Topic bazaar

If you do not want to present a topic on your own or are looking for fellow participants to conduct a workshop, we recommend using the rSE22 topic bazaar. This is a freely editable document with templates. There you enter your ideas or wishes and, if necessary, get in touch with other people to realise your idea.

Formate

Workshops, Splinter Meetings, BoFs

Workshops are pre-conference interactive formats that give participants the opportunity to collaborate on a specific topic. They can be organised in different ways, e.g. tutorial, discussion and speed blogging session, hack session. Splinter meetings serve working groups with specific, sharply defined interests. Birds-of-a-Feather (BoF) are informal meetings without a pre-planned agenda to exchange on a specific topic.

The Monday and Tuesday before the conference leave enough free space to realise such interactive formats. They can take place purely virtually or decentrally on site at the participants’ own choice (room must be provided by the participants themselves).

Experience has shown that a length of 90 to 180 minutes is well suited for workshops. For splinter meetings and BoFs, a length of between 30 and 90 minutes is recommended. Please mention in your submission the intended length of the proposed session so that we can schedule it accordingly.

Presentation

Presentations are 15-30 minutes long, including time for questions and discussion, depending on how many presentations are combined into one session. If your presentation is accepted, you will be informed of the length by the session chair.

Poster

Posters present an idea, a project, a collaboration, etc. Posters must be in portrait format and must not exceed a size of A0 (height: max. 1189mm; width: max. 841mm) and must be available digitally as PDF. Please be prepared to present your poster in a very short “lightning talk”. This will help conference participants identify the posters and people they would like to visit during the (virtual) poster session.

Links

rSE22 topic bazaar | rSE22 submission form

Building Research Software Communities

Michelle Barker, Jeremy Cohen, Daniel Nüst, Toby Hodges, Serah Njambi Rono, Lou Woodley, April 27, 2021

Cross-posted on CSCCE and Imperial College London - Research Software Engineering blogs.

Photo by @randyfath on Unsplash.

Running a workshop on community building and sustainability for the research software community

On Wednesday 17th March 2021, around 50 individuals from a wide range of different countries and time zones came together for the first of two 2-hour sessions that formed our “Building Research Software Communities: How to increase engagement in your community” workshop.

Run as part of the SORSE Series of Online Research Software Events, this workshop brought together an organising team consisting of 3 members of the international research software community and a group of speakers including experts in community engagement and sustainability. In this blog post we provide an overview of the workshop and some of the key messages and outcomes.

Why run a communities workshop?

The workshop’s three organisers - Michelle Barker, Jeremy Cohen and Daniel Nüst - between them have experience of starting and running, or participating in a range of research software communities at local, regional, national and international levels. Observing that many research software communities face similar challenges when getting started or trying to sustain activities, the workshop was set up with the aim of helping to address these issues.

Scientific or research communities are often set up by enthusiastic individuals who are keen to help their peers, raise the profile of their field and provide opportunities for training, knowledge exchange and networking. After what is often an extremely promising start with many people engaging and lots of attendees at initial events, it’s quite common for a community to lose momentum and for numbers to reduce to a small but committed group of people. Community organisers may begin to wonder where they went wrong, what they could have done differently and why people are not participating in the same numbers. Many people in the research software community are now involved in developing or helping to run communities (such as national Research Software Engineering (RSE) organisations) or want to initiate grassroots activities, but they are often without the experience or training to do so. The aim of this workshop was to try and offer some ideas, guidance and training from a group of scientific community engagement and sustainability experts to help begin to address this.

The workshop

The workshop included a combination of lightning talks and longer sessions run by leading experts in community engagement and sustainability from the Center for Scientific Collaboration and Community Engagement (CSCCE) and The Carpentries. You can find the full agenda on the workshop webpage. It was attended by participants with varying degrees of responsibility for, or interest in, managing research software communities.

Starting with a group of 4 lightning talks to set the scene, we heard from both current and former community managers representing communities at different stages of development. This provided a great opportunity to hear about some challenges faced but also success stories. Following the introductory lightning talks we had our first collaborative session of the workshop with Daniel Nüst running a short group feedback session.

Your three biggest community challenges

In the feedback session, participants were split into breakout groups, each with their own collaborative document, and invited to discuss and note down the three biggest challenges they’ve experienced/observed as a community manager or member. The results from this session helped to guide the discussion during subsequent sessions. The session provided a wide range of interesting and helpful responses which were summarised into five core areas:

Describing member engagement with the CSCCE’s Community Participation Model

After a chance for the workshop participants to discuss their community challenges, Lou Woodley, Director of the CSCCE, ran a session looking at “Describing member engagement with CSCCE’s Community Participation Model”. One of the key elements of this session was the presentation of the CSCCE’s Community Participation Model which defines four modes of member engagement that can take place within a community and one meta-mode - the champion mode discussed on day two. Community participants generally begin to engage with the community in the consume mode, taking in the materials that are made available through, for example presentations at events and online content such as newsletters. Levels of engagement can build through contribution and scaffolded collaboration to the highest level of engagement - co-creation - where participants work within the context of the existing bounds of community activity to create something new.

Download a guidebook describing the model in full here.

Community Champions

After a quick recap of the previous day’s material, the workshop slot on day 2 kicked off with a session from the CSCCE on Community Champions. The champion mode is the fifth mode in CSCCE’s Community Participation Model and highlights member engagement by emergent leaders within a community, who take on roles to maintain, grow and evolve the community’s activities. This might look like co-chairing working groups, serving on a code of conduct committee or spreading the word about the community to recruit new members. Lou Woodley highlighted the principles behind developing community champions and the important role that they can play in supporting community sustainability and ongoing engagement - something a community manager is unlikely to be able to do alone.

Community Sustainability

The final session of the workshop was a collaborative session on community sustainability run by Toby Hodges and Serah Njambi Rono from The Carpentries. Toby and Serah highlighted the challenges in ensuring community sustainability and presented various ideas to help address them. Using a collaborative document, a number of thoughts and comments were gathered from workshop participants in response to some important questions around the topic of sustainability. You can read more details about this workshop session in Toby and Serah’s “Pondering on the Question of Community Sustainability” post on The Carpentries blog and see a video of the session on the workshop’s SORSE event page.

This workshop was run as part of the SORSE “Series of Online Research Software Events”. The SORSE series has now finished but you can take a look back at other SORSE events, many of which cover related topics, and see videos from many of the events via the SORSE Programme page.

Videos from parts of this communities workshop are available on the workshop’s SORSE event page and further details including the full agenda and session descriptions are available on the workshop website.

Why not join the CSCCE’s Community of Practice on Slack? It’s a great place to gain new knowledge about community development, engagement and sustainability and to share your experiences and questions.

Change of our mailing address

Stephan Druskat, April 26, 2021

The Society for Research Software has a new mailing address:

de-RSE e.V. - Society for Research Software
c/o German Aerospace Center (DLR)
Institute for Software Technology
Rutherfordstraße 2
12489 Berlin
Germany

We would like to thank the Institute for Software Technology at DLR for giving us a postal home.

Introducing the International Council of RSE Associations

Daniel S. Katz, Stephan Druskat, Ian Cosden, Paul Richmond, Anne Fouilloux, January 27, 2021

Cross-posted on researchsoftware.org.
Photo by Mat Reding on Unsplash.

The RSE movement has been very successful, leading to thousands of both formally titled and self-described RSEs, about 7 national or multinational RSE associations, and a series of international RSE events (SORSE). This growth has led to a challenge, that there is no formal mechanism to ensure that the national associations collaborate internationally. This means that there is no clear view on who should be running international branded events such as an “International RSE Conference” and no active coordination to ensure that the national associations don't compete for conference dates by accident. In addition to organisational aspects, associations often face similar governance and policy challenges as well as potentially duplicating initiatives that could be run across associations. At the same time there is a need to provide resources and a point of contact for aspiring communities. It is necessary to find a working model for communities with a broad spectrum of maturity levels, giving a forum to the ones further ahead in the process of establishing an initiative, while providing means for others to get started.

The solution

Based on discussion at the 2nd International RSE Leaders Workshop, a set of national and multinational associations

have created the “International Council of RSE Associations” (“The Council”) as a forum to communicate and formally meet to ensure cohesion between associations and to provide a platform for open discussion around international issues and affairs. This enables collective decision making, collaboration among national associations as well as peer support.

Each member association has agreed to send two representatives (members of the association’s leadership group, well versed in current RSE events and capable of speaking on behalf of the association) to the Council, which meets virtually at least two times per year, and likely more as we start up.

The initial goals of the International Council of RSE Associations are:

1. Communication and Coordination

This includes coordination of participation in other interest groups, such as the Research Software Alliance (ReSA) and the Research Data Alliance (RDA); coordination of advocacy, developing a common argument for advocating for the implementation of Research Software Engineering for institutions, policy makers, funders, etc.; event coordination, to minimize the likelihood that associations schedule conflicting events; international RSE event branding, that the Council can approve of the use of the term “International RSE” for events; and international conference planning, such as potentially an international conference rotated around societies/associations.

2. Discussion Forum

The member associations can raise questions and set the agenda for discussion on topics pertaining to the organization and operation of a national association, to create a general forum to share knowledge, experiences, and best practices surrounding the formation and growth of national RSE associations, and to make this knowledge available to both established and new associations.

3. Avoiding and resolving conflicts between Associations

Regular Council meetings provide a formal and public opportunity to ask questions to other associations, particularly where other associations are interested in the answers. And should a substantive conflict between associations arise, the Council will provide a formal path to conflict resolution. Member associations can bring the issue to the Council meeting and request the Council work together to resolve the issue.

4. Development of new national associations

The Council will help and to encourage initiatives to develop new national RSE associations. The new establishing associations can attend the council as observing participants, and at the end of Council meetings, these observing participants can ask questions to the Council or offer items for discussion. This is intended to give the leaders of burgeoning communities an opportunity to listen and learn from Council associations to further support the growth of their communities. Once matured, the new associations can become full members of the Council. While the addition of future association members will be voted on by the existing Council membership, the Council currently thinks that important criteria for membership are:

Contact

The Council's first meeting was 25 January 2021 and it plans to meet on a regular basis throughout the year. The Council can be contacted at intl-rse-council@listserv.dfn.de.

deRSE20 Goes Bazaar

Stephan Druskat, January 31, 2020

Have you read the essay “The Cathedral and the Bazaar”, by Eric S. Raymond about open source development? In it, Raymond argues that open-source development breaks down the mismatch and separation between different parties regarding mental models of a problem, in his example a software program. Opening the source for a solution of the problem, he further says, makes it “far easier for tester and developer to develop a shared representation grounded in the actual source code and to communicate effectively about it.”

Translated to open research, we see an analogy in open collaboration based on a common shared source of knowledge. Indeed, for deRSE20, we would like it to be far easier for presenters and audience to develop a shared representation grounded in common knowledge, and to communicate effectively about it. As a community conference, there has been a fairly large overlap of presenters and audience at deRSE19 already. This year, we’d like to push this even further, and encourage more, stronger, and earlier collaboration on the topics in research software you care about.

Therefore, we are happy to present the deRSE20 Topic Bazaar! What may sound fairly grand is in fact very simple: If you consider submitting a contribution to deRSE20, we would like you to look around to see if there are potential collaborators in the community, which you may not know about yet. To make it easy for you to find collaborators, we’ve set up a simple “pad” (a shared document on the web, written in Markdown and rendered simultaneously). In this pad, you can

We hope to see many fruitful collaborative contributions at deRSE20!

We encourage you use the topic bazaar especially if plan to submit a workshop proposal! Please don’t leave this until the last minute, as collaboration takes time.

The deRSE20 Topic Bazaar can be found at https://bit.ly/deRSE20-bazaar.

The deRSE20 Call for Contributions opens on Monday, 03 February 2020.

Save the Date: deRSE20 - 2nd Internationl Conference of Research Software Engineers in Germany, 25-27 August 2020

deRSE e.V. - Society for Research Software, December 20, 2019

The 1st International Conference for Research Software Engineers in Germany this year in June in Potsdam was a great success. Therefore we are very happy to announce that planning for the 2nd International Conference for Research Software Engineers in Germany has started!

Save the date!

The conference is expected to take place take place from mid-Tuesday, 25 August 2020, until mid-Thursday, 27 August 2020 at the Friedrich Schiller University Jena. We’re very much looking forward to welcoming you there.

We are aware of holidays during this time in some federal states, but are bound to this date by the availability of the venue.

It is our continued aim in 2020 to focus on the diversity of topics and people in Research Software Engineering, and enable lively exchanges across the whole spectrum of research software. For a first impression of some of the topics that were covered in June, have a look at the video recordings on the TIB AV portal.

The community is also planning for a co-located NFDI event.

If you have any questions about the conference, or about joining the team, please get in touch with us at konferenz@de-rse.org.

See you in Jena!

The #deRSE20 conference committee

DrWatson. The scientific project assistant

George Datseris, May 29, 2019

Hello everyone,

I’d like to present a new software that was recently released in open beta, called DrWatson, the perfect sidekick to your scientific inquiries.

DrWatson is what I’ll call a “scientific project assistant”. It is software package created to help people “deal” with their simulations, simulation parameters, where are files saved, experimental data, scripts, existing simulations, project source code and in general their scientific projects. Although it is written in Julia, I believe its principles, practices and how it can assist you in managing a project can be applied to any other language.

You can find the full documentation here:

https://juliadynamics.github.io/DrWatson.jl/dev/

In this blogpost I will summarize what this software can do for you and how can it help you by reducing the stress of managing a scientific project. Please be aware that DrWatson is not a database management system.

Functionality

DrWarson is a scientific project assistant software package. Its core functionality is separated into 4, almost completely independent parts:

What makes DrWatson different

are the principles that we based our design decisions.

  1. Non-Invasive. DrWatson does not require you to follow strict rules or change the way you work and do science in order to use it. In addition DrWatson is function-based: you only have to call a function and everything else just works; you do not have to create additional special struct or other data types.
  2. Simple. The functionality offered is a baseline from where you handle your project as you wish. This makes it more likely to be of general use but also means that you don’t have to “study” to learn DrWatson: all concepts are simple, everything is easy to understand.
  3. Consistent. The functionality is identical across all projects and DrWatson offers a universal base project structure.
  4. Allows increments. You didn’t plan your project well enough? Want to add more folders, more files, more variables to your simulations? It’s fine.
  5. Reproducibility. DrWatson aims to make your projects fully reproducible using Git, Julia’s package manager and consistent naming schemes.
  6. Modular. DrWatson has a flexible modular design which means you only have to use what fits your project.

Examples

Let me now show two real life examples of using DrWatson.

1. Getting a name out of a container

In simulations it is often the case that we used a named container (like a dictionary) as something to hold our parameters in. For example

c = (T = 100, dt = 0.1, N = 25, mode = “bi”)

then calling the function savename that DrWatson offers results in

savename(c)

"N=25_T=100_dt=0.1_mode=bi"

while you can also add prefix/suffix

savename(datadir(), c, “dat”)

"path/to/data/N=25_T=100_dt=0.1_mode=bi.dat"

What is important is that the function savename works for any named container, which includes dictionaries, named tuples or any Julia composite structure (existing or to-be-created in the future).

In addition, it sensibly excludes non-fitting fields (e.g. vector-valued fields) but can be customized to full extent for your custom type.

2. Producing a dataframe from saved files

Let’s say that you have run some simulations with parameters a = 1 or 2, b = “x” or “y” and c = 0.3. You save these simulations in the directory “data”. for the purpose of this example you only save the parameter values but no other further data (like actual results)

You can then call the function

df1 = collect_results("data/")

4×3 DataFrame
│ Row │ a      │ b       │ c        │
│     │ Int64⍰ │ String⍰ │ Float64⍰ │
├─────┼────────┼─────────┼──────────┤
│ 1   │ 1      │ x       │ 0.3      │
│ 2   │ 1      │ y       │ 0.3      │
│ 3   │ 2      │ x       │ 0.3      │
│ 4   │ 2      │ y       │ 0.3      │

This is already quite convenient. But where collect_results really shine is the following. You now run a new simulation with a=4, b=“z”, a new parameter d=0.5 or 0.6 and the parameter c does not exist anymore! You again save these simulations in “data”. Then you call collect_results again:

df2 = collect_results("data/")

6×4 DataFrame
│ Row │ a      │ b       │ c        │ d        │
│     │ Int64⍰ │ String⍰ │ Float64⍰ │ Float64⍰ │
├─────┼────────┼─────────┼──────────┼──────────┤
│ 1   │ 1      │ x       │ 0.3      │ missing  │
│ 2   │ 1      │ y       │ 0.3      │ missing  │
│ 3   │ 2      │ x       │ 0.3      │ missing  │
│ 4   │ 2      │ y       │ 0.3      │ missing  │
│ 5   │ 4      │ z       │ missing  │ 0.5      │
│ 6   │ 4      │ z       │ missing  │ 0.6      │

As you can see the collection scheme has no problem with combining simulations with different parameters. This is especially useful for a scientific project, since it is almost impossible to know in advance all simulations you would have to run by the end of the project!

Conclusion

I hope that DrWatson can help you and I hope you will be interested to discuss during the deRSE2019 meeting! See you all there! If you are eager to contact us about DrWatson before deRSE2019, please use the GitHub repository:

https://github.com/JuliaDynamics/DrWatson.jl

best regards, George Datseris

New RSE groups meet in Munich and Münster

Heidi Seibold (Institut für Medizinische Informationsverarbeitung Biometrie und Epidemiologie, LMU München), Daniel Nüst (Institut für Geoinformatik, Universität Münster), February 26, 2019

The RSE community in Germany is filled with life by many committed people. An important building block for the realization of the goals is cooperation of research software engineers on a regional level. Thus local “chapters” can enable a much more regular exchange about problems, challenges, and solutions around software in research. Just as in the association de-RSE e.V. throughout Germany, the focus is on the people developing researching software.

Two new groups came together for the first time last month.

In Munich, Heidi Seibold together with Bernd Bischl (LMU) and Tobias Weber (Leibniz Computing Center) organized a round table at the Leibniz Computing Center. 35 persons from various subjects and scientific institutions in Munich participated, which far exceeded the expectations of the organizers. After the greeting and a short keynote lecture on the topic, almost two hours of constructive discussion took place. Focus topics were the lack of career paths for people who identify themselves as Research Software Engineers, lack of financial means to hire (permanent) Research Software Engineers, and the reputation of research software. Of special interest, of course, was what can be done locally in the Munich area to solve these problems. Among the ideas were the expansion of teaching (e.g. via Software Carpentry courses), education and events on the topic of (computational) reproducibility, the establishment of an RSE Master program (e.g. via the Elitenetzwerk Bayern) and an award for good, sustainable, and open research software. It became clear that many people would like to continue to meet and to support the topic, both in a relaxed atmosphere at regulars’ tables and in working groups or events where concrete goals are tackled. A big thank you goes to the Leibniz-Rechenzentrum and the director Dieter Kranzlmüller for hosting. His team was not only represtented strongly but the data center also provided plenty of snacks and drinks. The day was rounded off with a visit to the Augustiner in Garching, where further conversations were fuelled by savoury dishes, beer, and a nice atmosphere, networks were built, and more ideas were collected. It is simply wonderful when you are no longer lonely and have found a nice group in which you feel understood. Everyone is welcome to join the Munich RSE Mailing List. We are looking forward to new members!

In Münster Daniel Nüst and Stephan Rave also initiated a first informal meeting. 16 interested people met in the pub “Kruse Baimken”, which exceeded all expectations of the organisers, too. Some participants strengthened themselves with typical Westphalian kale while a detailed round of introduction was completed in a relaxed atmosphere. Various faculties and institutes (chemistry, bioinformatics, mathematics) were represented, but common ground was quickly found in the challenges and problems faced by many: How can I develop my career if I program the whole day? How can I develop software sustainably and effectively? How can I publish my work as open source software? How do I communicate with non-programmers about features and requirements? The lively exchange continued until the “last order” was called, though the time did not suffice to come close to discussing solutions. Small individual steps as well as larger changes in cooperation with faculties and the university seem to be necessary, which can be tackled together from now on. To organize further meetings, an ms-RSE mailing list and a chat group were created on the university’s internal Mattermost server and first topics in an Etherpad were recorded. Daniel and Stephan look forward to more members and suggestions!

Local chapters offer a perspective for the newly founded association de-RSE e.V. to develop a broad impact, for example by supporting further education offers, and with an effective flow of information between the association and the universities and research institutions in Germany. Heidi and Daniel look forward to your suggestions for the organization of regional and local chapters (What do you need?) [on GitHub] (https://github.com/DE-RSE/chapter).

Is there a local group with you? Then add them to the list on GitHub.

Are you thinking about organizing an RSE meeting in your city? Here are a few tips:

Umfrageverteilung 2018 in Deutschland

Post only available in German

Stephan Janosch, January 29, 2019

Ähnlich wie im letzten Jahr kann auch die Beteiligung an der RSE-Umfrage 2018 grafisch dargestellt werden. Das Clustering summiert die Beteiligungen der einzelnen Institutionen. Die Zahl gibt an, wieviel Antworten von wo zur Studie beigetragen haben.

Hinweis: Dieses mal liessen sich nur 268 von 333 Beteiligungen zu verorten.

Hinweis 2: Falls der Feedreader die Karte nicht interaktiv anzeigt, dann bitte den Beitrag im Blog direkt anschauen.

de-RSE association founded in Berlin

Stephan Druskat, Frank Löffler, Bernadette Fritzsch, Martin Hammitzsch, Daniel Nüst, Stephan Janosch, December 20, 2018

The German community of Research Software Engineers finally has a new home: On Monday, 26th November 2018, the association de-RSE e.V. - Gesellschaft für Forschungssoftware was founded at the Interdisciplinary Laboratory Image Knowledge Gestaltung at Humboldt-Universität zu Berlin.

participants

The community now has a framework to bundle all its activities around research software. During the inaugural meeting, the 21 participants discussed and passed the association charter and its bylaws.

voting

They further elected the six members of the association board, who went on to initiate the formal registration with the register of associations of Berlin.

The founding board consists of Frank Löffler (Friedrich Schiller University Jena, chairperson), Daniel Nüst (University of Münster, deputy chairperson), Stephan Janosch (Max Planck Institute of Molecular Cell Biology and Genetics Dresden, treasurer), Martin Hammitzsch (German Research Centre for Geosciences Potsdam, deputy treasurer), Bernadette Fritzsch (Alfred Wegener Institute Bremerhaven, secretary), und Stephan Druskat (Humboldt-Universität zu Berlin and Friedrich Schiller University Jena, deputy secretary).

founding board

Foundation of the de-RSE Association at Nov 26th in Berlin

Stephan Janosch, October 4, 2018

The time has come: The creation of the official de-RSE association is going to happen soon. We invite everyone who is interested to join us in Berlin on November 26th 2018 to be part of the inaugural meeting, with the chance to become a founding member.

Inaugural meeting

We will meet November 26th 2018 at 11am (doors open 10am) at

Interdisziplinäres Labor Bild Wissen Gestaltung
Im Hermann von Helmholtz-Zentrum für Kulturtechnik
Sophienstraße 22a
10178 Berlin

map

At 2pm the board heads out to a notary nearby to start registration process.

Afterwards we will celebrate the foundation .

For organisational reason we ask you to register your interest to participate in the inaugural meeting.

Wie geht’s, wie steht’s?

Post only available in German

Stephan Janosch, September 4, 2018

Aus aktuellem Anlass habe ich mal geschaut, wie viele Abonennten unsere Mailingliste und Twitter-Folgende de-RSE.org so hat:

mailing list count

Save the date: deRSE19 - Conference for Research Software Engineers in Germany, June 4-6 2019

Martin Hammitzsch, Stephan Janosch, Frank Löffler, Frederieke Miesner, September 3, 2018

Following the success of the First and Second international Conference of Research Software Engineers in the UK, a national conference addressing research software and the people behind in the German research landscape will be held at the Albert Einstein Science Park in Potsdam on June 4-6 2019.

We are expecting a lively mix of 200 attendees from different research domains. The purpose of this national conference is to get together with people who develop software that is used in any field of research. We call these people Research Software Engineers (RSEs), but they exist under many job titles (from postdoctoral researcher to research associate, to faculty).

#deRSE19 is not a standard academic conference. We welcome researchers, but we also want to hear from people who fund, develop, run or maintain research software and may not typically attend conferences. It’s a community conference: get involved and help us build the RSE Community in Germany. So save the date and spread the word to your peers writing software for research.

Stay in touch with us and get the latest updates by registering at konferenz-updates@de-rse.org. We will announce the opening of the calls for sessions soon, followed by the calls for talks, posters, workshops and tutorials by end of this year. Updates about the conference will be available also by @RSE_de at twitter. The hashtag for the event is #deRSE19.

If you have any questions about the conference, please contact the conference organisers at konferenz@de-rse.org.

Kind regards,

The #deRSE19 Conference Committee

Beteiligungphase der Vereinsgründung

Post only available in German

Stephan Janosch, August 8, 2018

Volle Fahrt Richtung Verein!

Letztes Jahr veröffentlichten wir einen Blogpost mit dem Titel “Fahrplan” mit einer Liste die folgenden Punkt enthielt:

  • Satzung, unterschrieben von min. 7 Mitgliedern

Um mit der Vereinsgründung weiter zu kommen, haben wir in der ersten Jahreshälfte eine Satzung und Geschäftsordnung geschrieben. Während der Zusammenarbeit hatten wir auch einen Zeitplan im Hinterkopf:

Der Juni ist schon Geschichte und wir wollen Euch nun die Möglichkeit geben, den erreichten Stand zu sichten und zu kommentieren.

Rückmeldung aus der Gemeinschaft zu Satzung und Geschäftsordnung

In Anlehnung an diverse Vereine mit ähnlichem Aufbau/Aufgaben sind wir mittels Telearbeit zu einem Dokument gelangt, welches Satzung und Geschäftsordnung enthält.

de_rse_satzung

Es wurde versucht eine Satzung zu finden, die es uns erlaubt, unsere Ziele abstrakt zu beschreiben, aber auch gleichzeitig konkret genug ist, um als gemeinnütziger Verein anerkannt zu werden. Eine Satzung ist ein relativ statisches Dokument, welches nach Änderungen erneut eingereicht werden muss. Daher sind konkrete Sachverhalte (z.B. Mitgliedsbeträge) in die Geschäftsordnung ausgelagert, welche mittels Mitgliederversammlungen an neue Gegebenheiten angepasst werden kann.

Und da so ein Verein von seinen (potentiellen) Mitgliedern getragen wird, wollen wir schon in der Gründungsphase transparent agieren und Beiträge zum Dokument ermöglichen. Daher könnt Ihr bis zum 9.9 entweder direkt im Google-Doc kommentieren oder auf Github.

Gründungsmitglied werden

Um einen Verein gründen zu können, sind mindesten 7 Gründungsmitglieder notwendig. Diese treffen sich auf der Gründungsversammlung und beschließen die Satzung, Ordnungen (z.B. Geschäftsordnung) und wählen den Vorstand. Höchstwahrscheinlich wird die Versammlung in Berlin im September/Oktober 2018 stattfinden. Falls Ihr als Gründungsmitglied mit auftreten möchtet, dann seid Ihr herzlich dazu eingeladen. Termin und Ort werden sobald wie möglich veröffentlicht. Interessierte sollten sich in unserem Slack-Channel "Verein" einfinden, um auf dem Laufenden zu bleiben.

Eure,

Stephan Druskat
Bernadette Fritzsch
Stephan Janosch
Martin Hammitzsch
Frank Löffler
Daniel Nüst
Alexander Struck

Research Software Engineers from the Geosciences assemble for the first time at EGU General Assembly 2018

Daniel Nüst, July 30, 2018

On April 12th 2018, the first Research Software Engineers (RSEs) for geosciences meeting was held at the European Geophysical Union (EGU) General Assembly (GA) in Vienna, Austria. The EGU GA is a huge event with over 15.000 people from more than 100 countries. It has a diverse programme with thousands of posters and hundreds of sessions, but what it lacked was an event to bring together scientists who contribute to research software. Daniel Nüst from the Institute for Geoinformatics, Germany, proposed the idea of such an event to a group of regular EGU GA attendees from the German RSE chapter. He was joined by Martin Hammitzsch (GFZ eScience Centre, Germany), Bernadette Fritzsch (AWI, Computing and Data Centre), and David Topping (University of Manchester) as co-conveners for a Townhall Meeting “Research Software Engineers in the Geosciences”. Townhall Meetings, or “townhalls”, are union-wide events. They allow participants to take part in open discussions covering a variety of topics. Townhalls take place in the evening after a full day of regular conference and poster sessions, so the motivation of people showing up is unquestionably high.

For the RSE townhall, it was difficult to stand out in the programme, it being a first time event at a large conference cutting across many domains and 24 divisions, from biogeosciences to seismology and paleontology, with over 600 sessions over the course of a whole week. But searching the submissions some weeks before the assembly for “software”, it seemed clear that software plays an important role for scientists attending EGU as it does of any researcher, so the conveners were hopeful to welcome a few people. And they did! About 40 people from 7 countries representing the wide range of EGU divisions joined the meeting. It was a good mix of seasoned RSE folks and early career scientists as well as senior researchers for whom the topic was relatively new.

The meeting kicked of with a short welcome by the initiator, Daniel, followed by Jens Klump (Science Leader Earth Science Informatics at CSIRO, Australia), Deputy President of EGU’s ESSI Division and advisory board member of the Australian and New Zealand chapter RSE-AUNZ. Both pointed out the relevance of contributions to science made by software and thereby the people contributing to that software in any way.

The motivations for national and international RSE activities were further detailed by three representatives from national chapters. David Topping from UK RSE, the oldest and largest RSE organisation, took a look at the definition of an RSE, at the community history, and its current state in the UK and beyond. Over 15 local groups already exist and more are forming at a high rate, sometimes even competing over members. Martin Hammitzsch presented the German chapter, de-RSE. Initiated only 1.5 years ago, he shared the group’s objectives, how they work to build a community, challenges they face and some lessons learned: a great resource for the attendees from countries without any organisational structure yet. Third up was Niels Drost (Netherlands eScience Center), who introduced the youngest European chapter NL-RSE and its core team, which already generated a considerable reach across the Netherlands.

After the short talks, we took advantage of the group size, had a complete round of short introductions, and enganged in a discussion. We found that one of the big challenges was to reach people engaged in Research Software Engineering (RSEng) activities at their work, especially outside of ESSI, and those for whom the “RSE” label does not ring a bell yet. The need for outreach also applies to holders of an office within the union, to reach better acknowledgements of the needs of RSEs in universities, scientific unions, and at scientific conferences.

Some good ideas came up and we plan to reach out to EGU and ESSI leadership and share them. For example, EGU could increase recognition of RSEs and their work by awarding a medal, by offering a special poster track for contributions to scientific software (allowing an additional “software submission” per author), or by tagging abstracts as “RSE” similarly to the “ECS” labels. These are ideas for “top-down” activites that we would like to advocate within the organisation. The usefulness and overall potential of such domain-specific (taking all EGU members as a group for a moment) actions, who are lateral to the national chapters, was commonly agreed on.

But there were also ideas for “bottom-up” activities which can support the RSE organisations’ causes, for example scientists organising sessions related to RSE roles and activities within their divisions, offering short courses specifically around RSEng capabilities (and also labeling the numerous existing courses as such), or organising software and data carpentry courses in the week before or after the conference. One participant suggested a session “Software development for professors - what do my students do with their computers?”, which seems funny at first, but at a second look goes to the heart of RSE outreach activities for raising awareness and teaching software-related skills. It was great to follow the lively discussions, which were enriched with a common understanding of the values and importance of diversity and openness. If you think about convening a session on scientific software yourself at an EGU GA, please get in touch!

An important aspect of structured RSE activities are surveys, because the people self-identifying as RSE are diverse and wide-spread and the roles that RSEs play in scientific research are manifold. We want to contribute to the process of understanding the needs and diversity of people involved in RSEng with the following survey on EGU attendees:

https://nuest.staff.ifgi.de/survey/index.php/598158?lang=en

The townhall meeting was a good start to spreading the word about the goals of RSE organisations and the activities to put Research Software Engineering on the map of all stakeholders in science, such as researchers, publishers, funding agencies, and scientific unions. What can we do better next year? Hopefully we can do what more “established” townhalls can offer: snacks and drinks! We should also announce and prominently place a sticker table. Apart from that, this first townhall did an excellent job, just like other long-running townhall meetings at EGU GA: It provided a place for like-minded people to connect and for newcomers to dip their toes into a new topic and be introduced to members of an international friendly community of dedicated people who “do science with code”.

The slides (download all slides here) include many links to further resources on the history and state of RSE-related activities. Please let us know what you think on Twitter: #egurse. See you at the RSE Townhall Meeting at EGU 2019!

RSE Townhall Conveners

Daniel Nüst
Martin Hammitzsch
David Topping
Bernadette Fritzsch

Verteilung der Umfrage in Deutschland

Post only available in German

Stephan Janosch, March 6, 2018

Die Auswertung der Umfrage geht langsam voran, hier schon einmal die geographische Verteilung der Antworten. Das Clustering summiert die Beteiligungen der einzelnen Institutionen. Die Zahl gibt an, wieviel Antworten von wo zur Studie beigetragen haben.

Hinweis: Die Koordinaten der Institute stammt aus Wikidata. Da dort nicht immer Koordinaten hinterlegt sind oder meine Abfrage die Institution nicht erfasst haben mag, sind hier nur 269 von 325 Beteiligungen zu sehen.

Nachtrag: Statisches Bild für Betrachter ohne Javascript hinzugefügt.

Digital Humanities im deutschsprachigen Raum gründen AG DH-RSE

Post only available in German

Stephan Janosch, March 1, 2018

Anfang diesen Jahres überraschte Stephan Druskat mich mit einer Einladung, die Keynote für dem RSE-Workshop auf der Jahrestagung der digitalen Geisteswissenschaften (Digital Humanities, DH) zu halten. Der Workshop sollte 30 Personen Platz bieten, doch die Sache entwickelte sich anders.

Die folgende Wortwolke der Tagungseinreichungen zeigt deutlich, dass Reseach Software Engineering kein Mauerblümchendasein mehr fristet.

Wortwolke der Konferenzeinreichungen
Wortwolke der Tagungseinreichungen (Quelle: http://dhd-blog.org/?p=9001) mit Hervorhebungen von mir

Wegen einer “Kommunikationspanne” meldeten sich 105 Personen an und überwältigten die Ausrichter förmlich mit Interesse (in Relation: ca. 600 Tagungsteilnehmer gesamt). Trotz der eisigen Temperaturen in Köln folgten ca. 80 Anwesende Torsten Schrade zu Beginn, der eine Auswertung einer Umfrage zur Kartierung der Entwicklergemeinschaft vorstellte, die von den Veranstaltern im Vorfeld lanciert wurde. Es offenbarten sich Parallelen zur unserer letztjährigen Studie. Mit meiner anschließenden Keynote versuchte ich die Stimmung zu heben und die Motivation für den folgenden Teil zu schärfen.

Es folgte nun ein zweigeteilter Arbeitsblock in 11 Gruppen, bestehend aus einem 45 minütigen Diskussionsteil und weiteren 30 Minuten zum Fixieren der Diskussionsergebnisse in Form von Speed-Blogging. Alexander Czmiel achtete darauf, dass Räumlichkeiten und Zeit maximal ausgenutzt werden konnten. Folgende Themen wurden mit von Gruppen bearbeitet:

  1. Softwarenachhaltigkeit: Gemeinsame und unterschiedliche Definitionen aus Sicht verschiedener Institutionen
  2. Institutionelle Kulturen und Workflows der Softwareentwicklung: Gemeinsamkeiten und Unterschiede
  3. Aktuelle Situation der Softwareentwicklung in den digitalen Geisteswissenschaften
  4. Was kann eine AG DH-RSE in der DHd leisten?
  5. Ausbildung, Training, Software Carpentry: Situation, Fallbeispiele und Initiativen
  6. Best Practices der wissenschaftlichen Softwareentwicklung: Bestandsaufnahme und Vergleich
  7. Infrastruktur: Welche institutionsübergreifenden Infrastrukturen brauchen wir für eine professionelle Softwareentwicklung in den digitalen Geisteswissenschaften?
  8. AG DH-RSE: Struktur, Infrastruktur, Workflows
  9. (DH-)RSEs: Situation, Anerkennung, Karriere
  10. Softwaredokumentation: Stellenwert, Praxis, Infrastruktur
  11. Softwareentwicklung als wissenschaftliche Leistung: Situation, Anerkennung, Workflows

Eine gegenseitige Kurzvorstellung der Ergebnisse schloss diesen Block ab. Die entsprechenden Blogeinträge werden ab April im dh-RSE-Blog erscheinen.

Teilnehmer dh-rse workshop 2018
Teilnehmerfoto

Für mich überraschend wurde zum Ende des Workshops noch die Gründung der “AG Research Software Engineering in den Digital Humanities (im DHd-Verband)” bekanntgegeben. Die AG bezweckt RSE-bezogene Fragen innerhalb des DHd-Verbandes zu bearbeiten und ansonsten eng mit de-RSE zusammenzuarbeiten. Damit scheint ein prototypischer Weg gefunden worden zu sein, wie innerhalb der vielfältigen deutschsprachigen Forschungslandschaft zusammengearbeitet werden kann. Ob die Geowissenschaftler einen ähnlichen Pfad auf ihrem EGU-Townhall-Meeting der RSEs einschlagen bleibt abzuwarten.

English Summary

A research software engineering working group (DH-RSE) within the DHd-Verband has been founded at the yearly conference of Digital Humanities in German speaking countries. The foundation was paired with a workshop which saw ~80 faces. The working group will closely collaborate in with de-RSE.

Founding an Association

Stephan Janosch (translation Daniel Nüst), January 23, 2018

Ever since we have come together as a community to create de-RSE for the everyday support of our work, one question has always been on the table: What organisational and legal form is suitable for the realization of our goals?

It seems clear that a loosely coupled group of willing people will not be able to build supportive structures for the long term, for example:

An impromptu meeting at the 2nd S3 conference in Hannover, May 2017 (recordings) Hendrik Eggers (TU Braunschweig) suggested the foundation of a cooperative besides the creation of a registered association.

Bernadette Fritzsch (Alfred-Wegener-Institut, Helmholtz-Zentrum für Polar- und Meeresforschung) has taken up these first ideas and started a series of telephone conferences in autumn 2017.

Current situation

Three conference calls by a core group of seven members later, we have come to the conclusion that the creation of a registered association is more suitable. Collaboratively (Slack channel #verein) we are developing a charter and rules of operation (both in German). The ultimate goal is a registered non-profit association, which utilises modern technology to allow for distributed collaboration. Additional collaborators are always welcome!

Name

What should that association be named? The abbreviation “de-RSE” seems set. The term Research Software Engineer establishes itself more and more, also internationally (just out: nl-RSE.org), and is not going to disappear any time soon. But there are also the German job titles of “Wissenschaftler” and “Ingenieur”, which seem to contradict each other at first glance, although both may include software development.

At the moment the charter repository includes three suggestions:

Personally, I favour a mixture, maybe de-RSE e.V.: Förderverein für Forschungssoftware und wissenschaftlich Software Entwickelnde? Maybe you, dear reader, have an illuminating idea for naming our association. The name is going to be widely used in a number of noteworthy contexts:

We look forward to your feedback on the mailing list and in the chat (ideally till Feb. 5th).

And since we’re already here, let’s address another important topic.

Membership fees

Until now, the question of membership fees has rarely been mentioned. But where there are eggs to be broken for an omelette, these eggs need to be laid first. And some forms of third-party funding require a certain level of existing initiative, i.e., own resources. We hope the search for a name is a good occassion for everyone to think about their personal opinion on financial support. Everything is possible:

If I were asked today, I would be ready to pay € 10 per month, roughly the fees my sports club charges me to take care of my health.

We belatedly wish you a good start to 2018 and look forward to your thoughts on the association’s name.

How is survey?

Stephan Janosch, November 15, 2017

Did fill out the survey? Yes, great!

So let’s check quickly how many people filled it out as well.

survey responses

Not bad, there are almost 300 answers! But on the other hand I only see 3 persons per university creating research software in average, which seems a bit odd.

Let’s see how many more people can answer the survey till end of the year.

Survey about research software in Germany, and the people involved in it - #deRSEsurvey2017

Stephan Janosch, October 19, 2017

Hello,

Do you develop research software, or are you involved in the scientific software creation process? Then we would very much like you to participate in the following survey:

https://softwaresaved.limequery.com/661559?lang=en

As of now there is not much knowledge about the community of those in research and science who develop software. This survey aims to gain valuable insights into this community in order to support research funders and other institutions to develop strategies and funding programs as well as policies.

This survey gives you the opportunity to make your point of view and experiences be heard, and thus be part of the development of this community.

In case you know others who develop software in research, please feel free to forward this invitation. If you forward this mail to a mailing list, please be so kind and copy in Martin (janosch@mpi-cbg.de) and Stephan (martin.hammitzsch@gfz-potsdam.de).

The survey results will be published under a CC BY-NC license, and will be announced and evaluated via the de-RSE mailing list and the de-RSE blog. Simultaneously, similar surveys are conducted in the UK, Canada, Australia, Norway, the Netherlands, the USA and South Africa. For reasons of comparability, this survey was closely coordinated with the others.

We look forward to your participation in the survey!

Many thanks, Martin Hammitzsch and Stephan Janosch

survey research software 2017

How to assign a DOI to software within MPG

Stephan Janosch, May 8, 2017

This post will explain how you can assign a DOI to a piece of software within the Max Planck Society (MPG). I need to restrict the scope to the MPG, because the access to the DOI service of the Max Planck Digital Library is restricted. If you plan to release on Github, then the guide ‘Making Your Code Citable’ helps you along.

1. Landing Page

One requirement for assigning the DOI is a public landing page. In my case I simply used the landing page of the project in our local GitLab installation.

gitlab project page

2. Fill DOI Request Form

Next you head over to https://doi.mpdl.mpg.de/request-doi/ and fill out and submit the form.

mpdl doi service form

3. Confirm Request

The MPDL did choose an request confirmation via email. So will receive an email like that which you return to DOI helpdesk. Then you wait for the confirmation to take place.

Dear …,

your eMail address was used to request a DOI name via the Max Planck Digital Library (MPDL). To confirm that a DOI name should be registered on your behalf for the content item described below, please return the complete eMail to doi@mpdl.mpg.de.

…

In addition, you confirm that all information provided is correct and permit the MPDL to store the data locally. You also agree that the location URL and bibliographic metadata will be transfered to the German National Library of Science and Technology (TIB) in order to register the DOI name. The TIB receives the metadata under the conditions of the Creative Commons CC0 1.0 Universal Public Domain Dedication.

Best regards, your DOI helpdesk in the MPDL

4. Receiving the DOI

After a while, you will receive the DOI with a nice hand-craftet mail. Done.

Lieber Herr Janosch,

vielen Dank fuer Ihre DOI-Anfrage. Fuer das Software-Paket wurde soeben die DOI 10.17617/1.46 vergeben und in wenigen Minuten sollte https://doi.org/10.17617/1.46 auf die gemeldete URL umleiten.

With a few clicks more you can link your freshly minted DOI to your ORCID record.

So open your ORCID profile and hit ‘Add Works’ -> ‘Search & Link’ -> ‘DataCite’

orcid profile add content

After you allowed the DataCite to connect to your ORCID profile, you can ‘Search’ for your works.

datacite home

Two clicks more on ‘Add to ORCID record’ and ‘OK’ completes the process.

datacite add to ORCID record

Question 1: Software vs Release

Software appears in different manifestations. You could refer to it as a specific release of your code (e.g. version 0.3 of the plugin) or as software engineering project. If you are interested in the citation count you want to have only one DOI for your software. Opposite to this, you want to have a DOI for each release of your code. This ensures that protocols or workflows cite the exact version used in order to prevent reproducibility issues.

The DataCite Metadata Schema (version 4 pdf) knows some very handy relation types like:

  - IsNewVersionOf 
  - IsPreviousVersionOf 
  - IsPartOf
  - HasPart

It looks like, that Zenodo makes use of these, as this example shows. I will try to speak with Martin Fenner (DataCite), who is giving a talk with the topic ‘Workflows for assigning and tracking DOIs for scientific software’ this wednesday, to get a better idea about metadate for software.

Question 2: Changing Landing Page URL

According to the MPDL personell there is no interface right now for changing the landing page URL. Their advice was sending an email to the DOI helpdesk and submit your changes that way.

Summary

As you can see, assigning a DOI to a piece of software is not very hard. The easy interface provided by the MPDL helps a lot, but maybe an expert version of it is more appropriate for software? And it takes a bit patience because there is some waiting involved (explaination?). But the process in general is straight forward.

Feel free to discuss this topic at our communication channels (mailing list and/or slack). In case you have the desperate need to document the DOI assigning process for your own research organisation then head along and copy this post and push a pull request to our website repo. 😉

Fahrplan

Post only available in German

Stephan Janosch, Martin Hammitzsch, April 28, 2017

de-RSE als Bewegung hat Ziele, für deren Erreichung nicht nur persönliches Engagement gefragt ist, sondern auch finanzielle Unterstützung für die geplanten Aktivitäten wie Workshops, Fellowship Programme oder eine jährlich stattfindende Konferenz. Eine derzeit diskutierte Idee soll hier kurz skizziert werden. Darauf aufbauend wünschen wir uns eine Diskussion, die diese Idee und eventuell andere Alternativen betrachtet, um in der Community zu einem Konsens zu kommen und handlungfähig zu werden.

Vereinsgründung

Um als Vereinigung von Leuten mit Geld/Ressourcen umgehen zu können, braucht es eine Körperschaft. Die Idee der Gründung eines gemeinnützigen Vereins liegt hier nahe. Um einen rechtsfähigen Verein gründen zu können braucht es folgende Dinge:

Mit einer strukturierten Vorbereitung wäre dies evtl. bis Herbst diesen Jahres machbar. Die Satzung könnte beispielsweise gemeinsam in einer Markdown-Datei geschrieben werden und regelmäßige Webkonferenzen helfen, diskussionsbedürftige Textbausteine anzugehen sowie weitere Aktivitäten abzustimmen. Falls nötig können wir abschließend auf einem eigens einberufenen Meet-up oder bei einer Konferenz die Gründung durchführen, so dass ein Vorstand berufen und der Verein gegründet werden kann. Alles weitere liegt dann beim Vorstand, der die geplanten Aktivitäten gemeinsam mit der Community angeht.

Budget

Für Konferenzen, Workshops und Stipendien (fellowships) braucht es Geld. Stellt sich die Frage, wie sich de-RSE nachhaltig finanzieren kann. Gestaffelte Mitgliedsbeiträge sind hierbei ein erster Anfang. Mitglieder und deren Beiträge könnten sein:

Mitglied möglicher Beitrag pro Jahr
natürliche Person 50-100 €
Institute und Universitäten 1.000 € - 5.000 €
Firmen 10.000 €

Wir gehen am Anfang von einem Übergangsprozess aus, von der Gründung mit vielen natürlichen Personen hin zu einer stabilen Einnahmesituation durch institutionelle Träger. Denkbar sind darüber hinaus finanzielle Förderungen durch:

Ausblick

Im Moment hat die Mailingliste fast 70 Abonnenten, was genug Potential für eine Vereinsgründung vermuten lässt. Nun würden wir uns aber erstmal eine lebhafte Diskussion über diesen Fahrplan erwünschen.

Welcome to the de-RSE blog

Stephan Druskat, March 22, 2017

This weblog will contain posts on subjects that are relevant to the Research Software Engineers community.

You, too, can contribute (in English or German). Simply clone this website’s GitHub repository, check out the README (we use Jekyll, and it’s easy to create and publish drafts with rake), create a blog post, and submit it to us via a GitHub pull request against master!

Happy reading, happy contributing!


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