User:Vtaylor/moodle metacourses

Moodle docs

• http://docs.moodle.org/en/Metacourses

Kevin's note

taking another look... annotated

There are actually a couple of separate issues, and I'll try to point out where they are - different needs (and different solutions?).

Re: Catalyst courses that are persistent

Hi Valerie (et. all),

I'm still trying to understand the root problem behind this, so please bear with me for a moment. As I read your initial email, the problem appears to be that student data needs to be persistent across quarters;

--Vtaylor 00:57, 9 July 2008 (UTC) yes, the problem stemming from our experience that faculty usually take more than one quarter to complete the work. We cut down the work somewhat, but we really want faculty to cover the breadth. Some spend more time on each topic than is strictly necessary, but there isn't a good solution to that "problem" yet.

secondarily, the current Catalyst process/system does not allow student data to be copied from one class to another.

--Vtaylor 00:57, 9 July 2008 (UTC) where "class" is CAOS / TSLR in Fall 2008 and "another" is CAOS / TSLR in Winter 2008 on the production server

I'm afraid I don't fully understand the intricacies of college enrollment management, so please excuse me if the below betrays my ignorance. Is the following scenario how we currently address the persistence issue for on-campus classes?

"A student enrolls in a class (for example, CAOS 198Y) during the Fall Quarter of 2008. This student completes some of the work, but not all of the work.

The student is given an incomplete for fall.

--Vtaylor 17:14, 8 July 2008 (UTC) current thinking - grades are going to be Pass or No Pass. We will not give a grade of Incomplete as that has administrative (paperwork) requirements.

During Winter 2009 (or even Spring 2009), the student complete the requirements for the course. The incomplete is then changed to the appropriate grade.

--Vtaylor 17:18, 8 July 2008 (UTC) register for next/later quarter, complete requirements and get Pass grade for that quarter - should be ok to require this be within the same school year. No grade changing. Separate grades for each quarter registered.

Since the course work is contained offline, the persistence of data is not a major problem."

--Vtaylor 17:14, 8 July 2008 (UTC) ?? << need to see where this came from - don't think this is right

If I'm not thinking correctly, please clarify to help me understand the request.

There are a few options I can think of to address this issue. Linda and I spent some time thinking this morning, and I think I may have a potential solution. There are two "persistence" scenarios I that spring readily to mind (to be clarified below):

--Vtaylor 00:47, 9 July 2008 (UTC) we are talking about the CAOS / TSLR course on the production server, right? Just checking.

1. 4 persistent courses, one per quarter (like we do now, but they don't "go away" each quarter).

--Vtaylor 02:20, 9 July 2008 (UTC) A faculty who enrolls in Fall 2008 can access the course until the reset at the end of Summer 2009 - yes, that would be ok. Requires facilitation / monitoring of all four, but that can be set up with automatic notification when there are posts and submissions.

2. A meta course for the overall class, and 4 child courses - one per quarter (none go away).

--Vtaylor 04:09, 9 July 2008 (UTC) need to look into this. I think all the students and student submissions are visible in the meta course which is handy. But there may be some other things - I don't know much about special meta course considerations.

These solutions assume both the following caveats:

• Courses cannot persist across the summer maintenance window (occurs after the fall quarter is over).

--Vtaylor 00:47, 9 July 2008 (UTC) no problem as Sept through July should be enough time. If they can't get it done in that time, an administrative re-start is entirely appropriate.

• Students are officially enrolling in the course(s) one time.

--Vtaylor 00:47, 9 July 2008 (UTC) actually we would prefer to have faculty register every quarter that they plan to participate. This is new news. This is better for record keeping. It also requires faculty to make a commitment each quarter.

For persistence solution 1, the setup is relatively easy:

• A faculty requests each shell in the standard way.

--Vtaylor 00:47, 9 July 2008 (UTC) - that's faculty = instructor (me)

• DL personnel are notified that this course is persistent
• DL personnel place the course in correct category so it is not hidden at the end of the quarter.

For persistence solution 2, the setup is a little more involved. The following caveats also apply:

• Courses should be identified in advance where possible.
• Courses are setup using "topic" layouts, not "weekly" layouts.

--Vtaylor 04:17, 9 July 2008 (UTC) ok, no problems with this

Given the above...

• In the fall quarter, we can create a category for courses that are to be persistent.
• We create a metacourse for each course that needs to persist, with the start date as the first day of fall quarter, and the end date as the last date of the 6 week summer quarter.
• We create a child course for the fall quarter, and add that to the CAOS 198Y meta course.
• When winter rolls around (and spring, and summer), we create a new child course and enroll that course in the CAOS 198Y meta course as well (this allows the call numbers from fall, winter, spring and summer to all feed the same course).

In this scenario, student data from Fall will continue to persist in the fall child course, and that student can continue to access the metacourse. Please note that interactivity between students might get murky if a student from, say, spring comments on a fall discussion (as the fall students may not even be enrolled at De Anza anymore), so interactivity will need to be closely monitored.

--Vtaylor 04:17, 9 July 2008 (UTC) sounds good

Either of these scenarios will not require us to rewrite standard standard campus add/drop/incomplete procedures and can be implemented in a straightforward fashion using our current processes.

I hope this isn't too convoluted (I also hope I'm understanding things correctly). Again, if I'm not understanding the root problem, please clarify.

Regards, Kevin

--Vtaylor 04:17, 9 July 2008 (UTC) Great - thanks. If this works for you, this should address all the concerns we had.