Breakouts give you the opportunity to discuss a topic that interests you, with a group of people who share that interest. It might be a broad topic relevant to research in general, or might be something specifically interesting to your research. Breakouts are a very good way of learning about new topics and working out problems.

A breakout session starts with everyone collected in the Newhaven lecture theatre. We show a list of the discussion topics and then ask everyone to vote for the topic that interests them the most. Based on the vote, we split into a number of groups (generally 5-10 people per group), move to separate rooms in the e-Science Institute and discuss the topic of choice.

Make it relevant to you

The best way of making sure that the workshop is relevant to you, is to email in suggestions for discussion topics. You can also suggest topics at the workshop. The topics we have received so far are listed at the bottom of this page.

We receive a lot of suggestions, so it's often necessary to combine similar ideas. This means that the exact wording of your suggestion might not always make it onto the agenda - but the spirit of the suggestion will.

How does it work?

The breakout sessions last about an hour. That's not enough time to discuss the subject in depth, but we find that it's about the right amount of time to work out the main points.

In the first five minutes, you should choose a group chair and scribe. Their roles are described below. Once that's done, the discussion can begin. Near the end of the session, someone will come and remind you that time's running out.

The Chair's role

It's the chair's role to keep the conversation going, draw out the main points of interest and make sure that no one is left out of the discussion.

The Scribe's role

The scribe should record the main points of the discussion. We're looking for about two to five slides worth of information. (If you want to record more, then please do, but there might not be enough time to present it all). The minimum information we need is:

  • Topic title
  • Main points
  • Conclusions
  • Further work (if appropriate)
  • If possible, the names of the people in the group

Reporting back

Download the reporting back template.

There would be little point in running the breakouts, if the revelations and conclusions that occurred during the discussions were never heard again. The reporting back session allows each group to report their findings.

We collect again in the Newhaven lecture theatre and the group chair or scribe (or someone else, if you prefer) talks through the slides prepared during the breakout and answers any questions. In total, a reporting back session should take about ten minutes.

We want to keep a record of the workshop, which will be made available online, so please give a copy of the slides must then be given to Simon Hettrick (workshop chair).

The final product

Even reporting back to the workshop isn't enough. It's important that the conclusions from the workshop are made available to people that did not attend. For that reason, we will make all of the slides available on the Software Sustainability Institute's website. We will also prepare a report based on the workshop's conclusions and make this available online.

Breakout topics

The current list of breakout topics is listed below. We want your ideas! If you want to submit a topic, please email us.

  • How can researchers work with developers to make the best of funding and new funding opportunities?
  • How can I get my research used by others?
  • Bridging the researcher-developer divide: researchers perceptions of developers, and developers perceptions of researchers
  • What's the best way to prepare case studies to show what works for funding?
  • If CRMs don't work, what does?
  • Can the development community help make my research software more robust?
  • How do you measure research impact?
  • How can we work together to disseminate research results?
  • Can the Research Councils promote interdisciplinary work by acting as a point of contact for their communities?
  • Research funding 2011: what's available and how to get it
  • How can software communities collaborate to save money?
  • Should PhD students be taught to program, and how should it be done?
  • Making the pitch for research support with software development
  • Training, development and mentoring priorities
  • We have data-management plans, should we have software management plans too?
  • Effective engagement of users in scientific software development
  • How to develop from a good idea to an open-source software product
  • How can projects with little resources protect their work from IP infringement

Share this page