Draft - Work in Progress
Release Process Proposal
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 a recruited 2.7 branch manager (TBD)
- These initial 3 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
- Security-related issues that impact release planning and timing will be managed in close consultation with the Security WG
2) Two releases over the next 10-12 months (4)
- A 2.7 release 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 2.8 release which may 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)
- 2.5 and 2.6 maintenance releases, the number, scope and timing of each to be determined by the release management team
- 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
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(s)
- Serve as liaison between the release management team and product council
4) 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, as issues of new functionality may surface in conversation between the product manager and release management team
Weekly open 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 review of proposed new features (7)
- determine which 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) formal processes for how its decisions will be made and how members may be recruited
- The product manager will document significant changes for 2.7-2.8, and coordinate their review by the product council.
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 both vacations and Fall term preoccupations hold sway, and so a balance needs to be struck that allows the council begin taking up its charge quickly but simply, without throwing all expectations and ingrained habits into sudden confusion.
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, and on this basis some proposed new features may have to be postponed for a future release.
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 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