Life of a Course

From openmichigan

Jump to: navigation, search


Life of an OER Course

An open course goes through four basic stages.

  1. Recruitment
  2. Clearing
  3. Publishing and Editing
  4. Maintenance and Publicity

Each of the phases is described below, and the entire process is graphically modeled as Appendix A. This report intends to document the process and extract areas in which OERca or other tools can more sufficiently facilitate the process from beginning to end.

Contents

[edit] Recruitment

The recruitment phase begins with the recruitment of a course itself as being potentially publishable. This can happen in a few different ways. Some faculty express interest based on word of mouth or as a result of acquaintance with others working on OER projects. Emails are sent out to departments eliciting participation. Medical School course have been mandated to be published openly, albeit with faculty approval. And some students interested in OER will offer to clear and help publish their course. Once a course is identified, a dScribe must be recruited, faculty permission must be obtained via the “OER Materials Permission Form,” and a license under which the materials will be published must also be chosen via the same form. Faculty are also prompted about how they would like to interact with their dScribes over the course of the semester or summer, how they will hand off materials to the dScribe team, when it's best for them to review the material, etc. This information is captured in the "Faculty Participation Specifications." This is mostly groundwork done by dScribe2’s. Once faculty permission is obtained, a license is chosen, some of communication and participation specifications have been established, and a dScribe recruited, the rest of the phases can continue uninterrupted.

[edit] Clearing

The clearing stage can begin before the permission form is signed, however it cannot progress adequately. As original content is obtained by the dScribe, he or she uploads it into OERca, recommends actions, finds replacements, then re-edits or recomposes the materials to present for publishing to the Publication Director. Often, several iterations will be moved back and forth between the dScribe and the Publication Director before a material is ready to be added to Educommons for the final publishing work. This is an area in which a new approach and perhaps a new tool may be beneficial to the process. the Publication Director and dScribes must email materials back and forth with changes or suggestions. A system for shared file editing and annotation would improve the efficiency of this portion of the process. In order to clear some materials, replacement objects must be located. Another potential breakdown is the lack of experience many dScribes have in searching for the type of materials, particularly images, that are needed to clear the material.

[edit] Publishing and Editing

In order to publish a course, a placeholder is first added to the Educommons site. The materials are downloaded from OERca as zip files, opened and examined. If changes need to be made, they are sent back to the dScribe in an email, and the publishing page is put on hold until the final version of the file is ready. There is an issue of version control that arises as a result of the back and forth movement of documents and instructions between the dScribe and whoever is publishing the course. dScribes sometimes have problems keeping the various "edited" versions separate from the original version in OERca and the version they use as part of their own files for the class. It is possible that the problem gets even more complicated when multiple dScribes are working on the same course. Text documents are copied and pasted into the Educommons HTML editor and marked up there. The publishing phase ends when an email is sent to the instructor asking for final permission. The instructor is given a login id and allowed to view and approve their course.

[edit] Publicity and Maintenance

Once a course has been published, data about its usage is tracked by Google Analytics. Courses are publicized as blog posts, and at the end of semester, emails are sent out indicating which new courses have been published. A course on the EduCommons site ideally could be maintained by the dScribe or the instructor as well as Susan. One issue this would bring up is version control between the various editors.

There are currently three channels for obtaining direct user feedback. There is a survey which is linked from every course. At present there has been only one respondent. There is a feedback field which can be accessed from the top navigation bar anywhere in the site. And there is a contact link at the very bottom of the page in which users could offer ideas. Thus far these channels have not produced a satisfactory or useful level of feedback.

This process is represented visually here. (pdf)

Personal tools