See alternative proposals 2A and 2B under specifics below. Draft document of proposals still under discussion.
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)
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
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:
- 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.
- 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