A question comes up about the administrator and instructor naming the class for a new semester. the instructor wants the same problem sets that she had previously, some of which are unique to that section of the class. I had been creating a new class with a name that indicated the semester, e.g.,ECExxx_Fall2017_instructorname. I worried about possible problems with the classlist.
How about the idea of simply using ECExxx_instructorname for the class and using it every semester? This might help with classes whose instructors have made modifications to the webwork problems by making carry-over and interfacing with Moodle easier.
A problem I ran into was an instructor created some new problems and modified problems sets during his last semester teaching the class. He didn't export the files and when I created the new semester class using the previous semester's template, the modified problem set didn't show up. Fortunately, the problems were there but we had to manually add them. Any suggestions for this type of situation - for me or the instructor?
thanks
Hi Joel,
I think what makes best sense here may depend on you and your instructor(s). My first reaction is that it makes best sense to have WeBWorK courses correspond with university courses (though we work on a scale at which doing anything else is a recipe for disaster), and to have instructors export sets that they want to have available in subsequent semesters. By creating the new course copying templates from the old one the modified sets and problems will automatically be available in the new course.
The other option that we use (sort of) is to have a model course which gets updated to reflect the changes and problems for a given course, and to use that as the template course when creating new ones.
In any case, for what it's worth,
Gavin
I create a webwork course for every instructor-course combination like JDoe_101 at the begining of each semester if the course does not exist yet. This webwork course remains alive while the instructor is with us. This way instructors can keep their old sets and only update their class lists. I make the class lists available as an *.lst file in the templates directory, so instructors only need to import it. I also make course dependents problem set recommendations in form of *.def files using the <set definition files> button in the library browser.
I have run into similar challenges and I can provide some thoughts and some wish list items.
As the person here who creates new courses and copies old content into them, here's what I generally do:
- If the instructor wants old assignments copied, then I log in to the old course and export all of the homework sets. If there is more than one instructor/TA that will be carried forward to the new course, then I export a class list of the relevant users.
- From the admin course, I create the new course, copying content from the old course.
- I log in to the new course and import the homework sets, and if applicable, the class list.
There are two main issues I have with this workflow:
- This creates a copy of all of the pg files created in the old course, so we now have multiple copies of newly authored problems. Over time the management of these files becomes a more significant problem. More on my current approach to mitigating this below.
- It is extra steps to move over the homework sets. Plus, if this is done semester after semester you can accumulate a large number of .def files, and it becomes a challenge to keep track of what's what. I think a nice fix would be if the admin course had an option to copy the homework sets in addition to the files.
For the first issue, what I've been doing lately is creating links to shared directories within the course templates directory. There are situations when this is done by instructor or by course. e.g. I would create a symlink in /opt/webwork/courses/[course1]/templates to /opt/webwork/libraries/[profname], which would be readable and writable by the web server. This way the professor can save all of his files to that directory, and access them from any of his/her courses. One current issue is that there is a bug in the file manager that even with the correct permission settings it won't let you navigate to a subdirectory of a linked directory (though the Library Browser works fine).
One current issue is that there is a bug in the file manager that even with the correct permission settings it won't let you navigate to a subdirectory of a linked directory.
I don't think this is actually true, though you do have to configure your course (or WeBWorK as a whole) to allow access to the specific directory tree you are interested in. You must add the /opt/webwork/libraries/[profname] (or just /opt/webwork/libraries/ if you allow access to all library subdirectories) to the $webworkDirs{valid_symlinks} array. For example:
$webworkDirs{valid_symlinks} = [
"/opt/webwork/libraries/OpenProblemLibrary/OpenProblemLibrary",
"/opt/webwork/libraries/[profname]"
];
should do it. I've checked that this works for me, and I can navigate the FileManager to all the subdirectories of the ones listed there. Of course, if there are additional symlinks in the directory tree of the one you are adding, you will need to add those root directories to the valid_symlinks array as well. So I'm wondering if you added /opt/webwork/libraries/ but are making symbolic links to the [profname] subdirectories?
You can add this to a course's course.conf file if you want to do it on a course-by-course basis.
I figured out why it wasn't working for me. When I created the symlink, I used a relative link (to ../../../[profname] rather than to /opt/webwork/libraries/[profname]), which didn't match what I had in the valid_symlinks array. When I changed the link to an absolute path it works fine.
The weird thing is that the file manager would let me in to the highest level directory of the symlink even though it didn't match the valid_symlinks, but not any subdirectories.
thanks a bunch for the advice and hints. They are very helpful.