Stanford Requirements

Charles Kerns responding to email:

> Charles, I'd like some help understanding your needs for next week.
> First, what's the show-stopper for your faculty to just make a site for
> each section right now? Granted it's kludgy, but with the ability to
> copy from site to site, it's no more than a few hours work at most to
> set up a flock of sections.

In our current system the faculty has to do nothing to get sections functionality in the CMS. This is because we do not have a new site for each section, but just filter based upon section membership for the tools. Students sign up for sections or are batch added or we get feeds from the registrar (we have three types of "sections") This means that is easy for faculty to have section-specific announcements, discussions, etc. Grading of students in sections and then viewing aggregate views of grades by the faculty of sections is simple, the quiz and test tools work the same way. So we have a full implementation of the tools supporting sections right now.

We do not want the faculty to revolt and demand that we keep Coursework-which they would if we only added "a few hours" to set up their sections-because they would also need to deal with continuously adding content, quizzes, announcements to each section during the quarter. Note: At Stanford the faculty run the farm. We can tell secretaries what to do--well maybe not, but the faculty run the academic side and we are completely user-focused on the CMS.

Also if the staff set up and then maintain sections then we will need another FTE or two. We are trying to simplify user support model because we did not get full funding (got about half) for our request for instructional support staffing. In fact we are transferring FTE from our multimedia content production support to CMS support.

So we need automated section setup and maintanence

For this reason it has been decided that we will not adopt Sakai until there is full support for sections: a section tool for instructors to manage sections, inheritance of content, announcements, etc. All of the use cases

> Second, are you looking for use cases for section implications in all
> tools?

Yes.

> Third, is it the case that Stanford does little distance education? The
> IU system does a lot of it, and our faculty are hollering about
> communication tools, not sections.

I think that Berkeley and MIT are similar to us in needing sections implemented for tools.

My understanding is that we will continue to use PHPBB with Sakai and build in the hooks for a local implementation. We had to just change discussion tools a year ago and the faculty dont want another change this year.

> That's generally followed by the lack
> of groups, but it's a distant third.

More from Charles Kerns

At 4/21/2005 01:17 PM, Altom, Timothy wrote:

> Okay, so let me see if I've visualized this correctly. Let me reference
> how Oncourse does it, and you let me know how Stanford differs.
>
> Here, we automatically create a site in our old Oncourse Classic for
> each course offered in our catalog, whether it's a "section" or not.

We cannot do that because the registrar does not know about sections for the courses which use scenario 1. There must be an easy way for instructors to create sections sites, for students to add themselves to section sites, for students to be moved from section to section, for content assessments etc to be fed to section sites, etc (see below for details)

> Technically, each course is its own section, and it's just the case that
> some sections are thematically connected at the next level up. W131,
> freshman comp, has many "sections" which are actually just courses. Each
> course/section has its own instructor, who may or may not teach other
> section/courses. Indeed, each instance of a course is given a unique ID
> each semester, so students are actually signing up for sections when
> they may believe that they're conceptually signing up for a course that
> just happens to meet at a more convenient time than another course with
> the same name.

This is like scenarios two and three below.

We have several scenarios for sections:
1) Scenario 1- large lecture course with discussion sections (examples Human Biology beginning courses, required intro to humanities courses):
the registrar lists the course as a large course and you cannot sign up for sections in the SIS. Students sign up the sections in the CMS (the feed from the registrar with courses has no section information)
Grades are given for the course and the registrar never knows about the section.
Students sign up for sections in the CMS with a seat limit of 20 per section.
The class meets twice for a total of 2hours per week in large lecture with all students in the course
The sections meet twice for for a total of two hours per week.
There are special tutorials for any drop in students for an hour a week.

