[Using Sakai] Sakai Product Council: Activities & Goals

[Nate Angell]

Following is the Product Council's summary of activities conducted through Q4 last year and goals for Q1 and Q2 in 2010.

We welcome your questions and input.
You can also read and/or comment on the Sakai wiki:
http://confluence.sakaiproject.org/display/MGT/SPC+Update+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 some basic documentation.

Then in phone meetings (and on-list) 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:

Site Stats
Profile2
Gradebook 2
Conditional Release
Basic LTI Portlet
TinyUrlService
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 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. This is especially the case where the Sakai community has historically not developed robust criteria.

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 the entire product and stamping it as something suitable for the community to deploy. 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 the 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 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
--
Nate Angell
Client Evangelist
ixmati = AIM, skype, gtalk
nthangell = yahoo, .mac
209965525 = ICQ
503.927.1162 work/mobile
http://twitter.com/xolotl
http://xolotl.org
http://www.rsmart.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-user/attachments/20100225/0e2156fd/attachment-0001.html