Sakai Community Practice [TBD]

Tool Status Requirements

Recommendation Level: Required

This is a required practice.

Audience

This practice applies to developers and contributors who desire to have a tool distributed with the Sakai Enterprise Bundle.

Purpose

The Sakai development community indicated a desire to improve the overall quality of Sakai tools at the Atlanta Project Coordination Meeting, 8-9 December 2006. This document simplifies and extends requirements from Criteria for Provisional Status.

Description

Sakai tools fall into one of three categories:

Contributed: Tools we're not comfortable with and don't know enough about.
Provisional: Tools we're getting comfortable with.
Supported: Tools we've been using and we're comfortable with.

This document defines requirements for provisional and supported tools more precisely than Criteria for Provisional Status specifically to make enforcement and testability easier. It does not invalidate this earlier document which explores background, rationales, and desired elements of Sakai tools. This document is purely focused on what is actually required.

1.0 Tool Status Requirements

1.1 Provisional Tool Definition

A provisional tool is defined as a tool that is included in a Sakai release but excluded from the list of tools presented to the user when they are configuring their site through site setup. A method is provided to allow provisional tools to be activated during the configuration process.

1.2 Supported Tool Definition

A supported tool is defined as a tool that is included in a Sakai release that will be fully supported by the community. This support includes response to bugs, good documentation, and a team of developers willing to answer questions. It is visible by default in administration tools.

1.3 Requirements Matrix

These requirements are defined for Sakai 2.4 planned for a May 15, 2007 release.
Requirements enforced in Sakai 2.4 are marked with a check . Deferred requirements with a cross .
Requirements who's status is unknown or open to discussion are marked with a question mark .

Number	Description	Provisional Tools	Supported Tools
Support
1.1	Identified group of committers.
1.2	Source code in SVN.
1.3	Two sites in production. Recommendations.	One	Two
1.4	Commitment to maintenance.
1.5	Question responders.
1.6.1	Design and specification document.
1.6.2	Q/A process participation.⁵
1.7	Bugs and features tracked in Jira.
Technical
2.1.1	Support for 3 databases.
2.1.2	Initialize databases appropriately.
2.1.3	All data access via APIs.
2.2	Configuration via Sakai properties.
2.3.1	Operate properly with Sakai authorization.
2.3.2	Operate properly with tool placement.
2.3.3	Use existing or publish security functions.
2.4	No patches to other tools or framework.
2.5	Must work in clustered server environment.¹
2.6	No new shared JARs.
2.7	Work with existing technology versions.
2.8	Clean licensing.
2.9	Compiled code must run in Tomcat.²
Interaction
3.1.1	Support the Sakai user experience.^3,4
3.1.2	Inherit skins from Sakai.
3.1.3	Follow Sakai Style Guide.^3,4
3.2	Use UI components where available.^3,4
3.3	Render to supported browsers.
3.4	Provide basic help.
Other
4.1	Internationalized from external strings.
4.2	Accessibility practices.⁴
4.3	Separation of application services.⁶
4.4	Web service API.⁶
4.5	Participate in import and export.⁶
4.6	Interoperate and integrate with other tools.⁶
4.7	Generate event codes.⁶
4.8	ORM Support.⁶
4.9	Minimize functionality overlap.

Notes
1 - Clustered environments may need more definition.
2 - This is a new requirement added by Steve Githens to cover cases where code might be generated by non-Java langauges. This code must be Java compatible and be packaged appropriately as JARs or WARs.
3 - Deferred pending clearer definitions, requirements, and evaluation methodology.
4 - Deferred pending improved system support.
5 - Later, this requirement will call for a test plan document.
6 - Originally defined as optional.

2.0 Conformance Process

In addition the previously defined application process, the following enforcement / conformance process will be implemented started with release 2.4.

(TBD)

Document History

All major changes should be recorded in the following history table:

Version	Date	Contributors	Description of Change
1	2/3/06	Charles Severance	Copied from a document submitted the SCP-PWG.
2	3/9/06	Mark Norton	Document updated to reflect SCP discussion on 2/22/06
3	3/15/06	Anthony Whyte	Minor text revisions; typographical, syntactial/grammatical errors corrected.
4	12/12/06	Mark Norton	Candidate draft based on actions assigned at the Software Coordination Meeting, 12/9/06. Added section numbers.