Outcomes from the CW11

CW11.jpg

Outcomes are changes that will make the life of the researcher easier. They were collected from the further work section of the reporting back slides, and also from discussions that took place during and after the workshop. The outcomes will be acted on by the Software Sustainability Institute over the coming year, with the goal of completing them all before the next workshop in March 2012.

Outcomes Update – December 2011

We have completed about two-thirds of the outcomes (20 of the original 32) in nine months. This puts us well on the way to completing all of the outcomes before March 2012.

Completed outcomes

  • Promote resources for training people about software engineering (not full-time courses)
    We've written three software-development-based guides on our website and six tutorials for Software Carpentry - a website for teaching scientists and engineers the concepts, skills, and tools they need to use and build software more productively. This is an ongoing outcome, so we will continue to provide more resources to help people learn about software engineering.
     
  • Get people to identify online educational resources on software development for researchers, and then aggregate these resources
    We've set up a useful resources page, which asks users to suggest the resources that they've found most useful. We've also sent out a call for resources, which we will repeat every quarter.
     
  • Blog about why researchers should care about learning more about software engineering (and how it would help their research) and the sorts of things they should learn
    Our blog post We’re all engineers now describes five key concepts that every computational researcher should understand about creating software.
     
  • Blog about the difference between coders and software engineers
    Our blog post Coder, programmer or software developer - spot the difference! looks at the different people who create code and discusses their relative merits.
     
  • Use AskSteve to explain why developers should care about the research field in which they've been asked to work
    This subject is the focus of Steve’s post As a developer, why should you care about the research field you work in?
     
  • Talk to research councils to gain their views and lobby for changes including software management plan and best practice in how to write a good pathways to impact for software
    Following the Collaborations Workshop, we met with the EPSRC, JISC and STFC to discuss the ways in which we could work with the research councils to promote software sustainability. Based on this meeting, we further developed our briefing papers. We will continue to liaise with the research councils and champion software sustainability.
     
  • Use AskSteve to promote open sustainable standards for data formats
    This subject is the focus of Steve’s post How to Specify and Implement Data Movement?
     
  • Investigate ways in which we could promote developers in general
    We have written a number of posts on our blog about the value of software and developers, and we are currently investigating a national developer awards ceremony.
     
  • Create a mailing list to collect together all contacts from the eResearch community, because the NeSC mailing list will soon expire
    On 27 July, the final email was sent to the NeSC mailing list. It provided details of alternative mailing lists (including our announce mailing list) from which the eResearch community could continue to receive news about developments in their field.
     
  • Prepare an overview of software management plans and hold a workshop
    This will be discussed at the SeIUCCR summer school on 12-15 Sept 2011
     
  • Produce usability evaluation and code evaluation of YouShare
    The usability evaluation has begun and will be completed later this year.
     
  • Publicise the Open Research Computation journal
    With permission from the editor of the ORC, Cameron Neylon, we have blogged about the journal and will be raising it in our meetings with subject librarians to see how we can further publicise the journal to the software community.
     
  • Check whether there's a subject librarian for software and whether they know about refable journals for software
    In August 2011, we met with a representative subject librarian. We discussed refable journals for software, and found that there is currently little provision for these journals. In 2012 we are planning to broaden this outcome and work with academic subject librarians to promote the need for refable journals for software.
     
  • Investigate CRM work with the DCC
    This work was investigated, and it was found that the disparate needs of different organisations would over-complicate the benefits of a shared CRM.
     
  • Promote the necessity of software development to the peer-review groups that decide on funding
    There is no absolute end to this outcome - it has to be an ongoing issue. This year, we have promoted this requirement whenever the opportunity has arisen, and we will continue to do so over the coming years.
     
  • Work with schemes for teaching PhD students how to program and advise them on curricula (this outcome also includes the outcome "Investigate and possibly disseminate development training that will soon be available from University of Edinburgh")
    This year, we have promoted better software engineering through our work with Software Carpentry and by running our training workshops. We have also acepted an invitation to advise on development training which will be promoted at the University of Edinburgh.
     
  • Review case studies for other groups
    This service is now offered on our case studies page.
     
  • Investigate aggregator for funding announcements
    We have found Research Professional to be a handy funding aggregator. A link is available on our useful resources page and we have asked the community for their views through a blog post.

Cancelled outcomes

Over the year, changing situations and requirements mean that some outcomes can no longer be completed. This has led the following outcomes to be cancelled

  • Create a new journal for software with peer-reviewed ‘refable’ papers based on the Nature methods, but for software
    This outcome was put on hold, because other journals are available for this purpose.

Remaining outcomes

  1. Update Research Council briefing paper based on comments from funders' session, and send out copies to contacts from the workshop
  2. Prepare guide on how to write case studies on funding - write guidelines from our point of view, and ask others groups to contribute too
  3. Prepare case studies on people who have worked across the researcher/developer divide and draw on people's experience in the Software Sustainability Institute
  4. Prepare guide that shows which journals are useful for publishing results from development projects
  5. Determine how to measure impact that software-engineering has on research
  6. Write up a case study about necessity of preserving original results based on nuclear test simulations which preserve bugs created by original hardware
  7. Investigate researchspace.org to see whether it is suitable for collaborator management
  8. Investigate Software Sustainability Institute involvement on review panels for software funding
  9. Investigate whether there is a CKAN service for eScience data
  10. Develop and recommend use of code citations
  11. Prepare guide on how to write case studies from a publicity point of view, covering which method is best (tweets, blog, videos, etc.) and mention the need to promote open data standards where relevant
  12. Work with OSS Watch on SIMAL