# The role of the R community in the RSE movement

## Blog post (output)

<start blog here></start>

## The role of the R community in the RSE movement

[for SSI] *Cross-posted from the blog of [useR! 2021](https://user2021.r-project.org/), the leading international R conference, held online between July 5 and July 10 2021.*

[Heidi Seibold](https://twitter.com/HeidiBaya) proposed an incubator session on “The role of the R community in the Research Software Engineer movement” to accompany her useR! 2021 keynote: ["Research software engineers and academia"](https://youtu.be/dag9l0GFci8?list=PL4IzsxWztPdmHoJwIVa4um44w2GMjctmP). An incubator session allows small groups of people to discuss a topic that interests them in a way that helps people learn about new ideas and work together on solving shared problems. A group of people ([Heidi Seibold](https://twitter.com/HeidiBaya), [Emma Rand](https://twitter.com/er13_r), [Heather Turner](https://twitter.com/HeathrTurnr), [Nicholas Tierney](https://twitter.com/nj_tierney), [Jan Dietrich](https://twitter.com/tscheypidi), [Anelda Van der Walt](https://twitter.com/aneldavdw), [Olina Ngwenya](http://www.cidri-africa.uct.ac.za/cidri-africa/about/staff), [Matthias Bannert](https://twitter.com/whatsgoodio), [Anna Krystalli](https://twitter.com/annakrystalli), and [Jochen Schirrwagengot](https://www.linkedin.com/in/jochen-schirrwagen-280799106/)) got together to plan the session.

The incubator plan (Box 1) was adapted from the discussion sessions held at [The Software Sustainability Institute’s Collaborations Workshop](https://software.ac.uk/cw21/discussion-session), which aim to produce a collaboratively written blog post. As the incubator was a much shorter session (only 45 minutes for collaborative work versus 1.5 hours), we planned for participants to summarise their discussion in a few bullet points.

:::info
**Box 1. Incubator plan**
::: spoiler

Adapted from [The Software Sustainability Institute’s Collaborations Workshop](https://software.ac.uk/cw21/discussion-session).

<!--  -->

*Schedule and topics*

The incubator will take place 16:00-17:00 UTC Tuesday July 6. Breakout topics will be proposed in advance by session organizers.

*How does it work?*

Zoom breakout rooms and a [HackMD](https://hackmd.io/) pad will be created for each topic. Facilitators will be solicited for the topics in advance of the session.

Participants join the breakout room for a topic that interests them. If no one else joins after a few minutes, they join a different room.

The breakout room discussion session lasts for 45 minutes. That's not enough time to discuss the subject in depth, but it's about the right amount of time to develop some common thoughts and summarise them.

*What to do*

Start the first 5 minutes by opening the HackMD for your group. If you are willing to share the information, add your name, affiliation and email at the top. Decide as a group whether you prefer spoken or written discussion.

For a spoken discussion, choose a Reporter to take notes. Then allow 30 minutes for discussion without worrying about writing the summary. Once the 30 minutes is up, work together to write a summary for the final 10 minutes.

For a written discussion, everyone edits the HackMD. Allow around 15 minutes for idea generation, 15 minutes to comment on each others ideas and 10 minutes to work a summary.

The summary is a few bullet points which give the main themes of the discussion.

The facilitator will guide the discussion by getting the discussion started, keeping the discussion on topic and giving different people a chance to contribute.

*Reporting back*

There is no formal reporting back session at the Incubator. The summaries will be pulled together in a blog post after useR! to share with the community.
:::

Topics for discussion were proposed by the session organizers in the run-up to the conference (Box 2).

<!-- skip this as didn't generate any new ideas! and we also circulated these on social media to allow suggestions to come from the community. -->

:::info
**Box 2. List of proposed topics**
::: spoiler
1. Many R developers probably qualify as RSE but don’t know this term or the RSE community. How can we increase visibility of RSEs in the R community? Should we?
2. R is less visible in the RSE community than, for example, Python. How can we increase visibility of R in the RSE community? Should we?
3. Could we develop a podcast on ‘meet the R-engineers’ or collaborate with an existing R podcast? What suggestions do you have for interviewees?
4. What should a book "Research Software Engineering with R" contain?
5. How can we reward people for writing software / publishing code? Is there a reward mechanism for producing software where you work? If so, what is it? Does it work?
6. What does an RSE who uses R do? What are common tasks you perform in your role?
7. How do we develop an RSE for R users community? What resources and techniques could help build communities of practice in this group?
8. What does "Research Software Engineer" mean to you? This role and terminology are not universal. Are these [UK](https://society-rse.org/) and [US](https://us-rse.org/) definitions appropriate for your role? What would you modify?
9. How do you help build intermediate software engineering skills and help people go beyond the basics?
10. How can we identify and highlight which funders are most research software friendly?
11. What can other RSEs learn from the R community? E.g. a common archive, structure of packages, etc.
12. How can we promote RSE career paths?
13. What are R's strengths in terms of infrastructure, workflow, and software testing and community? How do these differ to other communities and what can we learn from other communities on these topics?
14. How to show off what R is doing well?
:::

The incubator was held on Tuesday 6 July and around 30 people participated. Heidi, Matt and Heather chaired the session and [Faith Musili](https://twitter.com/musili_faith) hosted the session on Zoom. We were also joined by guests [Ania Brown](https://society-rse.org/about/governance/anna-ania-brown/) (RSE at the University of Southampton, UK and Trustee at the [Society of Research Software Engineering](https://society-rse.org/)) and [Mario Antonioletti](https://www.software.ac.uk/about/staff/person/mario-antonioletti) (RSE at [Software Sustainability Institute](https://www.software.ac.uk/), UK).

The session began with a welcome from Heidi Seibold, followed by short talk on the RSE movement from Ania Brown.

[Ania Brown's talk "Society of Reseach Software Engineering" on YouTube.](https://youtu.be/Xhwh80aTF0k)

We then directed people to move into breakout rooms titled by the topic, recommending to join another room if no one else joined after a few minutes. In the end, we had small groups discussing seven of the proposed topics. We have pulled together the summaries for these topics below.

## How can we increase visibility of RSEs in the R community? [(notes)](https://hackmd.io/U3tkYC6LQnutitBZuPYbPQ)

Many people in the R community do not know what an RSE is or identify as an RSE when they could! Our discussion had two main threads:
1. **Promoting RSE as a discipline/career**
- Share relevant talks on social media, e.g. [Mike Crouchers keynote at JuliaCon 2018](https://youtu.be/8ZSaAM8hhJ4).
- Invite RSE speakers (especially R users) to R events.
- Share RSE event announcements/listings.
- Participate in mentoring (the RSE Society is announcing a mentoring scheme at [SeptembRSE](https://septembrse.github.io/#/event/T1026)).
- Share RSE jobs (the RSE Society has a [vacancies](https://society-rse.org/careers/vacancies/) page).
- Apply for funding to support RSE work/outreach (some potential funders: Society of RSEs, CZI, CodeforScience and Society, Wellcome Trust, Gordon and Betty Moore Foundation.)
2. **Identifying as an RSE/building community**
- Join your local [RSE Association].(https://researchsoftware.org/assoc.html) (the UK-based Society of Research Software Engineering is open to international members and has a [LinkedIn group](https://www.linkedin.com/groups/13564426/)) and/or the [RSE Slack](https://society-rse.org/join-us/#slack) (we created an #r-users channel after the incubator)
- Create RSE channels on R Slacks, e.g. [R-Ladies community Slack](https://rladies-community-slack.herokuapp.com/).
- Use the #RSEng hashtag on Twitter (with #RStats, #RStatsES etc).
- Write RSE-related posts on R blogs.
- Create newsletter for R + RSE community.
- Start/contribute to podcast (c.f. Topic 3 breakout!).

## Could we develop a podcast on ‘meet the R-engineers’ or collaborate with an existing R podcast? ([notes](https://hackmd.io/G-g2oK32RWu3dWeZC6EjyQ))

- Conflicting views on preferred content/focus:
- Developers' stories as RSEs vs applied help on concrete issues.
- Research vs software.
- Should be distinct from existing series, mostly Why R? Webinars.
- Podcast vs. YouTube: longer, less technical formats, more content vs better reach, shorter clips with visual support when explaining things
- New things call for new people, existing community leaders can't be the ones starting new things. Connecting to other existing outlets could be a chance:
- [Bioconductor Developer's Forum](https://www.youtube.com/playlist?list=PLdl4u5ZRDMQQLMupAtEzm2y4gUIUm_1n6) (Monthly teleconference with RSE content)
- [Why R? Webinars]( https://www.youtube.com/watch?v=3RkBEva4xRk&list=PLKMUlj_pGn_ldSI9_xIae6tOozrMNYa96)
- [RSE Stories podcast ](https://us-rse.org/rse-stories/posts/) - chance to pick this up as Vanessa Sochat is looking for a [new co-host and other volunteers](https://us-rse.org/2021-07-27-newsletter/) to help with production.

The RSE Stories podcast is more-or-less exactly what I had in mind when I suggested this topic. It tells stories of different people working in RSE. As this has been an U.S. effort mostly, a collaboration or European / African version could be a reasonable starting point. A take away from the incubator could be that we use our network and mentoring capacity to find a new co-host, perhaps an African / European counterpart.

## What should a book "Research Software Engineering with R" contain? ([notes](https://hackmd.io/Nj3hRSYgSfeWzg_EJ0TevA))

We had a wide ranging discussion about what such a book could and should contain. We identified several different approaches and topics which could form the basis of multiple books or major sections within one book. Three themes emerged:
1. Materials covering the fundamental practical and technical elements that would allow R users to become software engineers using R. This could be similar to [Research Software Engineering with Python](https://merely-useful.tech/py-rse/) by Damien Irving, Kate Hertweck, Luke Johnston, Joel Ostblom, Charlotte Wickham, and Greg Wilson, which itself draws on many workshops by [The Carpentries](https://carpentries.org/). It might cover universal tools such as the unix shell, git, and pipeline toolkits (including R specific ones like `targets`) and package development, testing and deployment. In addition, it could cover thinking like a research software engineer and how to be a good contributer.
2. Materials explaining the benefits of R-focused RSE to R users and to existing RSE teams. [The Turing Way](https://the-turing-way.netlify.app/welcome.html) handbook to reproducible, ethical and collaborative data science covers much of this very well and it might be sensible and productive to contribute the R-specific perspectives there.
3. More advanced topics likely to be useful for R-using RSEs, such as managing memory, big data, cloud and parallel computing, database connectivity and data products such as Shiny dashboards

## What does an RSE who uses R do? ([notes](https://hackmd.io/mQj62-eTShuMm5jbc2VlHw))

Two of us (Anna Krystalli and Nick Tierney) shared similar paths to becoming an RSE: starting out in research, really enjoying the software aspect of our work, and gradually becoming more focussed on the software aspects of the research process. A common theme was the need for empathy in the design of software and documentation - we wanted to make software that enabled researchers to do their job more efficiently, rather than spend time learning the nuances and minutiae of software to complete their work. We discussed some common daily tasks: cleaning up data, automating repetitive tasks, writing R packages for analyses, developing documentation for existing projects, and encouraging new users.

Others in the group shared what they do in their role, which wasn't always officially "research software engineer". This included: creating analysis templates (e.g., this package of [R markdown styles and templates for official reports](https://github.com/inbo/inbomd)); building tools or R packages to perform statistical analyses; developing checks for code quality (see the [checklist](https://inbo.github.io/checklist/) package), and storing or sharing data in an open format under version control (see the [git2rdata](https://ropensci.github.io/git2rdata/) package).

Finally, we discussed how to get started as an RSE. Some ideas we came up with were to start teaching software to your research group, or to find common tasks that might be repetitive or annoying for other researchers and to explore ways to automate or simplify these processes. As for the skills needed to get started as an RSE, we believe if you like research, but are also interested in how software is used by other researchers, that should form a great base to start on the path to becoming an RSE. You do not need to have a background in software engineering, although it certainly wouldn't go astray! We believe the more important side of an RSE is knowing the context of the areas of research and how it is conducted. It is this blend of having research experience, interest in software, and desire to improve research experience, that helps form a base for being an RSE.

## How do we develop an RSE for R users community? ([notes](https://hackmd.io/sYxKitzBSrG2UKclMyBuLA))

Some thoughts and ideas from this group were:

- Find interested people and set up a core team (probably the most difficult issue).
- Make the RSE concept explainable to interested people, e.g. by writing a manifest.
- Identify crosscutting topics in the RSE and R communities (e.g. Open Science/Data).
- Invite R users to RSE events and vice versa.
- Start with user stories as in the RSE Stories podcast.

## How can we identify and highlight which funders are most research software friendly? ([notes](https://hackmd.io/SjNn5pfuTvS80zNu0cinKg))
The scope of the topic was widened somewhat to finding funding (or effort) to help maintain a successful existing project. Although most funders are happy to provide seed capital to create or support an existing piece of software it is best to diversify revenue streams to help support a piece of software and not to rely on an existing single source of funding. With this in view:

* It is important to build networks to become aware of opportunities and how to exploit them. The RSE movement is such a network to join.
* Use connections with Master/PhD programmes to help develop focused functionality. If your project is open source you can try the [Google Summer of Code](https://github.com/rstats-gsoc/) to sponsor a student.
* Use a donation button (but it provides no continuity in the funding stream).
* Consider a dual licensing scheme for commercial/academic use.

## How can we promote RSE career paths? ([notes](https://hackmd.io/Ra1zreGLTcuvv5IbtWb__A))

We had a lot of discussion about the fact that research software does not "count" as achievement in academic contexts (industry may vary?), but only paper publications do. What can help to change this?

- Teach / learn about research software and its importance.
- Make software a first class citizen in science (count it as a valuable research output).
- Value maintainance of software

We also talked about what could help RSEs in their career path.

- Allow for less stiff career paths in science, e.g. introduce RSE career path in addition to careers as researcher, librarian, etc.
- Offer permanent/prestigious positions and group leader positions.
- Make term RSE more widely known.

We found it important to invoke change both top down and bottom up.

**Bottom up:** Build grass-roots communities.
**Top down:** Institutions, funders, and journals have the power to make change.

<end blog here></end>

---

# The event planning

## The event: what is it about?

* Tu 06.07 at 4:00PM UTC; 1 hour session
* Incubator: The role of the R community in the RSE movement
* More info: https://hackmd.io/dfEKX_cnSsiiQ7SRCaX4zQ?edit
* Potentially many attendees (Heather expects ~100)

## Tasks:

* Publish topics of the session on the website in advance + allow others to add ideas (e.g. through gsheets, miro, hackmd; Heidi checks) -> a week in advance
* We should promote the event before registration for the conference closes (which is this week)
* Emma looks at [potential questions](#Potential-topics) in the session (see also bottom of the doc) and [intructional infrastructure](#Instructions-for-participants) **Initial drafts DONE**
* Nicholas supports in questions to discuss
* Heidi to look into options for recording the outputs eg miro, hackmd, ...
* Matt publishes stuff on the website; streamlines what comes in
* Olina promotes the event through local R user groups
- [X] SSA group in Australia
- [X] Monash University
- [X] Telethon Kids Institute
- [X] RSE mailing list in Australia/NZ
* Finalise promotion heading below
* Finalise abstract below
* Heather
* Checks about the Zoom host. **DONE**: our host is Faith Musili (Kenya), with Rachel Heyard (Switzerland) as a backup Zoom Host
* check limitation on number of breakout rooms **DONE**
* Max **50** breakout rooms
* In theory, if we open 10 rooms, everyone can pick to join room 1. But I think it is possible to see how many people are in a room before you join, so we could recommend that people don't join if there are already 10 people, say. Or perhaps, we want to keep it open choice, to get an idea of the popularity of each topic! Suggest we ask people to sign up before and do as much of the room allocation beforehand as possible?
* Asks contacts at UK SSI if they'd like to join in and possibly give a brief intro at the start. **DONE**
* Claire Wyatt will give the RSE intro and Mario Antonioletti will participate as the main SSI R user.
* Checks on incubator promotion
* A tweet will go out this week **DONE** https://twitter.com/_useRconf/status/1408319045905141760 (tweeted by official useR! account 25 July 2021).
* Promotes session **DONE BUT PLEASE SHARE MORE WIDELY**, see [Promotion](#Promotion).

## Background

What is an incubator? https://docs.google.com/document/d/1l_fbZqJlep6yMZoKHHigKlOE_Wj1dSbRXpkbxbmzu8o/edit

## Abstract (TODO)

Motivation (from Heidi)

At RSE events I keep showing the R community off as a community that has sort of figured out software standardization, publication and archiving. So maybe we could use that. Also the R community is quite organized so we could make a difference and help making RSE career paths a reality in many countries.

Submitted version:

The term "Research Software Engineer"(RSE) was proposed by a group of software developers working in academia at a workshop in Oxford, UK, 2012. It was the beginning of a grass-roots movement to establish Research Software Engineering as a profession for people that combined expertise in programming with an intricate understanding of research. Since then, the movement has grown substantially, leading to recognition, reward and career opportunities for RSEs and the creation of national RSE associations in Australia/New Zealand, Belgium, Germany, the Netherlands, the Nordic region, the UK and the USA.

This incubator will provide an opportunity to discuss the role of the R community in the RSE movement. What can we share with this wider community? How can we help the movement grow? What could the R community gain from this movement? We will identify a range of actions from quick wins to more ambitious projects that could be pursued after useR! 2021.

## Promotion

### Places to Promote

* See tweet/LinkedIn post in next sections to share, or use your own message.
* Strikethrough below when done.

#### Slacks
~~LatinR~~; ~~RUG organizera~~, ~~RSE~~, ~~R-Devel~~, ~~Forwards~~, ~~R-Ladies Remote~~, ~~R-Ladies organizers~~, ~~R-Ladies community~~, ~~CSCCE~~, ~~Biconductor~~, ~~Carpentries~~

#### Twitter
Personal Twitter [~~Heather~~], ~~useR!~~, ~~R-Ladies Remote~~, ~~Forwards~~ [~~Emma~~]

#### Other

~~SSI website and newletter~~

#### Not done (reason)

RSE Society weekly newsletter (missed deadline).
R Weekly (published after registration deadline).

### Promotional LinkedIn Post

https://www.linkedin.com/posts/user-conf_rse-rstats-activity-6814149828843487232-2Xq2

### Promotional Tweet

https://twitter.com/_useRconf/status/1408319045905141760

:hatching_chick: useR! 2021 Incubator

The role of the R community in the RSE movement

A participatory session on Research Software Engineering and R

#RSE #RStats

:date: Tuesday July 6, 2021
:clock1: 4:00pm – 5:00pm UTC
:link: https://t.co/sXZQXdWznb

### on image slide with alt text

Header: The role of the R community in the RSE movement

Join a small group discussion (spoken or written) on a topic related to R and Research Software Engineering, such as:

* How can we increase visibility of R in the RSE community?
* How could we develop an RSE for R users community?
* What does an RSE who uses R do?

Help incubate ideas to bring the R and RSE communities closer!

Image: waving marmot with useR! scarf

### Start #r channel on RSE Slack and promote event
- do we want (many) people to contribute to HackMD in advance?

> []## Instructions for participants
Adapted from [The Software Sustainability Institute’s Collaborations Workshop](https://software.ac.uk/cw21/discussion-session)

The Incubator allows small groups of people to discuss a topic around "The role of the R community in the RSE movement" that interests them in a way that helps people learn about new ideas and work together on solving shared problems.

The output of the discussion session is a summary from each group which can be developed to help disseminate the insights to the wider community.

*Schedule and topics*

The incubator will take place 1600 UTC Tuesday July 6. The live list of topics are available so you can sign up for a topics and suggest new ones.

*How does it work?*

Before the start of the Incubator participants sign up for a topic, or suggest a new one, that will be discussed in a breakout out room. If there are fewer than 3 participants for a topic, the topic will be dropped. Where many people sign up for a topic, several breakrooms will be created to discuss that topic.

The breakout room discussion session lasts for 45 minutes. That's not enough time to discuss the subject in depth, but it's about the right amount of time to develop some common thoughts and summarise them.

*What to do*

In the first five minutes, you should choose a Reporter. The Reporter clicks the link for the collaborative note taking and summary template for their group from the Discussion Topics spreadsheet and uses that to note down points from the discussion.
Then allow 30 minutes for discussion without worrying about writing the summary. Once the 30 minutes is up the group moves on to writing the summary for the final 10 minutes. The summary is a few bullet points which give the main themes of the discussion

*Reporting back*

There is no formal reporting back session at the Incubator, the summaries form the heart of reporting back information from the discussions in a way that is of wider benefit to the community.

Potential topics

Topics have been added to spreadsheet to allow suggestions: [Discussion topics](https://docs.google.com/spreadsheets/d/1-3fyUrmUf7ged5Y4pAnu0u8oSsP8ZX5bm4qch7OS6UE/edit#gid=0).
If you edit the list below please also amend this spreadsheet.

1. How can we increase visibility of RSEs in the R community?
Many R developers probably qualify as RSE but don’t know this term or the RSE community. Could we change this? Should we? How?
2. How can we increase visibility of R in the RSE community?
R is less visible in the RSE community than, for example, Python. Could we change this? Should we? How?
3. Could we develop a podcast on ‘meet the R-engineers’?
Are there Existing R podcasts we could collaborate with? What suggestions do you have for interviewees?
4. What should a book "Research Software Engineering with R" contain?
5. How can we reward people for writing software / publishing code? Is there a reward mechanism for producing software where you work? If so, what is it? Does it work?
6. What does an RSE who uses R do? What are common tasks you perform in your role?
7. How do we develop an RSE for R users community? What resources and techniques could help build communities of practice in this group?
8. What does "Research Software Engineer" mean to you? The term "Research Software Engineer"(RSE) was proposed by a group of software developers working in academia at a workshop in Oxford, UK, 2012. It was the beginning of a grass-roots movement which has grown substantially, leading to recognition, reward and career opportunities for RSEs and the creation of national RSE associations in Australia/New Zealand, Belgium, Germany, the Netherlands, the Nordic region, the UK and the USA. However, this role and terminology are not universal. Are these [UK](https://society-rse.org/) and [US](https://us-rse.org/) definitions appropriate for your role? What would you modify?
9. How do you help build intermediate software engineering skills and help people go beyond the basics?
10. How can we identify and highlight which funders are most research software friendly?
11. What can other RSEs learn from the R community? E.g. a common archive, structure of packages, etc.
12. How can we promote RSE career paths?
13. What are R's strengths in terms of infrastructure, workflow, and software testing and community? How do these differ to other communities and what can we learn from other communities on these topics?
14. How to show off what R is doing well?

## Output ideas (Brainstorm)

### Get some data from (some) participants in advance to help plan rooms

### Provide a document / article / post on R's approach to RSE

* Goal is to provide a resource for other RSEs to adapt, remix, and engage.
* Provide information on Rs stengths in approaches to infrastructure, workflows, ways of building community, software testing.
* Use lanaguge that is accessible to RSEs not familiar with R that can be perused after the event and people can be referred to later

### Join RSE mailing lists, events, ...

R users can join RSE mailing list and contribute to the discussions there. The R community already does a lot of things well that the broader RSE community can learn from (standardization, archiving, R ladies, ...).

### Increase visibility of RSEs in the R community and of R in the RSE community (extends point mentioned above)

Many R developer probably qualify as what is described as RSE but don't know about the term or the community. Having regular RSE contributions to R-Community events could help here. On the other hand R is currently not too visible in the RSE community (e.g. compared to Python). Having dedicated RSE-R channels of communication could help here (e.g. a R channel in UKRSE slack or deRSE rocket chat) and dedicated R sessions on RSE conferences. Knowing who your peer RSE-R developers are could be useful.

Podcast, similar to [rse-stories](http://us-rse.org/rse-stories/) or [vignette.md](https://vignette.md/about/), but focused on R.

We could also link in with other existing R podcasts?

### The Carpentries like Certification ?

### Platform for RSE remote workers
I know this is controversial, but since establishing RSE positions requires change of the academic system in many countries which might be hard to achieve in the short run.

### Start an RSE Journal (or cooperate with an existing Journal)

### Write a book together (Research Software Engineering with R)
Incubator participants could act either as authors or editors. Contextualize R and its ecosystem.

### Course of Research Assistants (RAs)

Research assistants are often hired as semi-automatic, helping hands for senior researchers.
Depending on how far their programming skills take them and are considered production ready,
RAs may be the best programmer on the team with little to no time for documentation. Or RAs may write
some of the most unsustainable code you have ever seen. A course, series of interviews, a cheatsheet or book may
help to address this target group / help the RSE community plant seeds.

# Running the session

- Heather, Matt, and Heidi are the chairs of the session
- Session outline
- Chair 1: welcome
- Claire's talk (5 mins)
- Chair 2: introduce breakout rooms
- Breakout room discussions
- Chair 3: close

- Briefly explain how the break out rooms are created, list what the topics are, and how the reporting works. There will be an appointed reporter for each of the topics. There is no reporting out,
- How do we identify who is going to be the "reporter" person for each breakout room? Can we do this in advance? We should aim to get this done by Monday.
- (where do people see this list?) It's a google sheet.
- Will each breakout room have its own hackMD website?
- We might be able to share a spreadsheet of the topics, so they can see them, and potentially add their own, they can also preassign their interest in a topic?
- What is the max size for each breakout room - ideally it is about 6-8 people
-
- People then join the breakout rooms
-

- Mario's suggestion for "uconfly" - a framework for helping write collaborative workshops

## Further thoughts on running the session

Can give choice of spoken and written discussion.

Others to invite to participate
- Someone from UK SSI? They could give a quick intro to RSEs
- Ditto someone from RSE Society?
- Anna Krystalli (as "official" participant)

Heather will look up again:
- [Speed blog post format](https://www.software.ac.uk/speed-blogging-and-tips-writing-speed-blog-post) (collaborations workshop)
- 50 mins discussion, 40 mins writing; small groups 2-6 -> not suitable for our case
- Birds of a feather sessions (Bioc)

# Cutting room floor

current 4pm utc tues 6 july
possible swap is 6:45pm UTC Friday 9 July
- no good for Anelda, Emma, Nick, Jan
- all good for Olina
- 4pm 6 july fits better for Jochen
- better to go with time where we know we have volunteers, we can promote well in advance to RSE groups and smaller, focused group may be better
- try inviting somone from UK SSI/RSE to give quick intro to start off

### ~~Some ideas for questions in the session~~
The following have been incorporated in to [Potential Topics](#Potential-topics)
1. ~~Is there a reward mechanism / bean counting for producing software where you work? If so, what is it?~~
2. ~~What are common tasks you perform in your role?~~
3. ~~Do you know other research software engineers? Do they use R?~~
4. ~~How do we develop RSE for R users community?~~

~~The output might be a blog post that could be shared on the useR! website, with ways that the RSE and R communities can get more connected and perhaps a roadmap/some initial actions that could be taken.~~

~~"what do you do day to day / what is an example of a daily task" from people who feel they identify/resonate with the term RSE.~~
~~### podcast: 'meet the R-engineers'

~~The on-site incubator could compose a list of interviewees and draft a red line across interviews. This would not be a podcast for the masses, but something for the both the R community the RSE movement and students to listen to. This could also go in hand with a blog post.~~ ~~

## Participants

Matt Bannert
Heidi Seibold
Heather Turner (Research Software Engineering Fellow, University of Warwick, from July 1)
Emma Rand (Senior Lecturer in Computational Biology, University of York, UK and SSI fellow)
Nicholas Tierney (Research Software Engineer, Telethon Kids Institute)

## Meeting minutes

useR RSE meeting 22.06.2021

Participants:

* Heidi Seibold (Johner Institut / [e-mail])
* Emma Rand (University of York, UK/ [e-mail])
* Heather Turner (Univeristy of Warwick, UK / [e-mail])
* Nicholas Tierney
* Jan Dietrich (Potsdam Institute for Climate Impact Research, DE / [e-mail])
* Anelda Van der Walt
* Olina Ngwenya
* Matthias Bannert
* Jochen Schirrwagen

#