Child pages
  • Release Proposal 2009
Skip to end of metadata
Go to start of metadata

See alternative proposals 2A and 2B under specifics below. Draft document of proposals still under discussion.

Release Proposal

General Goals

1) A simple, measured introduction to a new set of product development processes (1)

  • Avoid unnecessary disruption to the momentum of development work to date
  • Provide the new Product Council space and time to work with development teams around significant new functionality

2) A reliable, published release roadmap (2)

  • A clear plan before QA begins
  • A plan designed around meeting the broadest user needs with the highest quality code while minimizing risk to target timelines (3)

Specific Proposal

1) A formal release management team

  • Initial members will include the Release Manager (Anthony Whyte), QA Director (Pete Peterson), and at least one recruited 2.7 branch manager (TBD, and more than one branch manager would be preferable)
  • These initial 3 members will in turn propose to the community formal processes for both recruiting additional members to this team and making decisions within its purview
  • This team will be empowered to make operational decisions about release management, up to excluding new code for QA or technical reasons, but will make proposals on list for community comment
  • Security-related issues will be managed in close consultation with the Security WG

    Two alternatives below

    2A) Independent tool releases before general QA

    • A general Sakai 2.7 feature release by April 2010, the general QA of which will begin before the end of 2009. It may include new tools reviewed by the Product Council.
    • Independent releases of Forums, Tests & Quizzes, and other tools prepared to work in this way before the beginning of general QA. (these tool releases should be intended to work against Kernel 1.1.x)
    • New tool releases must meet a set of criteria before the beginning of general QA, or the release team may be obliged to include a prior stable version of the tool instead.
    • The responsibility of organizing release management, QA and documentation for these independent tool releases will fall to the respective project team, although it's expected that other members of the community will be called upon to help.

    2B) Two feature releases over the next 10-12 months (4)

    • A 2.7 release which prioritizes lightweight refinements to existing functional components (i.e. components/tools already present in 2.6) by the end of 2009. This may include significant new capabilities if they can be worked through the Product Council process in time, and are not judged by the release team to put the deadline in serious jeopardy.
    • A 2.8 release which will include new tools and other significant new capabilities reviewed by the product council, but scoped to allow full testing and delivery by May 2010 (5)

3)2.5 and 2.6 maintenance releases, the number, scope and timing of each to be determined by the release management team

4) Supporting Kernel (K1) releases, the number, scope and timing of each to be determined by the kernel team, while the release management team determines the kernel version to which a given Sakai release will bind

5) The product manager will:

  • Shepherd the review and planning process up until code freeze
  • Work with the release management team to identify issues that need to go to the product council
  • Work with the release management team to produce an achievable published plan for the release(s)
  • Serve as liaison between the release management team and product council

6) The product council will:

  • Work to quickly establish straightforward but preliminary guidelines for inclusion in 2.8, and refine them through iterations of documentation and discussion with both the development teams and the wider community
  • Serve as a court of appeal where needed, where issues surface in conversation between the product manager, the release management team, and project teams

Next Steps

Weekly, open release meetings (i.e. anyone may join the discussion, though not all opinions may be formally binding) (6) will begin which will include the product manager and release management team. The product manager will coordinate and own the agenda, and early orders of business will include:

  1. An initial triage of proposed new features (7) :
    • determine which, if any, will need to go to the product council for review
    • identify where more documentation is needed from development teams, and communicate this out
    • make an initial risk assessment of various projects which can inform test planning (e.g. riskier changes may receive earlier QA focus)
    • establish realistic freeze dates for 2.7, based on time needed for QA, availability of resource, etc.
  2. The initial members of the release management team will work to propose (to the community) processes for how its decisions will be made and how members may be recruited


