Guidelines and Procedures for the Use of Moodle

Purpose

The purpose of this document is to outline operating guidelines, roles and responsibilities and procedures as they relate to the management of Moodle, the college’s learning management system.  

Definitions

Academic shell:
A course space created within the LMS to support Web-enhanced, blended and fully online courses in connection with guided independent study, study groups, residencies and courses. These shells are created approximately four weeks prior to the start of the term.
Archive shell:
An LMS shell which is no longer available on the LMS production server. The archive shell is stored in a compressed file.
Center(s):
Refers to the college’s academic units: SUNY Empire Online, the seven regional centers, the Harry Van Arsdale Jr. Center for Labor Studies, School of Nursing and the School for Graduate Studies.
Community space:
LMS shell used by college administrators, faculty, staff, or students for the purpose of conducting college-related business or extracurricular activities. 
Designated center contact:
Refers to assigned staff reporting to the SUNY Empire Online director of curriculum and instructional design, director of learning management and design at the School for Graduate Studies, the School of Nursing and faculty instructional technologists at seven regional centers
ITS:
Information Technology Services
LMS:
Learning Management System. Moodle, effective with the start of the September 2013 term, is the college’s learning management system.    
MOLE:
Management of the Online Learning Environment
OAA:
Office of Academic Affairs and related units, including Office of the Registrar and the Division of Student Affairs
Orientation shell:
A type of academic shell used to deliver basic information about college practices and policies to new undergraduate and graduate students
SIS:
Student Information System, otherwise known as Ellucian Colleague

Access

  • Student access to the LMS is associated with the official course/study registration record within the college’s SIS.
  • Instructor access to the LMS is associated with the official record of the college employee noted as the instructor of record for a given course/study in the SIS.
  • Access to and administration of the college’s LMS is provided by the Information Technology Services.
  • Special conditions: Student or instructor access other than those described above will be determined in consultation with the Office of the Registrar and/or other appropriate representative from OAA.
  • Guest access to LMS for non-Empire State College employees is limited for the duration of the term in progress, when requested. Requests should be channeled through designated center contacts via the IT Service Desk.
  • Extensions of guest access should be made using the same process.
  • LMS guest access for non-Empire State College students requires the approval of the Office of the Registrar.

Course enrollment methods

  • All college centers are required to manage student enrollment using the SIS. 
  • All manual enrollments of students in a course shell in the LMS require approval from the Office of the Registrar and must be managed through MOLE.
  • Center staff seeking manual enrollments for testing purposes should make these requests through the IT Service Desk.
  • These manually enrolled accounts are intended for course development purposes only and will not be added to live course rosters.

Content

Center faculty and their staff are responsible for the review of all course content. Use of the college’s LMS is restricted to the delivery of course shells with content and learning activities related to supporting:

  • the  college’s modes of teaching and learning, i.e., blended learning, online courses, residencies and guided independent study
  • recurring training for faculty, staff and students
  • student orientation.

Given current licensing constraints, the LMS cannot house community space shells.

Shells for course development

  • Faculty and staff involved in the course development process may request shells via their center’s designated contact.

System upgrades and maintenance

  • The Moodle upgrade schedule consists of two major updates typically scheduled for early-to-mid July and late December. These upgrades can include, but are not limited to, Moodle core updates, security patches, bug fixes and new features.
  • It is the company’s practice to remain one release behind the current Moodle release cycle.   
  • Moodle also pushes smaller patch releases on an irregular basis several times per  year.

Notifications and outages

  • OIT will notify users of any planned outages of the LMS. This is done through a combination of system announcements and postings on the Moodle homepage, through MyESC for students and using Exchange for faculty, staff and instructors.
  • Frequency and duration of notices for planned outages will be guided by the estimated downtime of the system.

Implementation of new system features

  • Decisions related to new LMS features need to accommodate requirements of the current hosting environment, which provides enterprise class security, scalability and performance. New feature requests can be submitted to the user support services ticketing system at www.esc.edu/techinfo
  • New system enhancements may require contract discussions with Moodle and additional cost to the college.

Course archiving

  • ITS will retain course sections on the college’s LMS production server for a period of one academic year plus one term from the start of the term the course was offered. Instructors have access to these courses through the LMS homepage. 
  • At the end of the period described above, all courses on the production server, including associated user content, will be archived and compressed as zip files, backed up to an archive storage area, for a period of two years. Access to archived courses is handled through the course restoration process below. 
  • Prior to starting the archiving process, faculty and staff will be notified through their designated center contacts of the last day to access course content. Access to these course shells will be terminated during the period of the archiving process.
  • The archive process will run over the course of several days. Once the archives are complete and verified by the LMS administrator, all archived course shells will be deleted from the production server.
  • Courses will be retained on the archive server for a period of two years. At the end of two years, these archived courses will be deleted from the server.

Restoration of archived courses

  • Only those zipped course files available through the two-year archive can be restored. This includes all legacy (ANGEL) course archives. Any course archive older than two years will not be available for restore.
  • The LMS system administrator is responsible for restoring courses. Requests for access to archived courses must be made through the center’s designated contact via a support ticket and will be made available on a college website for a maximum of 30 days.
  • Restoration of archived courses apply to the following situations:
    • Student grade disputes: Local requests must be forwarded by the designated center and/or OAA contact.
    • Administrative purposes: Requests must be approved by authorized OAA management.
    • Research: These requests must be accompanied by written documentation from the college’s Institutional Review Board approving the research protocol.

Official course grades and rosters

  • The SIS is the sole repository of official course grades and rosters.
  • While roster and gradebook information in LMS is confidential, the LMS is not the official record of course grades and rosters.

Copyright compliance

  • Delivery and access to copyrighted materials in the LMS must adhere to copyright guidelines set forth in the college policies.
  • The system administrator will remove content that is in violation of college policies if requested by the instructor of record, or the college’s copyright officer.

Notes:

This document was circulated to the Moodle advisory group and the Moodle core team for comments during October-November 2013.

Questions should be directed to Suzanne Hayes, director of academic technologies