Edinburgh RSE community bootstrap meeting, 2018-09-26, Bayes Centre

Content

Purpose

Our primary goal is to invite active and interested RSEs to bootstrap and participate in a local community of practice

Venue, Date, Time

G.03 Bayes Institute; 1-3pm, Wed 26th September

Code of Conduct

We expect all attendees at this meeting to abide by the Carpentries Code of Conduct. In summary, we encourage the following behaviour:

Please see the link above for the full Code.

If someone violates the Code of Conduct during the event we ask that you report it to one of the organisers (Sean McGeever, Mario Antonioletti, Andy Turner, Neil Chue Hong). All reports will be reviewed by the organisers and kept confidential.

Outputs from group discussion activities

2. Cross-campus and cross-discipline network building

Facilitator: Mario Antonioletti

Summary of Discussion

The group consisted of Mike S., Martin D., Eleni K., Hywel D., Catrina C., Peter B., Geoff L., Oliver B., Chris W and Mario A.

Each participant was given one or more postitnote and they wrote one or more ideas on it. These were then placed in the centre and we discussed on voting on them. Some of them were similar. We briefly discussed each and then voted on them. The top three group of ideas were:

  1. Create project showcases/success stories/examples of best practice.
  2. Form a subcommittee that will:
    • Meet regularly (or maybe as a one off).
    • Representatives to establish what is of interest to the community.
    • Choose a topic for the month.
  3. Provide a match-making service for:
    • mentoring.
    • give courses for particular skill sets.
    • provide skill based forums.
    • generate a reverse open source look-up table (to find out who is involved in open source projects and with what skills)

Post-it notes

Suggestions are ranked in order by group members.

3. Finding out what others are doing / presenting what I’m doing

Facilitator: Victoria Dishon

Summary of Discussion

There is the desire to have regular meetings, approximately monthly, with the purpose of sharing and learning from each other. The consensus appeared to be 60minutes of sharing followed by 30 mins of discussion or networking.

The talks should be held in different locations and at a variety of times throughout the week, Wednesday afternoon is an obvious choice, but having a fixed session excludes people who have commitments at specific times in the week from attending.

The option for recording (with the presenters permission) and/or virtual attendance is desirable, particularly for people who either are not permitted to travel to events on a regular basis or where traveling is impractical for a short session.

There is interest in more social events, breakfast meetings (for the early risers) or option to go to the pub after a later afternoon event for those that wish.

It was suggested that there should be a core group to co-ordinate events overall, but that it should be an expectation of the community that throughout the year everyone contribute in some way, either as a member in a small team arranging the event or presenting. Events topics should be planned two ahead.

Post event, the material from should be available for those that could not attend or to return to for reference. Suggestion that a website or blog could fulfil this purpose.

Communications between meetings, lengthy discussion about Slack and a variety of other tools, kept returning to Slack as a medium for day to day conversations, tips, questions. Comments about getting the balance of this right, sometimes channels can become too noisy, other times too quiet.

A mailing list was identified as the best way of informing the community about big announcements, publicising events and sharing information about external opportunities of general interest to the community.

Post-it notes

4. Growing our community / inclusion and support

Facilitator: Andy Turner

5. Recognition, Reward and Recruitment

Facilitator: SeanMcGeever

Key Points & Actions

  1. Most RSEs are normally unable to apply for grants in their own name, so are entirely dependent on PIs to fund their posts, assign their roles, etc.

  2. ‘Supervisors expect papers’ as the primary metric or currency for academic output. Software outputs rarely register as recognisable and rewardable outputs

  3. RSEs need a consistent and coherent framework for roles, posts and careers, including appropriate grades and jobs descriptions, explicitly supporting career development - ideally including access to well-promoted job adverts.

  4. Mentoring should be available for potential and current RSEs, to help guide and support their career development.

  5. META point: some of these points are already either being addressed (not yet fully solved, to be fair). But many RSEs, especially those working solo in a research group or unit, haven’t been made aware of what is happening.

ACTION: Ensure we point all attending and related RSEs to:

Raw Notes

(Rupert) REF2020 Recognition - RSEs not normally refable on existing contracts - moving to different contracts - competing against academics

(Rupert) Reward - salaries often much lower in academia than industry - so tradeoff between salary / conditions.

(AndyT) RSE career security very difficult - short contracts - sawtooth profile very common.

(Chris) We need to involve PIs in learning how to support RSEs

(AndyW) Did you have to make a choice between academic / service / support roles?

(Richard) RSEs typically unable to apply for grants in own name

(Chris) Shifted from grant to grant quite a lot; clear recognition of need, but ‘grant jenga’ often applies.

(Erica) More academic role currently, but writing software is a personal preference - however, ‘supervisors expect papers’

(Rupert) Some journals now expect software, e.g., the Journal of Open Source Software - JOSS

(AndyW) Are there complications dealing with with open source, licensing, etc?

(Rupert) DOIs often used solely for paper describing software - not for the software itself

(AndyT) Issue of qualtiy of code; how do you present software for access / reuse?

(Chris) Isn’t Zenodo supposed to help with access and reuse?

(AndyW) RSEs often at the mercy of PI selection, often based on poorly-chosen criteria (e.g., I need a particle physicist with experience of experiment x and who can do a bit of coding; rather than a competent RSE who can learn or translate the domain-specific data structures and algorithms into maintainable software).

(Richard) But don’t try to ape academic productivity metrics - e.g. release code with DOI but it’s never cited

(Chris) Need for mentorship - helping guide career development of RSEs from ‘potential’ to ‘senior’ (AndyW) Note existing targeted advertising for RSE vacancies - see ukrse weekly digest

Schedule

13:00 Welcome (Sean McGeever / Andy Turner)

13:10 Research Software Engineers - Who / What / Why (Andy Turner, UK RSE Association)

13:30 Edinburgh RSE Community Bootstrap (Neil Chue Hong, Software Sustainability Institute)

Group discussion on the following themes

  1. Learning, improving and sharing skills
  2. Finding out what others are doing / presenting what I’m doing
  3. Cross-campus and cross-discipline network building
  4. Growing our community / inclusion and support
  5. Recognition, reward and recruitment

Group discussion practicalities

14:00 Coffee / Cake / Networking

Some participants may need to leave or arrive at this point, so this is a natural break …

14:15 Bootstrap Outputs, Actions, Volunteer (Andy / Neil / Mario / Sean to summarise)

14:45 Wrap up & Thanks (Andy / Neil / Mario / Sean)

15:00 Close & Tidy up

Please refer to the accessibility statement for this web site.