Previously known as “discussion topics”, presenter-led panels give an opportunity for a range of opinions to be shared on a potentially, but not necessarily, controversial 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 panel

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?

When submitting your proposal for a panel you will have considered:

  • Title and abstract: Make this informative and eye-catching as this will be used in the conference programme.
  • Expertise level and 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: We have a complete accessibility guideline set to ensure 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)? 
    • Visually, have you considered the colours chosen as well as the shape and size of graphics and fonts?

You should now be thinking about who will be on your panel. Feel free to ask us if you want any suggestions or help to find volunteers.

Wider dissemination after the conference and licensing

Please bear in mind that all materials will be published on the conference website under a CC BY-NC license.