2006-02-08 Project Kick-Off Notes

Owned by Former user (Deleted)
Last updated: Apr 04, 2006Version comment
8 min read

Course Management Re-Kick-Off Meeting - February 8, 2006 @ Stanford

Project Scope Summary

  • Finish Course Management API
  • Design and implement new APIs to handle sites and memberships
  • Design and implement new UI for site memberships
  • Design and implement new UI for site set up (tentative)

The Course Management WGs strategy

UI Design and Functional Requirements

  • Extensive user research during phase 1
  • Determine intermediate deliverables without necessarily coupling it to user research, possibly by adding limited functionality to existing tools via Course Management API
  • Modelling of users and their goals (personas)
  • Vetting of existing requirements and possible inclusion Sakai 2.2 and beyond requirements.
  • Framework definition (views & panes, scenarios, etc.)
  • Design (mockups and functional specs)

Site and Membership APIs Design and Implementation

  1. Re-engineer Site and AuthzGroup APIs
  2. Write hibernate-based impls of these APIs
  3. Write adapters for legacy APIs
  4. Swap out legacy impls for adapters

Course Management API

Rough Timeline - 2 Phases

Phase 1 (for Fall '06)

  1. Redesign API of membership and sites so they are decoupled from legacy code.
  2. Create new implementation for these APIs.
  3. Finish Course Management API and service based on what we've learned.
  4. Implement a limited set of functional improvements enabled by Course Management API, limited UI changes (TBD)

Phase 2 (for TBD '07)

  1. Implement a more robust set of CM functional improvements, significant changes to admin tool(s) UI changes (TBD)
  2. Refactor tools to use the new APIs
  3. Remove legacy services. Move the new APIs and implementation to common.

Code location

  • We will build in the trunk, which requires committer access to Commons and new CSM module service.

Discussion

Development platform discussion:

  • Had legacy system (CHEF and before)
  • Sectioning pushed for an intermediary CM
  • At same time Chuck asked Mark Norton and Craig Counterman to design a new CM service
  • Yesterday (at Kernel Bundle training) Mark presented all 3. Would like to see how we can build on the new service with a solid model moving forward.
  • Need development platform on which to build allow all the institutions to do what they need. Mark presented 2 options:
    • Option 1: Kernel bundle. Too small to be the foundation for CM. No authorization, no groups, no sites, etc.
    • Option 2: Stripped down version of Sakai, common services, selected legacy services (any other option?) but no tools. Stellar is an example of this strategy; its tools will be able to live on top of this platform.

Discussion of proposal for moving forward:

  • This is a requirements driven project
  • Steps 1-3 of these are required to move the project forward. This is when we can start building a CSM tool(s).
  • Start in the trunk, move to a branch only if necessary.
  • Backwards compatibility needed when updating legacy services
  • What if there are dependencies on legacy bugs upon which we'll be building?
  • Code and design review will be part of this project
  • What's the most expedient way to move this forward?
  • Build to the requirements.
  • We want to accomplish site sectioning tool moving forward...bring in new API, etc. In order to do that we need to change the way the membership is handled.
  • A second project is to write another implementation of sites based on hibernate.
  • Should we consider a long term project to move the sites implementation forward.
  • Refactoring of legacy can be done by modularizing the legacy services. Spaghetti code makes this difficult. Lots of dependencies. We can't rewrite all the legacy services. But we could limit the number of tools we want to move forward. Sites and realms are the important ones for Course site management. There is a contingency of people that don't think we should modularize. What about tool suites?
  • Functionality can be tightly integrated even if they are not on the technical side.
  • Add backward compatibility as a requirement (alternative is to back fit our new stuff). This is backward compatibilty of functionality not code.
  • We will not break any existing tools. Will require re-implementation of Site API with adapter.
  • We will cause refactoring of tools not in the trunk
  • Find services that we can bless and move forward with...move them into commons.
  • What about things that are built on bugs? We may break lots of UI stuff. What is the cost if we don't fix this now?

More...

Marc: Oliver suggested talking about the two phase development approach before talking about resources. User research & UI design isn't done yet, so it couldn't effect things by the fall, and UCB needs to show progress.

Oliver: Doesn't know the specific pressure, but we're asking for more developers & we need to justify the expense in progress by showing that we react to user demands.

Josh: Good to have some deliverable in the fall just as part of iterative development.

Oliver: The Gradebook seems like a good place for course info to show up.

Ray: In terms of natural fit with the development cycle, integrating Section Management with official data may be best.

Oliver: "Managing my site" usually means tool setup to our users; "managing my course" is memberships.

Marc: The abstract customer is better integration. Casey has been delivering warnings about problems at Stanford, too. There'll be courses which can't be supported in production. With a schedule end point of July, though, it's aggressive to try to produce something & not break what's there.

Daphne: Can we go back to the goals?

Duffy: Course information management. Course site administration. So far we know that this will entail a redesigned site membership, a revised course management service....

Mark: Goal is to draw information from admin & SIS & mix with manual admin in Sakai sites.

Daphne: What about the other part of "course site management"? The course information that becomes site content, not membership.

Josh: If you can come up with the tasks, we can talk about ordering them.

Marc: Less research-oriented institutions are likely to want to have more out of the box and less personal tweaking.

Daphne: What are the pain points that we want to solve? 1) The integration: have the data flow in easily. 2) Faculty & staff: how to present their course online. 3) Faculty & staff: how to handle the people in the course: have the data available in ways that are understandable.

