It’s a simple question with a complex answer: in a given academic term, what percentage of our Moodle courses are “active” (used by a faculty member in the teaching of their course). We have to start by figuring out what counts as a “course” in a term, and then come up with an inclusive measurement of activity.
Courses
The basic unit in Moodle is the course. We use the Banner/Luminis Message Broker plugin to create a course for each section of each course which is taught for a given term at Lafayette. Each of these courses has an idnumber which corresponds to the section’s CRN. An exception is crosslisted courses; the LMB plugin creates a merged course with a special idnumber.
We also create “merged” courses during a term, using the Course merge helper plugin. The destination course is an empty shell with metalinks to the source courses. The source courses are preserved with their idnumbers, but most activity is assumed to take place in the destination course.
This results in close to 900 courses per term, not all of which should be counted against the total. We discovered that we create a course for each registered “Thesis” or “Independent study.” We have over 60 courses which correspond to a student research program (coded as “EXCL”). These aren’t “courses” per se and should be excluded.
Terms
Courses in Moodle are organized by category. At the top level are term-based categories such as “Fall 2015” and “Summer II 2016”, which correspond to academic terms at Lafayette. Each of these categories has department/program subcategories such as “History” and “Mechanical Engineering.” Courses are categorized within one of these subcategories, not the top-level category. When speaking of which term a course belongs to, we compute it based on courses which belong to a category whose parent is the corresponding top-level category.
Activity
Now that we’ve defined scope, we can measure activity. We want to know which courses, as Lafayette defines them, are active. This means that we need to exclude destination courses themselves from the report, but determine activity in the source courses based on the corresponding destination course.
Activity itself is determined based on whether a user, other than the system user, updated the course or created something within it. This is determined by examining the internal logstore for “create” or “update” events.
A course is therefore considered to have been active if it meets the following criteria:
- It is neither the target nor the source of an active course meta link enrollment and a user other than the system user took an action which left a “create” or “update” entry in the log.
- It is the source of an active course meta link enrollment and a user other than the system user took an action which left a “create” or “update” entry in the log of the destination course.
Examples
Consider the example courses below:
- ENG 100.01 is a course with no active course meta link. A teacher added a course module to the course.
- ENG 101.01, ENG 101.02, and ENG 101.03 are source courses for the ENG 101 destination course. A teacher edited the ENG 101 destination course so that it was available to students.
Of the above, the following courses are active:
- ENG 100.01, because it has a “create” log event from the teacher.
- ENG 101.01, ENG 101.02, and ENG 101.03, because are the source of a course meta link.
The following course is not active:
- ENG 101, because it is the destination of a course meta link.
Observer effect
One issue with relying on log data is that actions by managers can potentially pollute the results. If a manager modifies a course, for any reason, that turns the course active. Presumably in most cases the course would be active anyway, but it’s a consideration.
We’ve built a number of tools for mass-managing courses, including Set course dates and Hide courses. For both we’ve used ad-hoc tasks to handle the actual actions. Beyond being good engineering, this means that all the actions are logged as the system cli user, and are therefore easy to exclude from the activity reports.
Running reports
We were able to develop each of the needed reports as a single SQL query, which can be run from the interface using Tim Hunt’s Ad-hoc database queries plugin. Below are GitHub gists with each of the reports.