Edinburgh RSE community bootstrap meeting, 2018-09-26, Bayes Centre
Project maintained by cerse
Hosted on GitHub Pages — Theme by mattgraham
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
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.
- 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
- Hackathon style events with communities such as: City Council (WCDI?), NHS: bring together problems and
- 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
- 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
Key Points & Actions
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.
‘Supervisors expect papers’ as the primary metric or currency for academic output. Software outputs rarely register as recognisable and rewardable outputs
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.
Mentoring should be available for potential and current RSEs, to help guide and support their career development.
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 email@example.com)
(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
13:00 Welcome (Sean McGeever / Andy Turner)
13:10 Research Software Engineers - Who / What / Why (Andy Turner, UK RSE Association)
- Slides for this session (pptx, pdf)
Group discussion on the following themes
- Learning, improving and sharing skills
- Finding out what others are doing / presenting what I’m doing
- Cross-campus and cross-discipline network building
- Growing our community / inclusion and support
- 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)
- Potential activities and events that might address the theme
- Roles and Responsibilities: how might you organize these activities?
- Available resources that could be contributed to make things happen
- 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