[sakai2-tcc] QA Director returns to role at Amsterdam/QA going forward

[Ian Dolphin]

Apologies for cross-posting

At the end of March Alan Berg, Sakai Foundation QA Director, returns to his role at the University of Amsterdam. I would like to take this opportunity to thank Alan for the tremendous work he has done over 16 Months, which has included two major and three maintenance releases. I would also to thank the University of Amsterdam for allowing Alan this extended secondment. Sakai is built around the collective contributions of institutions and individuals. Alan's contribution, which would not have been possible without UvA's commitment, has made a significant difference to the quality of Sakai software. It has enhanced the experience of millions of learners, educators and researchers who use Sakai software. I wish Alan the very best in his continuing role at Amsterdam.

A number of possibilities exist for structuring QA work going forward. The approach I outline below continues the approach of the last 18 months, and breaks out QA roles into discrete areas. This is designed to facilitate greater incremental contribution from institutions with an interest in improving the quality of Sakai software, without imposing a significant overall coordination overhead. Whilst this proposal appears to be the optimal path forward, and has been discussed and developed by Foundation staff, I'm more than happy to listen to alternatives and suggested amendments from the broader community. 

Functional Test Coordinator: The recent bug-bashes organised by rSmart and Marist have begun to have a real impact on Functional testing. To develop this area further, we need a longer-term coordinator, who can build on this work, soliciting and recruiting further functional testers. 

Automated Test Coordinator: This person should be familiar with emerging technologies that help capture code defects early in the development cycle. In the short term the coordinator's effort should center around leveraging Hudson/Jenkins plugins, reviewing automatic functional testing. In the longer term, the coordinator will help plan and build generic infrastructure for a multi-project community. 

Performance Test Coordinator: The performance lead will play a significant role in revitalizing the Performance Workgroup, in addition to writing and running test plans against Sakai through an open source product such as Jmeter or Grinder. An understanding of the underlying Java Frameworks would be of great benefit. Generating a greater degree of engagement from institutions with an interest in specific release/database combinations is a strategic priority in this area.

Overall coordination of QA effort should be collectively organised by the three coordinators, with a suggested rotating fixed time "point person". Each of these roles imply a strong, proactive engagement with other members of the Sakai Community, including the Technical Coordinating Committee, and those coordinating work to improve specific capabilities such as accessbility and internationalisation. Each QA role provides not only a great opportunity to improve the quality of Sakai software, but also to gain considerable additional experience in several critical areas of quality assurance. Such experience could be of considerable broader benefit to the contributing institution. I would suggest the time commitment associated with each of the roles lies, on average, between 1 and 2 days per week. This will clearly vary according to the point in any release schedule.

This proposal has two purposes. The first is to solicit community contributed resource to continue to improve the quality of our software. The second is to stimulate discussion around how that resource is best organised. The current QA structures evolved in a period when Sakai was a single "product", single project community. We now have two distinct "products" in the existing Sakai CLE, and the emerging Sakai Open Academic Environment. As Alan Berg has often, and rightly, reminded me in recent months, the implications of the Sakai OAE Hybrid mode are that for QA purposes our community now supports *three* products - somewhat masked at present by the nature of the OAE effort as a managed project. As we evolve quality assurance processes into the future, we need to factor this into thinking and planning, carefully examining where structures and processes can be applied to the range of software we develop and support. This is particularly important in the context of a future, larger foundation with our colleagues in Jasig, where we should certainly carefully examine opportunities for economies of scale and increased effectiveness.

As a community, we've made significant progress in QA, but three "products" imply a larger challenge. We need to meet that challenge by stepping up resources devoted to quality assurance, and ensuring that resource is effectively deployed and coordinated. 

Please feel free to contact me directly about any aspect of this mail. I suggest discussion take place on the Sakai Management list.

Best

Ian

--
Ian Dolphin
Executive Director, Sakai Foundation

iandolphin at sakaifoundation.org
+44 7737 862863
Twitter: d iandolphin24