Outputs
- Topic: Quality in research software development; testing, CI, continuous deployment reproducibility etc.
Outcome: 9 steps for quality research software - Topic: How do we improve research software usability for non-developers.
Outcome: How do we improve research software usability for non-developers? - Topic: What are the best ways to mentor under/postgraduate students and researchers to adopt sustainable software practices when learning to code.
Outcome: How do you teach Sustainable Software Practices 101? - Topic: RSE recruitment, retention, development, career paths and future directions
Outcome: The inevitable abyss: find mentors who will help you get out - Topic: What are the most important things I can do to ensure reproducibility in my research software?
Outcome: What do you tell your PhD student Three Years Before They Leave … - Topic: Importance and credit for the publication of negative results
Outcome: NULL, not void - Topic: Supporting distributed team work with collaborative and decentralised tools
Outcome: Collaborate and don't die trying - Topic: How do research software engineers figure into establishing credit for software
- Topic: What is Open Science and how do we promote its importance
Outcome: Steps To Start Liberating Your Science - Topic: How would you collect examples of software impact to use as evidence of the importance of research software?
- Topic: Software platforms and packages that support the reproducibility of research results.
- Topic: How to get senior stakeholder buy in to 'Better Software, Better Research' and RSE's
Outcome: Evolutions in the Discussion of RSE Career Paths - Topic: Minimum standards of software description for publication of research
- Topic: Open source research software development techniques
- Topic: Pathways of funding research software development
Schedule and topics
The live list of topics are made available to attendees of the workshop allowing them to vote for topics and suggest new topics. To get a flavour for the type of things planned to be discussed please take a look at a snapshot of the current list.
How does it work?
Each topic is assigned a Proposer whose role is to make sure that everyone's voice is heard, and keep everyone on topic.
During the morning of the first day of the workshop, participants can make the following changes:
- Drop a topic: If someone is down against a topic as the proposer but they would prefer to be participating in another topic, they can remove their name as topic proposer.
- Lead a topic: If there’s a topic participant wants to see discussed, but it doesn’t have an owner attached to it, they can volunteer to lead it by adding their name on the topic.
- Suggest a new topic: If the topic a participant wants to discuss isn’t listed, they can add it to the list with themselves as the topic owner.
During lunch, all workshop participants should vote online (a link will be provided) on the sessions they'd like to participate in, there will only be one discussion topic session. Based on peoples preferences, we'll schedule the discussion sessions and assign them rooms.
The discussion session lasts an hour and forty minutes. That's not enough time to discuss the subject in depth, but we find it's about the right amount of time to determine the main points with time to write them up as speed blog.
What to do
In the first five minutes, you should choose a Reporter. The Reporter uses this form to request a note taking and blog template be setup for their group and uses that to note down the pertinent points from the discussion that can then be used as the basis for constructing the speed blog about the session.
A good way to start is to ask what participants in the group want from the discussion. Are people looking to solve a problem, wanting to promote a solution, or do they simply want to more about the topic? If you can get a handle on what people want from the discussion, it's much easier to keep everyone on topic.
Focus on what can be changed! It's easy with some topics to focus on a discussion of the problems and overlook the process of finding a solution.
Also it's important to give the first 50-60 minutes of time to the discussion and not worry about writing the blog post, as it can be hard to explore a topic and write coherent prose as the same time. Once the hour is up you should move on to writing the blog post for which you will have approximately 40 minutes, ideally it's better to get it written during this time as we have found if you leave it for later then you tend to never get back to it, even a first decent draft is a good start, and we will ask you if you want to work on it further before we publish them after CW16.
You might want to move the notes to the bottom of your document and blog post to the top in the last few minutes of the discussion session. In any case once you are done and if you want others to see it then you can always let people know via the CW16 Slack team. Otherwise the organisers will be aware of where the documents are. You will be able to carry on working on the blog after the session and for about a week after the workshop but please do try and have a (near) complete blog by the end of the session otherwise the momentum to write anything might be lost.
Email the filled-in template
The filled-in template will be recorded by the Scribe in an email. To make it easy to find the recorded information, the email's subject line should say which discussion session it was (eg. Session 1) and the Question of the discussion topic. At the end of the session the Scribe should send the filled-in template to the mailing list.
Reporting back
There is no formal reporting back session at CW16, the blog posts forms the heart of reporting back information from the discussions in a way that is of wider benefit to the research software community.
The final product
A week after CW16 we will publish the blog posts from CW16 so the teams will still have some time to tweak them; we will check with the team members before we publish. We won't be publishing the notes so please feel free in noting things down as you see fit.