Conditional Release
Initial Documentation
|
Zach Thomas (Aeroplane Software LLC) |
|
Confluence Home: http://confluence.sakaiproject.org/display/CR/Home |
What the project aims to accomplish and who should benefit from it - explained in clear, simple language.
Conditional Release is a feature which allows a worksite maintainer to specify a condition that must be met for some piece of content to be shown ("released") to other users, typically students. It essentially offers rules-based access control to Resources.
The original motivating use case for Conditional Release is the ability to have resources (files, folders, etc.) become visible to students only after some Gradebook condition has been met (e.g., their grade on a particular assignment is above or below a specified threshold).
Which institutions and individuals are committed to it, for how long, and in what roles.
Zach Thomas is the author of the code and has been engaged by Rutgers to shepherd the project from incubation to release. Rutgers and Georgia Tech have both offered to support Conditional Release for at least a year. Zach will be available to answer questions for the foreseeable future.
What other projects, if any, does this project relate to or depend upon?
The project requires modifications to the K1 kernel, the content module, and the gradebook module.
What does the project know and not know about how it will achieve its aims at this point?
The primary use case (applying conditions from the Gradebook onto the availability of items in the Resources tool) is already written and refactored to work in the 1.1-SNAPSHOT K1 kernel. We will need a little more code to satisfy the additional use cases, including op-in configurability, and appropriate handling of Resources notifications (email).
We will need to write QA use cases and identify specific points of contact for Conditional Release QA. This person or persons will be the owner of any Conditional Release issues in JIRA.
What public communication methods are being used, how may a curious person contribute to or track the project?
Significant milestones or technical questions will go out over the sakai-dev mailing list, and more frequent updates will appear in the Confluence space.
Anyone may contribute to the design, the implementation, the documentation, or the project plan by creating JIRA issues and assigning them to Zach, or by submitting comments and/or patches via email or wiki.
Ongoing Documentation
September, 2009: The project entered incubation with the intention of making the 2.7 release of Sakai. Zach wrote the use cases and created the detailed status board available at the project home space.