Draft Stories for 2.4 Upgrade
Upgrade our SmartSite instances (dev, test, integration, and prod) of Sakai to 2.4.
1. Sakai Course Management. Prepare SmartSite to accept 2.4 Course Management. To complete this story, the following categories of work may be involved:
a. Conduct data mapping, e.g., how does 2.4 Course Management data map to Student Information (Banner) data to include course offerings and corresponding sections? Document the analytical results in Confluence.
b. Determine if we continue to use SmartSite provider architecture, e.g., what are the programming requirements for using 2.4 Course Management api's?
c. Interface with SmartSite GradeBook e.g., how will 2.4 Course Management section interfaces with our modified SmartSite GradeBook? What effect does this have on SmartSite's interface with Online Grade Submission?
d. Allow faculty to create course sites from a selection of their course offerings and sections, e.g., What is involved in allowing faculty to self select their course offerings and sections as is available in 2.4? Will we continue to maintain the batch create process that creates a course site for faculty? If so, we need a substory to make changes to the batch create process so that it interfaces with multiple sections.
e. Make changes to our SmartSite so that it appropriately handles roles in Course Management, e.g., graders, instructors, business officer, etc for course sites. First, we need a basic understanding of how this works in 2.4 course management. Then, we need to make sure we are following University policy re graders and who is authorized to assign and submit grades.
2. Sakai Views based on Mviews.
a. Make changes to our internal views to allow them to correctly interface with Course Management data for managing Scheduling and Course data.
3. Section tool.
a. Interface with SSRMEET data, e.g., Translate SSRMEET data in our Sakai internal views based on CRNs assigned to the course site.
b.
6. Conduct analysis on managing the 2.4 code with Foundation and our Subversion branches.
--Document the process.
--How frequent is the rotation among programmers?
7. Enterprise ID, the internal ID, and Display name.
--Conduct analysis on the use of Enterprise ID, Sakai's internal userID and Display name. The purpose of the analysis is to understand the best usage for each data element vis a vis SmartSite tools. One suggestion that's recently emerged is whether or not we can use WhitePages' Display or Nickname for some of our tools.
--Document the best case usage.
--Make changes to our SmartSite data / programming where necessary to implement the discrete usages per tools
--Write code to intercept getDisplayId Method and return displayId/displayName as appropriate per tool
10. Define additional roles and permissions for the 2007-2007 academic year.
11. Gradebook
a. Conduct analysis to identify changes to GradeBook for 2.4, particularly how faculty will grade sections and interface with Online Grade Submission.
b. Research if changing #7 code writing would allow StudentId to be used in Gradebook and
c. Use (b.) to match import of Clicker Rosters/Grading data
d. Test if existing import capability in Gradebook is sufficient to import Clicker data as is (probably still need Excel Macro or other script to reorder that data)
12. Current Providers (3 of them).
a.Conduct the analysis to identify how our existing providers will change for 2.4.
b. Make change to SmartSite providers to interface with Sakai 2.4. This is in the context of course management above.
13. Implement the process for programmer rotation for work on bugs and trouble tickets each week.
14. Design strategy for routing MyUCDavis users from the portal to SmartSite. Take into account whether we can identify where a particular course is hosted and alter the links to course sites from the portal appropriately. Also determine if the strategy should change as the 2007 academic year progresses and we edge towards the mycourses cutoff date. A proposal or set of proposals are needed from the programmers as to what is possible and we need to then involve some faculty in the review.
15. SCORM Tool
16. Common Cartridge - not well enough defined to consider this for website builder import via file import in Site Info at this time. Further follow up with Zach required (Lisa)
17. Contact Us Application - button at top? Just change velocity template. Might be related to "get out of SU status"
18. Website Builder Test Plan: WebDav import of Wesite Builder needs to be stress tested
19. Implement 2.4 Sandbox
-- Apply current providers to 2.4 for testing in Sandbox?
-- Allow for testing of faculty creation of new sites with real rosters possibly using Scott's CM provider
20. jsMath needs more testing re fonts, Global problem and when/if to activate the javascript (e.g. when math macro exists on the page.
21. Monitoring implementation: requires some DB changes that IU code depends on (Long's -> CLOBS)
22. Define specification or usage stats needed / implement Stat Tool (Kirk,Sandra,Corey/Michael Wenk)
23. Short Answer excel export from Samigo for TRC
The Resulting Topics and Stories
Topics
Stories (not associated with any Topic above)
Not applicable to this iteration
4. Schedule Tool
a. Interface with SSRMEET data, e.g., Translate SSRMEET data in our Sakai internal views such that scheduling data is managed in the Schedule / Calendar Tool.
b. Port academic calendar to the Schedule Tool.
c. Port students' and facultys' course schedules to the Schedule tool.
5. Conduct analysis on the Message Center split and the affect on existing messages and forum topics.
8. Verify that Sakai 2.4 is compatible with our RAC implementation.
--First step: test RAC against 2.3.x on SmartSite-Test
9. Verify that AFS differentiated is compatible with Sakai 2.4.