SPC Report for January 2010

Activity Summary for Q4 2009

Processes

The Product Council took as its inaugural charge the documentation and review of new tools and capabilities for the 2.7 release. The first step was to encourage a number of ripe projects to enter incubation by providing basic documentation.

Then, on-list and in phone meetings, the council worked toward criteria for 2.7, finally reviewing the incubated projects against them.

Meetings

Product Council Meetings are held fortnightly on Wednesdays at 6pm GMT, although the slot is not always used if there isn't an agenda.

2.7 Release

The Product Council reviewed 6 new tools or capabilities for the 2.7 release:

In the end it was decided that Site Stats, Profile 2, Conditional Release and Basic LTI Portlet were ready for release, with the following caveats:

Profile 2 needed to decouple itself from the TinyURLService. Doubts were raised about whether TinyURLService was the right answer to a more general problem of shortening URLs and making them human-readable, while including it as a particular answer to a single tool (Profile 2) was also judged inadvisable - the problem really is more general, and the PC puts product coherence as one of its key goals.
Conditional Release would be turned off in the release by default. It contains a valuable service that other tools can take advantage of, but until more tools do so its user experience can appear to be incomplete. Again, product coherence was a driving factor in this decision.
Gradebook 2 could not be distributed with a Sakai release because of license concerns - it uses UI components which are distributed under an LGPL license.

More extensive notes from the review exercise are recorded under 2.7 Exercise.

Criteria for Review

Noah Botimer and Max Whitney devised a Technical Elements and Interoperability Worksheet, which was worked through in cooperation with each respective lead to score all the projects under review.

The Product Council also insisted that there should be more than one institution behind the maintenance support of a given tool/capability. In some cases this meant that additional recruiting had to be done.

What needs to be improved next time

At the end of the process we could be glad that we had a more closely considered and better supported set of additions than Sakai had yet known in prior releases. The improvement was clear, yet it was only a first step; the process should be improved for the next round at a few key points:

Start Earlier: the review process was well behind 2.7 QA and release management preparations, and this led to uncertainty and some disruption. What's more, since the review included only fairly mature development projects, the full product development cycle was not exercised; projects leapt straight from incubation to the release. We could hardly do otherwise for our inaugural round, but this is not how the process should run from here on out.
Review a wider set of criteria: confining the review to release gatekeeping also meant that important considerations - like design and accessibility - could not hope to be addressed, and so these criteria were de-emphasized in a way they should not be going forward.
Incorporate newly founded maintenance team: without a maintenance team the product council could only make relatively cursory judgments about code maintainability from the Technical Elements and Interoperability Worksheet; readiness for maintenance should generally involve more expert review of those doing the maintaining.
Increase use of objective criteria: the product council process didn't start from scratch with its criteria; it leaned on scorecard and other criteria developed by the community in the past. This however also meant that the criteria used were generally technical, and didn't always go far enough in speaking to goals for product coherence. The product council was obliged to try to make judgment calls that should be better supported by precedent and objective criteria in future.

Future (Q1 and Q2 of 2010)

The first year of the Product Council's service will be completed by the 2010 conference in Denver, at which point the ED, the Board, and the community at large will no doubt be reviewing the Council's effectiveness. It's worthwhile to work to set some goals that should be accomplished in this period.

Sakai 2.x

New Sakai 2 tools and capabilities are still being introduced, and these will need to be treated on a case by case basis.

At the same time, the Council anticipates an increasing shift of Sakai Foundation and community resources toward Sakai 3, to the point that questions need to be raised about maintenance and new releases for the Sakai 2 line. The Council is charged with the stewardship of the full development cycle, which includes end-of-life. Although Sakai 2 will certainly not be retired at any point soon, planning for a measured community process can and should begin. The Council will focus on establishing clear agreement around a well-managed community process for a transition to Sakai 3.

Goals:

Help usher new Sakai 2 tools/capabilities through the process
Facilitate Sakai 2 -> Sakai 3 transition planning for community resource

Sakai 3.x

Sakai 3's rewrite from the ground up presents real opportunities for improvement. In areas where standards of quality are more easily met if they are focused on from the beginning (e.g. coherent UX, accessibility) the Product Council should work to see these criteria introduced and vetted with community expertise as early as possible.

Sakai 3 also represents for the Product Council the first situation where formal graduation from Incubation to Product Development needs to be considered. So far, with the focus on mature Sakai 2 tools, this kind of transition has really been left ambiguous, and the Council needs to bring clarity.

Finally, a maintenance or 'release readiness' decision in the case of Sakai 3 is different in kind from the Sakai 2 decisions faced already - checking to see if a new piece of the puzzle fits is different from drawing a line around an entirely new product. Functional thinking - even if it's simply a matter of assessing completeness - will have a role to play here, and the Council will need strong guidance from the community in making this determination. It's not expected that there will be a Sakai 3.0 by the time of the conference, but the Council should nevertheless have identified at a high level the broad functional scope and criteria that a future 3.0 release should be measured against.

Goals:

Develop criteria and process for moving from incubation to product development
Facilitate development of objective criteria for S3
Identify a high-level functional scope for a 3.0 target
Conduct a review of PC activity and make recommendations, test whether expectations are being met. This should be ready in advance of the conference