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

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Draft - Work in Progress

Release Process Proposal

General Goals

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

  • 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

    The new Product Development Process introduces a couple new roles and a new way 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 when both vacations and Fall term preoccupations hold sway, and so a balance needs to be struck between having the council take up its charge quickly and not throwing some ingrained habits and expectations into sudden confusion.

    2) A reliable release roadmap
  • 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

    Release scope will be framed by an analysis of what can be managed and adequately tested under the constraints of available time and declared volunteer resource from the community. Functional priorities will require the guidance of the product council, but on this basis some proposed new features may not make the cut for a given release.

Specific Proposal

1) A formal release management team

  • Initial members will include Pete Peterson (QA Director), Anthony Whyte, and a recruited 2.7 branch manager
  • These initial members will in turn propose to the community a formal process by which others may be recruited to this team, and a published decision-making process
  • This team will be empowered to make operational decisions about release management, up to excluding new code for QA or technical reasons

2) Two releases over the next 10-12 months

  • A release (2.7) which is limited to lightweight refinements to existing functional components (i.e. components/tools already present in 2.6) by the end of 2009
  • A release (2.8) which may include new tools and other significant new capabilities reviewed by the product council, but scoped to allow full testing and delivery by June 2010.

    These two releases would correspond to two different kinds of processes for reviewing 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 at all. A "heavy" process would involve passage through the entire product development cycle.

    3) 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 a published plan for the release
  • serve as liaison between the release management team and product council

4) The product council will:

  • work with development teams to establish clear criteria early (Sept at the latest) for inclusion in 2.8
  • serve as a court of appeal where needed, as issues of new functionality may surface in conversation between the product manager and release management team

Next Steps:

Weekly open meetings (i.e. anyone may join the discussion, though not all opinions may be formally binding) 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:

  • an initial review of proposed new features to (MJK: is this across 2.7/2.8?):
    a) determine which will need to go to the product council
    b) identify where more information is needed from development teams and
    c) make an initial risk assessment of various projects which can inform test planning
    d) establish realistic freeze dates for 2.7
  • the initial members of the release management team will work to propose (to the community) formal processes for how its decisions will be made and how members may be recruited
  • documentation of meetings will go on confluence. any significant proposals will be sent out on list.


Planned changes to 2.7:

  • No labels