1. The new Product Development Process introduces new roles and new ways of doing business. There is a newly appointed product council, which will be working to establish a transparent process with clear criteria, and there is also a new product manager, among whose responsibilities is ownership of a Sakai roadmap. The new process is not going to achieve maturity overnight, especially at this time of year (Q3 2009) when many are preoccupied with both vacations and a Fall term, and so a balance needs to be struck that allows the council begin taking up its charge quickly but simply, without throwing off all forward momentum.
2. The community needs a reliable release roadmap in order to both contribute to the general effort and make preparations for its own deployments.
3. Release scope will be framed by an analysis of what can be managed and adequately tested under the constraints of available time and volunteer resource from the community. Functional priorities will require the guidance of the product council, but against this an achievable release management plan still needs to be developed. If such a plan seems impossible under the constraints of time and available resource, a proposal will go out to the lists for comment, one which either reduces planned features or extends the deadline (or both).
4. These two releases would correspond roughly to two different kinds of processes for reviewing release readiness of new development work. A "lightweight" process can be used for modest refinements or small additions to existing functionality, and typically won't involve the product council. A "heavy" process would involve product council review at a minimum, and typically passage through the entire product development cycle. Changes to existing functionality that the release management team deems significant (e.g. a big change to the UX, or involving some considerable technical risk) will be brought before the review of the product council by the product manager.
5. While QA and other release management processes are underway for 2.7, review and planning for 2.8 will also begin. To the extent that 2.8 involves significant new capabilities, this activity will happen at first mostly in the context of product council processes.
6. The meetings will publish minutes, document decisions, and send out any significant proposals to the list for community comment.
7. New features and plans from development teams are being collected in Confluence at: Proposed changes to 2.7

  • No labels


  1. Overall, this looks good to me, Clay. The idea of having a go-to person or each release is critical, I think.

    The the topic of features, the experience in the project to date is that the closer we get to a release, the more accurately we can predict what features will be included. Ultimately, features are only perfectly known at release time, as the release time (and the Product Council, in theory) have the ability to veto features right up to the last minute. Generally, we can only say that feature "x" is targeted at a particular release. As we start to separate tool release from the Sakai Enterprise bundle, we might gain some ability to predict more accurately (especially if tools are QA'ed independently).

    It is my belief that the idea of a project road map is unattainable. Put ideas on a page all you want. We (as a project) have no way to actually control what will happen. Further, the process is so uncertain that we cannot predict any any accuracy what will be included in future releases.

    • Mark
    1. Atmospheric dynamics are so complex that even the most sophisticated models have only a 60% success rate 5 days out, which is why forecasts typically don't go beyond that. I'd agree with you that we have a rather limited horizon within which we can make accurate predictions, but we can still get to a point where, metaphorically speaking, people know when to bring umbrellas or pack a sweater. Difficulty with precision doesn't mean we can't plan better - in fact it makes planning all the more important, so that we can adapt to the unexpected without losing our way. We can also articulate goals that fit within a broader strategy, helping us make better small-bore decisions along the way, and so when we talk about a roadmap it doesn't have to be at StreetView (TM) level.

  2. For me "Release Process" suggests a bit more along the lines of milestones, checks, and flows to get to a release - this feels a bit more strongly focused on Roadmap?

     I guess I'd expect to see a "Release Process" that included the elements about the Release Mangement Team, but didn't in and of itself talk about what was going to be in particular releases -- leaving that to a particular releases Roadmap. I would expect to see a bit more about QA - for instance, what QA steps have been defined? When are they performed? What is the trigger that takes a feature from "in development" to "in QA", and what kind of artifacts or documents need to be produced by whom...

    1. I think the basic idea is to try and accomplish a certain set of things over the course of the next year, and parts of it that prove to be helpful may be adopted as standard practice or "process," and parts that don't (or that are simply specific to a certain period of time) may be dropped.  If there's ambiguity between process and a particular proposal, I think that's where it lies - and is to that extent apt.  This is a trial and a migration strategy of sorts.

      I'll change the main heading to match the page title, in any event.

      1. Clay - you read your Confluence en francais? I was mighty confused at that email for a sec...

         I can appreciate what you're looking to do - I'm probably shaped since I just went through a major SDLC formalization exercise, which actually made a lot of questions/communications easier on my end.

  3. I think my views are known, but I might as well document them. I think we barely have the resources to manage and QA one release per year. Thus I'd like to see 2A. I'd be happy to see a focus on fixes, but the description from 2B seems appropriate: new features are encouraged as long as they can be QA'd in time, and don't compromise the quality of the release.

    I think the needs that 2B addresses can be met better by using 2.6.x for refinements and having only one new release. I'd be willing to accept small functionality changes in 2.6.x as long as they are low-risk, don't break any existing APIs, and don't change the UI enough to confuse users. We're not likely to be able to update documentation for a .x release, and we wouldn't want to see any of our functional additions break because of API changes.

    One thing I'd really like to see in 2.7 is gradebook improvements. There were some features for which APIs were added but not the UI.

  4. I favour 2A. Not because I think it is a more desirable release process, but because I think it will make QA more manageable.