Child pages
  • Promote-2.4-UserMembership
Skip to end of metadata
Go to start of metadata

Promotion of UserMembership from Contrib to Provisional

See the Comment section at the bottom of this page for discussion on this tool's promotion.

Provisional Criteria Matrix

The table below is derived from the Criteria for Provisional Status document and is intended as a quick-reference guide on how this tool measures up to the requirements for a Provisional tool.

Key:
(tick) Criteria met.
(warning) Work needs to be done to meet criteria.
(error) Will not meet criteria by code freeze.

Community Support Criteria

User Membership

There must be an identified group of committers within the Sakai community who take responsibility for the tool. This group can be comprised of the original author(s) or others from the community willing to take responsibility for the application.

(tick)

The application source code must reside in Sakai's source control system. Organization and management of the source control system is defined in a different Sakai Community Practice (to be determined).

(tick)

At least two Sakai production sites must be utilizing the tool successfully in their production environments. Those sites should be able to report that the tool runs properly and is useful to their users. These sites must also report that the application does not cause any problems with other parts of the Sakai release such as poor performance, memory leaks, etc.

(tick)

The developer(s) of the tool must be committed to maintaining the application across Sakai version changes including any necessary data conversion for their elements of Sakai if storage structure changes.

(tick)

The developer(s) of the tool must be willing to answer questions about their application on Sakai dev list.

(tick)

The developer(s) of the tool must commit to helping to develop test plans and specifications for the application. Until those test plans are in place, the author(s) will commit to join the Sakai release/QA process and perform the necessary QA on their application. To become an official tool, the author(s) of the tool must contribute test plans and specifications (to satisfy the requirements of the QA group).

(tick) (3)

Bugs and feature requests for the tool must be tracked in Sakai's bug tracking system.

(tick)

Technical Elements Criteria

User Membership

If the tool persists data to a database, it must support all official Sakai databases (currently HSQL, MySql, and Oracle).

(tick)

The tool must work properly with the Sakai AutoDDL approach. The application must properly create tables when tables do not exist and the tables must be named so as not to conflict with other Sakai tables.

(tick)

All database access to tables that the tool does not own will take place via published Sakai APIs provided by the application that manages those tables. The tool should use APIs for access to its own data, but it must use APIs for access to data from others.

(error) (2)

The tool must participate in the system-wide configuration (sakai.properties) and not require any local configuration to be hand-edited.

(tick)

The tool must properly operate in the Sakai Authorization and tool placement structure. It must either use existing appropriate security functions or introduce new security functions for the application.

(tick)

The tool will not require patches to other Sakai tools or to the Sakai framework. A application may require changes to other areas of Sakai, but those changes should be negotiated ahead of time and should be part of the full distribution.

(tick)

The tool must fully work in a clustered Sakai application server environment.

(tick)

The tool cannot force new jars into shared/lib or common/lib. Sakai's goal is to keep these jar footprints as small as possible. Any new jar requirement in those areas requires significant discussion.

(tick)

There are a number of system-wide elements in Sakai including Spring, Hibernate, and others--the application must work with the versions of these elements that are part of the Sakai release.

(tick)

Licensing must be clean before the application is moved into Sakai's source control system and put into a Sakai distribution. The license must not violate the policies set by the Sakai Foundation. This also means that a tool cannot require other application or jar with a proprietary or ECL-incompatible license to be part of the distribution.

(tick)

Interaction and Visual Design Criteria

User Membership

The tool UI must look like the rest of the Sakai application and properly inherit skins from Sakai (i.e. when the sites color changes the tool colors change as well). The tool should not look "out of place" amongst other Sakai tools.

(tick)

The tool should follow general interaction guidelines outlined in the Sakai Style Guide (SG) so users have consistent experiences and expectations about how to complete actions such as "paging in a list", "navigating between pages", "taking action of items in a list", etc across tools. The SG is a guide and should be used to help inform interaction decisions but is not meant to have all the answers.

(tick)

UI components available in the Sakai library should be used where possible (e.g. wysiwyg editor, calendar, paging widget).

(tick)

The application must support all of the browsers currently supported by Sakai including FireFox/Mozilla and Internet Explorer.

(tick)

The tool should provide basic help which integrates seamlessly with the Sakai Help system. The help should have a look and feel and writing style similar to the other elements of help.

(tick)

Desirable Elements Criteria

User Membership

The tool is properly internationalized with all of its user-displayed strings derived from properties files.

(tick)

The tool should be fully accessible and pass a Sakai accessibility review.

 

If the tool has any persistence or business rule code it should be factored into a Sakai Component with a published API which has complete javaDoc.


This component should be designed so as to allow other applications and/or system processes to be able to work with the business objects handled by the application.


Creation of web services API for the tool. The authors should provide a web-service layer which sits on top of their API.

 

The tool should participate in the Sakai cross-site import and export if it persists business objects.

 

The tool should be inter-operable with other Sakai tools where appropriate.

 

The tool should generate event codes that are triggered minimally on new, revise, and delete actions on the basic objects created by the tool.

 

Hibernate is not required but if the tool is doing significant ORM, it should be done using Hibernate - the application should work with the current version of Hibernate used in the Sakai release.

 

In order for Sakai to seen to be a seamless application, effort needs to be made to minimize overlap in functionality with other Sakai "bundled" tools. At times, as tools are evolving, or complete replacement tools are being produced, overlap is acceptable. Where overlap will happen between tools under consideration, developers should first look to fixing/improving the existing tools rather than simply writing a new tool with a few features. Each tool which adds overlap may result in the long term need to "clean up" the overlap to maintain a good user experience.

 

Notification and Process Criteria

User Membership

30-day notification prior to code freeze of: (1) What is is, (2) How to install/configure it, (3) Known issues, and (4) Whom to contact

 

Notes:

  1. Will be provided/changed if tool get promoted
  2. Cannot make any progress on this until SAK-6792, SAK-6793, SAK-6794 are resolved (see below)
  3. 2.4 QA will be performed manually. Test plans and procedures will be made available after 2.4.

  • No labels

3 Comments

  1. From Nuno Fernades' email to sakai-dev (Sent Thu 11/23/2006 6:15 AM EST):

    UserMembership is currently dependent of the following JIRAs in order to be
    considered as Provisional:

    • SAK-6792: Ability to search external users
    • SAK-6793: Improve performance of SiteService.getGroupsWithMember()
    • SAK-6794: Ability to search sites user is member of (published and
      unpublished)

    The tool is currently using direct SQL because of some missing features
    on the (User and Site) API.

  2. User membership is an invaluable support tool for us. Our support team uses it multiple times per day. Its user search feature is significantly better than the existing Users tool, it adds additional features (CSV export), and reduces the workload involved in investigating support issues considerably.

  3. We started using it in January in production, and I'd echo the things Stephen is saying. It's been so useful for support, in fact, that I take the note about direct SQL (from Peter's quote above) to be a sign of how the User and Site APIs need to be improved - not to mention once again exposing the limitations of current core admin tools.