Mark: I have heard that Glenn is working on import/export now....

Marc: If we integrate enterprise data, we need to give instructors the chance to administrate it.

Josh: Yes, the site administrative tools should be designed around user workflows. It's possible that content & membership might still be combined even in the new user interface. But there are different tasks & operations going on beneath the surface.

Marc: Once we've done a couple of months of research, we might come back & ask for more or change priorities.

Duffy: Is this really phase 1 & phase 2? There are parallel tasks going on.

Ray: We'd like a close cyclical relationship between service, UI research / specs, & app delivery.

Marc: First phase: Programmers do service cleanup while user reps get enough info for the coding to go forward for Fall '06. Next phase: User research continues on course site set-up for instructors. Programmers do the course membership development in parallel.

Daphne: What's the Fall '06 goal?

Ray: Seems to be left to our pragmatic choice: "visible progress", rather than driven by user priorities.

Mark: What has been the response to the Section Info tool? Let's find the users & ask them.

Oliver: The problem is without direct feeds the largest courses have been less likely to use them.

Josh: Getting lots of kickback on wanting to see enrollment status, & a little for better support of ad hoc groups.

Marc: Design will be iterative with frequent milestones during CSM application development. For first pieces, we should keep a limited team. Then we can look at expanding.

Oliver: Is there a conflict between iterative design & scale of what needs to be done?

RESOURCES

Marc: Moving to the known resources.... Lydia & Daisy probably at most 50% time until April/May due to Samigo.

Lydia: Stanford is looking for someone to maintain Samigo.

Marc is 75% available as of now. Hoping to go down to 5% on Samigo.

Duffy: Probably won't be able to help much with development, but can help with design & management & outreach. Maybe 25%

Mark: 1% time - for review, etc. Too taken up with MIT coding.

Oliver: Watching; managing. We're in production now; going to be a Fall deployment....

Josh: 75% time.

Ray: Some transition overhead for hand-off of Gradebook, mentoring, and miscellaneous architectural work. Hoping for 75%.

Duffy: There may be other resources withing the wider Sakai.

Josh: More bodies doesn't necessarily mean less time.

Daphne: 30%? Judy Stern available too....

REQUIREMENTS AND INITIAL TASK ASSIGNMENTS

Marc: We have the set of requirements from the Berkeley meeting. Some new requirements may come out of the design work. How much can be done by 2.5 FTE before July?

Josh: Daisy for course management API changes?

Daisy: Prefers list of tasks & assignments.

Mark: One requirement is to retain the sources of data for history & reconciliation – membership records may not be the right spot.

Ray: How many sources of data are there, typically?

Various: Usually only two: internally administered and externally provided.

Daisy: CourseWork supports self-registration on top of manual admin & official rosters. But it's suggested that instructors don't allow all three, because it gets too confusing.

Duffy: Arizona might have a long-distance registrar as well as a local registrar. But no mixing of enrollments in a single site.
not a "long-distance registrar" but the Learning Technologies department may offer for-fee/non-credit courses over the Internet --Duffy

Marc: Can we ballpark the requirements? Or do we need to break into teams to scope them out?

Oliver: Let's review them first. Backwards compatibility.... Do we need to maintain the Roster functionality as well? (Yes.) Need to replace it? (Oliver thinks so.)

Missing from "Requirements": Be able to easily model site groups to match complex course hierarchies.

Marc: We should send a list of scenarios for section hierarchies & get responses from schools: What's been missed? What are the priorities?

Ray: Missing implied requirement: Admins/instructors must be able to view course offering metadata (course title, credits, department, etc.), to default some site metadata to those values, or to override them.

Missing requirement: A departmental administrator.

Ray's tasks:

  • Send list of names to hit up for data to Marc & Duffy.
  • Review existing Requirements / Feature Requests against our list & document them on our Confluence site.

Everyone has the task:

  • Send big communications to local WG first before sending them to a larger audience.

Weekly WG meetings on Tuesday at 10 AM, Pacific Time.

  • Next week: Programming and user-rep teams will start breaking requirements down into estimatable tasks.

Josh: How do we make changes in the CM API since Mark has so little time & Craig's no longer involved?

Mark: Try the discussion list for a sanity check?

Marc: Green Array - Mikado is trying it out, & Stanford's likely to settle on it for project management.

Ray: It's better when I have a granular list of tasks that I can look at daily for my to-do's. Jira is really nice for this.

Marc: I'd rather use something that people will update everyday. If it's something that people are used to like Jira, and we can bend it to meet PM needs, Jira is fine with me.

Near-term Course Management API tasks

  • Get data mapped from real schools. Look at results. (Task for all.)
  • Describe application client usage. (Ray & Josh)
  • Put call out to enterprise group for more data mappings & scenarios. (Ray should probably formalize last year's Integration of Web and Institutional User Groups and Course Management Scenarios to serve as a starting point.)
  • Clean-up: Standardize method names. Avoid unnecessary interface extension (e.g., Persistable).