Previously known as “discussion topics”, presenter-led panels give an opportunity to share a range of views on a complex topic. Unlike an audience-led panel, presenter-led panels have a minimal element of audience interaction, with the chair and panellists driving the conversation.

Topics for the discussions should be broad, with a set of participants who can approach the topic from a range of perspectives. The discussion should be moderated by a chair, who will steer the event, ensure all participants are heard, and will make sure that there is time to debate all relevant aspects of the topic. 

Compared to an audience-led panel, for a presenter-led panel the majority of the time should be spent on discussion between the panellists, or between panellists and the chair. Panels will last 50 minutes.

Planning your submission

Presenter-led panels focus on interactions and discussions between panellists. Compared to talks which should usually come to a conclusion within the available time, good panels frequently deal with issues too large to ever be fully encompassed in a finite time slot; the variety of experiences of the panellists gives a range of perspectives on the topic, and provides the starting point for conversations that can continue into coffee and lunch breaks. That said, panels should discuss related issues around a focussed topic that will likely be of interest to the wider Research Software Engineering community. Topics of previous presenter-led panels include:

  • Industrial Software Development Practices: Do they work in Academia? Should RSEs learn and use them?
  • Python is ubiquitous in research, even when it is not the optimal option. When is it worth investing time in a more specialised but harder to learn/maintain programming language?
  • Is testing overkill for most research software? How can we make it easier to test scripts?

Note that this conference is a hybrid event and participants will be able to attend your panel remotely. It is expected that panels should provide an equivalent experience for online and in-person participants – we will provide guidance for accepted submissions. We may not be able to broadcast video of the panellists from all rooms and may be limited to audio and any slides you or your panellists present, for example a biography slide. 

When submitting your proposal for a panel you will need to consider:

  • Title and abstract: Make this informative and eye-catching as this will be used in the conference programme.
  • Audience: Would your target audience be required to have any prerequisite skills/background knowledge e.g. knowledge of a particular language or software package?
  • Outcomes: How will your attendees benefit from your session? What do you expect them to gain/learn?
  • Questions: Will the floor be opened for audience questions, or will the discussion be kept between panellists and chair? (If you want to devote a lot of time to audience questions, then consider submitting an audience-led panel instead)
  • Panel diversity: Will your panel’s composition reflect the diversity of the RSE community and wider world? For example, how will you ensure that the panel does not represent a single gender or ethnicity?
  • Accessibility: Accessibility guidance is available to help you make your panel successful.  Some key pieces to consider are:
    • Have you thought about how accessible your session will be to a diverse conference audience (i.e. different skill sets, different work backgrounds)? 
    • Will someone who views a recording of your event be able to contact you in future?

You can also use automated accessibility checking tools to help ensure that you haven’t missed anything.

Note at this stage that you only need to suggest a panel topic and nominate yourself as a panel chair. You don’t yet need to identify the panellists. Feel free to ask us if you want any suggestions or help to find volunteers.

Wider dissemination after the conference and licensing

All materials will be published on the conference website, and recordings will be shared via YouTube. All material will be shared under the Creative Commons Attribution (CC BY) licence unless an alternative open licence is agreed in advance with the conference committee. Recordings, subtitles, slides, and any additional Q&A will also be made available via Zenodo.

Mentorship

We are happy to provide mentors who can help you put together your session. Mentors can help by reviewing draft slides, listening to a rehearsal, providing advice on making material engaging, reviewing adherence to accessibility guidelines, advising on hybrid delivery, etc. You can let us know if you would like a mentor if you are accepted.

Example Submission

This submission was very highly rated by our reviewers last year – you may wish to use this as an indication of the details which should be included and how to present your idea.

Title

Licensing our code for better impact

Abstract

We all want the software we are involved with producing to make a positive difference in research and beyond. Open source licensing can help with this, but coming up with guidance for RSEs and researchers can be problematic. Many people do not own the copyright on work they produce as a student or an employee (https://www.legislation.gov.uk/ukpga/1988/48/section/11), and ownership can vary by funder. In some sectors making code open source may limit the private sector investment that is needed to (ultimately) build a product compliant with regulations (e.g. medical devices). Despite useful guidance (e.g. https://choosealicense.com/, https://www.software.ac.uk/resources/guides/choosing-open-source-licence and https://alan-turing-institute.github.io/rse-course/html/module06_software_projects/06_07_software_licensing.html) licence choice can be confusing.

After a short introduction on copyright and licences in the context of research software, this discussion will address questions including:

  • Should RSEs advise a default open source licence? Which would it be?
  • Should the organisations we work for or study at grant us ownership of the code we produce to licence as we chose?
  • How can we make good decisions on whether code should remain closed source for commercial reasons?
  • Is it a good idea for research funders to advise or stipulate a particular licence?
  • How do we ensure copyright and licensing are correctly managed for projects where people from multiple organisations contribute code?
  • How do we avoid useful code languishing on researchers and RSEs laptops when it could be doing something useful for the world via a licence?

Audience questions will be addressed.

Audience

Licences are of general interest to the RSE community as we often work on open source projects, or want to make our code and our colleagues’ code available outside our home institution. This session may be of more particular interest to those developing institutional policies or training in this area.

Expertise level

Practitioner, Expert

Panel Diversity

There has been some discussion on the RSE slack – those involved included myself, Guillaume Flandin, Simon Li, Heather Turner and James Graham. I can think of a couple of other people at the University of Sheffield and beyond who might be good. I’m keen to be advised by the rsecon committee on reaching a good level of diversity. I would be happy to put out an open call e.g. via RSE Slack, or approach people individually, under advice. I have not yet approached any potential panel members.