Child pages
  • Sakai Technical Management Committee Proposal
Skip to end of metadata
Go to start of metadata

The TMC proposal was drafted during the December 2007 Newport Beach Project Planning Meeting and later debated during the course of a series of follow up technical BOF sessions during the Sakai Newport Beach Conference. The proposal was laid aside during these discussions in favor of a less centralized approach to Sakai technical leadership. See the draft Sakai Developer Practices document for more details. A. Whyte.


The team will be known as the Sakai Technical Management Committee (TMC).


The TMC will oversee the technical evolution of Sakai software, providing leadership, guidance, processes and priorities for the Sakai developer community.


The TMC will be composed of up to seven (7) members, nominated and elected by members of the Sakai Community who are members of the Sakai Developer Discussion Group. Candidates for the TMC will each secure and state publicly the amount of time they can commit to TMC activities. The expected time commitment of individual TMC members is one calendar year and will represent between 10 to 40 hour a week time commitment.

Elections will occur by the end of January 2008.


Internal TMC governance will be determined by the members of the TMC. TMC processes and priorities will reflect the values of the Sakai Community.

General Priorities

The TMC will work to improve the reliability, maintainability, performance and utility of Sakai software.

As a first milestone the TMC will review the set of technical goals outlined in the Sakai Technical Goals (towards a roadmap) document and derive a set of related tasks to work on in support of those goals.

Possible Tasks

In discussions to date, there seems full agreement that a short-term goal will be creation and maintenance of automated regression and load tests. Without tests in place to ensure stability, other changes may be too risky to pursure.

Other goals targeted over the year are likely to include:

Reliable and supports High Availability

  • Regression and load tests will be verified, validated, and heavily used by the QA team
  • Sakai should be a reliable service and should be able to run continuously
  • Server should be stable enough to stay up over long periods without requiring restarts
  • Kernel code quality should be protected and insured via a set of best practices

Reduce support costs

  • Continuous maintenance tasks should be removed/minimized
  • Data validity should be protected by the system
  • Data should be readable by system operators in the storage medium
  • Configuration should be well documented and easy to use
  • Kernel services should have plugin points to make extension and customization easy
  • Consistent and flexible group management
  • Archiving and restoring sites must be supported
  • Server should be able to undeploy and redeploy webapps and components without restarting
  • Server should be able to run continuously without needs for restarts

Easy to install and get up and running in a day

  • Unit/Integration tests throughout the framework/kernel code which can easily be run to guarantee system is functioning properly
  • Common enterprise integration approaches should be easily enabled and configured without requiring code changes
  • Installation should be well-documented, easy, and as automated as possible

Able to handle many users per app server (with relatively modern specs)

  • Database load should be reduced/minimized
  • Heavy usage of memory should be reduced/minimized

Easy to develop new tools and apps to run in Sakai

  • It should be possible to get a development instance of Sakai working in less than one hour
  • Sakai service APIs should include detailed javadocs and should be intuitive to inexperienced developers
  • Setting default Authz tool permissions should be simple
  • Support for cross-tool navigation
  • Support for archival and restoration
  • Support for modular addition and upgrades (one new application or service without updating everything else)

URLs that make sense to users (also called "clean" URLs)

  • URLs in Sakai should make sense to users and they should adhere to normal web semantics
  • Bookmarking a page should create a stored URL which will bring the user back to that page
  • No labels