Tuesday 1 May 2007

peer review workshop - 25 April, Bolton



The second peer review workshop was held in a rather cloudy but warm Bolton. The focus of the workshop was very much about getting the projects to work together to share their findings and experiences of reviewing with their peer project(s). It ensured that they also had the time and space to consider the areas within their projects that could realistically be strengthened within the time/resource limits of their projects. To facilitate this, all of the morning and part of the afternoon was set aside for group work. Using the information in the Workshop Introduction guide, and completed SQA/OSSM review forms which peered projects had been asked to work on prior to the workshop, the (pre-defined) groups went through their review forms, feeding their findings to their peer project and then working on building roadmaps of priorities for their projects.
The latter part of the afternoon gave the four peer groups an opportunity to feed back to the wider group the issues, good practice and learning that they had identified during the peer review process so far. The presentations are available from the workshop page. Some general key themes emerged from these presentations:

Good practice:
  • Code tended to be well commented and clear
  • Generally there was a good level of documentation available on project websites
  • In most cases the software was available to download
Issues:
  • In general projects needed to work harder on improving the design/navigation of their websites so that visitors could more easily find the information and documentation that is there.
  • In some instances more/better use cases needed to be made available on project websites
  • More thought on support/documentation around installation of the software provided needed
Learned:
  • The importance of ensuring the prominence of key documentation on the project website
  • The strengh of having an FAQ section
  • The usefulness of shared technical know-how with the peer project
  • Being given a deadline for peer review helped focus the development of the project
Generally the review process appeared to have been a positive experience for the projects and one which they found to be helpful, though a couple of useful comments were also made:
  • importance of maintaining flexibility within the review guidelines
  • OSSM should include some review of use cases
  • greater consideration needs to be given to how demonstrator projects (as opposed to toolkit projects) can and should engage with the peer review process

The code sprint debate
The day ended with an open discussion with the projects about the forthcoming Code Sprint day, allocated for early/mid June to find out what they would want to get from this and whether they had a preference for this to be online or face-to-face. From the discussions it was evident that there was not a strong requirement for this, nor a good understanding of how it would benefit them.

However, there was some consensus about the usefulness of working within their peer groups and that some kind of focussed support on getting them to their final deliverables stage at around that time would be helpful. The clear message was that projects either needed a much stronger argument for the usefulness/benefit of a code sprint day (regardless of whether it was online or face to face) or some kind or re-working of the day/event that would better reflect their needs. Myself, Wilbert, Sam and Warwick are due to discuss the future of the 'code sprint' day this week and I will be reporting back very soon on the outcome of this.

No comments: