Skip to end of metadata
Go to start of metadata


OSP 2.6 will be synchronized with the Sakai 2.6 release with a current target release Spring 2009.

A short summary of OSP 2.6 changes is described at Sakai 2.6 Overview.

Overview of Changes Implemented for Sakai 2.6


  • SAK-14417 - Redesign Portfolio User Experience
  • SAK-8638 - Ability to edit and delete feedback and evaluations
  • SAK-10139 - Aggregation of Evaluations across sites via My Workspace
  • SAK-11545 - Better group awareness and filtering in Wizards tool
  • SAK-12154 - Ability to apply an OSP Style to more screens of a Matrix
  • SAK-13406 - Ability to control allowed general and item-specific feedback (0, 1, many) in Matrices and Wizards


  • SAK-11449 - Adding contextual cues to audience selection pages
  • SAK-12101 - Ability for learners to review their own submitted materials more easily within a cell
  • SAK-13192 - Including inviter's email address in portfolio sharing notifications
  • SAK-13410 - Moving some Matrix styling to CSS to allow Style to adjust more UI
  • SAK-14096 - Matrix name configuration after publication
  • SAK-14214 - Optional sharing screen limit for users in a given role
  • SAK-14279 - Avoid wasteful calls to resolveUuid
  • SAK-14280 - Improve efficiency of form handling by caching schemas

Complete List of OSP JIRA Issues Resolved in Sakai 2.6 is also available

Past Planning Meetings

A two-day OSP 2.6 Planning Meeting at IUPUI was held on October 22-23rd, 2007, in Indianapolis, Indiana (UITS Building).

More Travel Information on transportation from airport and hotels is available here.

Planning Meeting Breakout Sessions

  • No labels


  1. I'm a little confused here. On the link to this page it says OSP Design and Devt for 2008 but the content of the page refers to OSP 2.6. Are we writing requirements for the presumed Sakai 2.6 release or coming up with a roadmap for future OSP functionality or both? It seemed like some of the focus of the discussion at the meeting this week was not limiting ourselves to the Sakai releases and chipping away at things incrementally without a larger roadmap for where we were going. How do folks think we should proceed with this goal?

    1. I'm pretty sure the 2.6 references here are just legacy dirt. I think we'll be cleaning them out and trying to ignore release versions as much/long as possible. Obviously, we have to pick and bundle features for a release, but I think we can roughly think in terms of v.Next and v.Future until we have a clearer picture of release cycle.

      I think that the most important thing is defining a roadmap and bundling cohesive features that align with it at functional milestones, rather than bundling what can get done by a calendar date.

      I like the names "feature boxing" and "time boxing" for these methodologies. There is a definite overlap as we get closer to releases where we have to make "in or out" decisions based on chunks of features and their likelihood of completion.

      Just dreaming, it should be more feasible for implementors to "cherry pick" features that miss a release, but are compatible. This is what the post-2.4 branches were about for things like Assignments and Gradebook, and it works really well. Schools that have sophisticated requirements can meet their needs with some work, while schools that need factored reliability can run OOTB with a known quantity.

      The rolling feature/code freeze effort and feature branch ideas are working toward this feature-driven model, too, so we can learn from the experience of everyone.