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

Content

• Purpose
• Code of Conduct
• Outputs from group discussion activities
• Schedule

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:

• Use welcoming and inclusive language
• Be respectful of different viewpoints and experiences
• Gracefully accept constructive criticism
• Focus on what is best for the community
• Show courtesy and respect towards other community members

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.

• Collaborating on a project with a data science and HPC component and more
• Directory of FOSS projects/applications being developed locally
• Skills based forums/message boards

• Various intro courses for different skill sets (introduce non-traditional disciplines in)

• Match making/mentoring
• Expanding code clinis behond students

• Help researchers write appropgriate papers

• Project showcases/case studies/Best practice frameworks

• Cross discipline topic of the month
• Conference/evet with multiple tracks reflecting various backgrounds

• Building cross-disciplinary teams/forum meetings relationship presenting internal resesearch in other schools

• Edinburgh is a huge presence, will domination be an issue?
• Could industry and academic positions be more fluid?
• (EPCC hat on) MSc project ideas in Data Science and HPC could lead to collaborations
• Lobbying - university, government(s), funders, punlishers
• Combining approaches/benchmarking with:
  • other regional RSE groups?
  • other professional groupings (AMRMA, CILIP, etc)

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

• Formal V Informal sharing
• Lightning talks
• Recording lightening talks
• Slides and audio to be shared after the event
• Lightning talks 3-4 minutes - networking afterwards
• Monthly meetings - no more than 50 attendees - 60 minutes presentation/sharing, 30 mins networking
• Chance to Chat
• Social events
• Virtual attendance - enables those that cannot travel
• Small core group to coordinate - with small teams of volunteers to arrange events Annual bigger event
• Mailing lists - mixed feelings
• Mailing lists for announcements and event publicity
• Slack - can be challenging, too noisy/quiet
• Website with blogs / sharing resources

4. Growing our community / inclusion and support

Facilitator: Andy Turner

• Highlight 1: Diversity
  • A community that has the widest diversity of people and is inclusive (both leading and in the membership) will have the most benefit and impact
  • How could this be achieved?
    • Explicitly highlight diversity and inclusivity as a goal of the community (in all publicity material and at events)
    • When writing event invitations make sure the variery of people who can come is explicitly stated to try and mitigate risk of people not thinking the event is for them
    • Run a diverse range of events with a variety of different timings to allow different groups to be involved in the community (for example, events that are labelled as Training will attract a different audience and potentially make it easier for people to argue for time away from their job to come along).
    • Look at how Women in HPC have achieved this as they have been very successful.
    • Produce or point to career profiles showing a diversity of people in the community.
  • Ideas for different event types:
    • RSE training - more advanced than the Carpentries
    • Joint event with UoE Staff Pride
    • Joint evert with local Women in HPC Chapter
    • Edinburgh DataFest Fring events: one for RSE community, one for wider community where they bring their problems to local RSEs
    • Hackathon style events with communities such as: City Council (WCDI?), NHS: bring together problems and problem solvers
• Highlight 2: Inclusivity
  • Coming along to a community event such as this can be difficult for people as they may not feel part of the “club”. There can be certain level of clique-iness associated with “movements” (e.g. RSE, Carpentries)
  • How can we avoid this?
    • Make sure our publicity text does not have these sorts of connatations and is welcoming and inclusive for all.
    • Have advocates for the community in institutions/departments that will raise the profile of the community from a source that potential members already know and trust.
    • Make sure events are run at different locations throughout Edinburgh (institutions, campuses, etc.).
    • Have events where members are encourgaed to bring a friend who has not attended before.
• Highlight 3: Growing the community
  • Can be difficult to reach out to people who do not already know about the community
  • Options:
    • This may naturally get better as the community grows and members disseminate information.
    • We could have reciprocal dissemination agreements with other, related groups: PyData Edinburgh, R Edinburgh, Carpentries, UK RSE, ARCHER/Cirrus. We need to find out who these communities are.
• Highlight 4: Support
  • How can we help less experienced community members grow their skills and develop their career/network?
  • Mentoring programme:
    • Pair less experienced community members with more experienced ones
    • Value in having mentors in different organisation/departments to help get diversity of views and to allow mentee(?!) more freedom to ask questions
• Things that we are missing:
  • Network organisation effort/skills:
    • Skills in dissemination, advertising, socila media, organising events, community adminstration
    • Could we put a funding proposal together to get money to support (part?) of a person to take on this role?
    • Would maybe also facilitate the mentoring scheme mentioned above?
  • Bursaries for less experienced community members to travel to relevant events (e.g. RSE conference) that they may struggle to find funding for.

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:

• the UKRSE slack (specifically the #edinburgh and #jobs channels)
• the UKRSE weekly jobs posting email list (weekly post to everyone@rse.ac.uk)

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)

• Presentation: Welcome (pptx), Sean McGeever, School of Physics and Astronomy, University of Edinburgh

• Introductions
• Edinburgh Core Team (Andy Turner, Mario Antonioletti, Neil Chue Hong, Giacomo Peru)
• Outline of workshop

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

• Presentation: What’s all this RSE stuff about? Andy Turner, EPCC
• Context: UK RSE, Global Reach, Society
• Local / Regional RSE Groups (e.g., Soton, UCL, Manc) and individuals
• RSE18 UoE attendees (including Chem / GeoS / ISG)
• RSE resources and related activities: e.g., Carpentries, Our Coding Club
• Icebreaker (CarpentryCon style)
  • Jean Bartik
  • Anita Borg
  • Margaret Hamilton
  • Grace Hopper
  • Katherine Johnson

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

• Slides for this session (pptx, pdf)

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

• Only 30 minutes!
• Introductions (5 minutes)
  • Name, group / department, organization
• Discuss the topic, noting ideas and barriers
  • Highlight (15 minutes)
    1. Potential activities and events that might address the theme
    2. Roles and Responsibilities: how might you organize these activities?
    3. Available resources that could be contributed to make things happen
    4. Missing skills / experience / resources that are needed
  • Prioritise (5 minutes)
    • What’s the most exciting thing? What’s the easiest thing to do now?
• Wrapup – anything you’ve missed? (5 minutes)

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)

• Activities and Events
• Roles and Responsibilities
• Funding and Logistics
• Initial Community Roadmap

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

15:00 Close & Tidy up

Please refer to the accessibility statement for this web site.