This page summarizes initial Sakai Product Council impressions in responding to the posted summary of 2.8 work at http://confluence.sakaiproject.org/display/MGT/2.8+Possible+Scenarios
Pre-draft draft. Consider this to be a document with gales of wind passing through it. The Product Council on June the 2nd felt that it would be a worthwhile effort to develop an impressions document in response to the Sakai 2.8 release taking shape.
A number of the proposed enhancements for 2.8 touch on broader themes that merit ongoing attention and improvement, such as accessibility and security. The PC is concerned that taking a one-release, all-or-nothing view of important but large or risky projects may be short-changing the long-term future of Sakai 2.x. Therefore, we will highlight those projects that we think are strategic, help lobby for increased resource commitments and, when all else fails, advocate for a multiple release strategy in which we can at least make partial progress toward important goals in the 2.8 time frame.
The following projects are considered strategic by the PC:
CKEditor upgrade - First, CKEditor offers very substantial accessibility improvements over the current FCKEditor. Second, CKEditor has active development and support, while FCKEditor does not. If the QA resources do not exist to test CKEditor in the 2.8 time frame, then we suggest investigation into taking some partial measure, such as enabling the toggling of editors on a tool-by-tool basis so that QA testing may be carried out throughout the 2.9 development cycle.
S3 Hybrid Support - Clearly, strong co-existence between Sakai 2 and Sakai 3 is going to be critical for a number of years going forward. The PC favors moving as much integration code into 2.8 as possible and also developing a multi-release road map to clarify exactly what we think we can accomplish in terms of hybrid functionality by which releases.
Maintenance Team reforms - As resources continue to be stretched, it is important to deprecate and eliminate unnecessary code as quickly as we can so that maintenance and QA coverage can focus on the components of Sakai that are actually useful to the community. The PC suggests the development of a multi-release road map for deprecation and elimination of legacy code. This will also require some coordination with new tool development and promotion. For example, Assignments 2 is nominated for inclusion in 2.8. We should consider if, when, and how, Assignments 1 should be moved out of core.
Security patches - As with maintenance, the PC suggests the development of a multi-release road map. That way, if security enhancements turn out to require more resources than are available for any given release, we can develop a phased, multi-release approach rather than just kicking the can down the road to the next release.
i18n - Internationalization is critical to Sakai's future. Once again, there should be a multi-release road map that commits to a sustained effort.
If a particular project nominated for inclusion in 2.8 is not on this list, it does not mean that the PC is suggesting that project is unimportant. It may, for example, fill a critical hole in functionality. The projects listed here are here because they fit with thematic concerns that we should be addressing in some way in every release.