There is one faculty member for the course
There are 5 instructional staff (non-tenure 3 year teaching post-docs) for 15 sections of 20 students each
The faculty member posts common content for al courses
The faculty member sets up a discussion for the whole course (the grip channel)
The instructional staff post special material for their three sections only
The instructional staff sets up a discussion for each of their three sections
The faculty member posts weekly on-line assignments
The instructional staff grades weekly assignments and returns assignments with the CMS and sometimes adds extra questions on unique material
The faculty member makes announcements to all sections
The instructional staff makes announcements to their three sections at one time
The facultymember posts take home exams
The instructional staff grades the take home exams either with one instructional staff grading one question for all students or with each instructional staff grading only their sections
The instructional staff may be locked out of viewing the grading of other instructional staff depending on the philosopy of faculty (it is a collaboration vs equity tradeoff)
The faculty member reviews grades for all sections and may make changes in grades

To summarize one big course with breakout meetings, same content (with some unique additions for breakouts), same tests, student signup for breakouts in CMS (the breakout sessions are called sections)
This covers about half of our courses with sections.

2) Scenario 2-courses taught with same content (what we often call multiple course offerings)-EG spanish 101 with 10 offerings of holding 20 students each:
the registrar lists the course only ass ections (there is no way to sign up for the course without being in a section)
Grades are given for the each section (not aggregated for a common course) and the grades are turned in to the registrar for each section through the SIS
Students sign up for sections in the SIS with a seat limit of 20 per section.
Each section meets three times for a total of 3 hours per week There are no other meetings.

There is 1 instructor (instructional staff or faculty member) for each section. (many instructors have more than one section)
There is common content for each section that all instructors agree upon.
The is unique material for each section as well
There is one discussion for each section
There are common weekly on-line assignments for all sections as well as unique assignments for each section (or set of sections if instructor has more than one)
The instructional staff grades weekly assignments and returns assignments with the CMS to students a
The department coordinator makes announcements to all sections
The instructor makes announcements to their sections at one time
The instructors agree on common take home exams delivered over the CMS
The instructors grade the take home exams either with one instructional staff grading one question for all students or with each instructional staff grading only the staff
The instructional staff may be locked out of viewing the grading of other instructional staff depending on the philosopy of faculty (it is a collaboration vs equity tradeoff)

To summarize lots of little courses with different instructors with coordinated content and assessment with some unique components (this sounds like what you describe)

3) Scenario Three one course with several different listings by the registrar (eg English 295, Eng 395, Eng 495
(this is like a cross listing but all are in same department)
This is basically one course but with different requirmentns (e.g. "section" requires major paper and exams, one requires only exams , one is only for graduate students and only gigantic paper and probably exams.
To summarize: All three have same content, discussions, announcements, etc. They have different assessments. The students sign up for their version of the course with the SIS.

> Given this inherent fragmentation, we elect to create sites on a
> one-to-one basis with courses. If an instructor is teaching more than
> one "section" that should be thematically connected (two sections of
> W131, say), the instructor can "redirect" the subordinate sites to a
> single "master" site, and administer all the sections from that one
> master site. A user accessing a subordinate site is told to refer to the
> master site. This does, however, require some setup time by somebody,
> faculty or departmental admin.
>
> In the instructor view in the master site, students are simply
> aggregated without regard to which course/section they came from. The
> instructor can alter this organization by creating groups that reflect
> the different courses. Again, this is not default behavior.
>
> This sounds to me a lot like what you're wanting in Sakai. However, I
> have one major question. In Oncourse Classic, we get around the problem
> of multiple TAs or equivalents by just having each course/section be its
> own little world that can be redirected if desired. Any course can be
> redirected or kept status quo, and any course can have one or more
> instructors. But the payment for this is behavior is that an instructor
> or someone else with privileges has to manually redirect at the start of
> each semester.

How do you deal with 80 % common content, assessments, announcements etc and 20% unique.

> It sounds as though what you're asking is that Sakai have the ability to
> automatically detect that various sections have a parent class, then
> construct a site for the parent class that automatically has sections
> delineated within it, and with the tools configured for that situation.

Yes this is critical for us and what we will do for scenarios two and three. The big issue for us is signup within a big course for the sections. What we need is to have a big course from the SIS. In this site the students sign up for their sections.

> Can't necessarily quarrel with that. However, how would you then deal
> with the problem of assigning different or subordinate instructors, as
> will almost certainly have to happen? How's it handled now in your
> current system?

Different scenarios handle it differently.