Proposal: Make courses shareable for other instructors to reuse

[timothyclemansinsea]

Inspired by an instructor using a course @williamstein taught with that instructor's students I propose we make it easy to share courses. I'm thinking a file type called .course-template. There would be a button for converting a course file to a course template. Conversion would strip out any confidential info like student list. Then one would just publish that like usual. When one opens a course-template file there would be a button one clicks to create a course from that template.

[novoselt]

I am skeptical of how often such a feature will be used, BUT a very common scenario is to reuse the same course you have taught before or someone else taught in your department. It is not just the course file that should be reused - assignments and handouts should be picked up as well, with everything relevant for the instructor, but without any collected files. Most likely they should NOT be published to prevent student access to future material as well as solutions.

The "template", I feel, should be a single archive file that one can download and send to somebody or copy directly to a different project.

Before any concrete implementation, perhaps it makes sense to set up a call with one of the big universities that run the same course for a long time and ask them what exactly they are doing at the moment to solve this problem and how would they want to see it work, what are the main friction points in their current process.

[williamstein]

Thanks for looking at this. It gets requested in support many times a year, so it will get used. What should happen is probably two forms of export that result in a zip archive:

1. A zip archive of everything, including all collecting student work and all student data. This is for the instructor to archive everything from the course. This is pretty easy, and instructors probably do this themselves regularly by just using our existing archive functionality. However, it would be nice to do this in such a way that when the zip is extracted, the files appear at the same level in /home/user, rather than all in a subfolder.
2. A zip archive that excludes all data about specific students, but includes everything else, i.e., the assignments and handouts. You can then safely share this with other instructors. Depending on the use case, this should either be private, but ultimately there could also be a public version in some cases. E.g., imagine making a course with 3 assignments, on "how to use CoCalc". That might be published to the share server. Similar to 1, this zip archive should be something that extracts directly to the home directory of a project; alternatively, if it is extracted to a subdirectory, then all links in the .course file to assignments and handouts need to be properly (or be relative to the course file).

I think both of these things are pretty simple to implement with little design or choices that need to be made. They only haven't happened already due to our lack of focus on this issue in the past.

[novoselt]

I would prioritize it since this will get used even by instructors who are not actively thinking about such functionality! Relative paths for all components definitely make a lot of sense.

Somewhat related - with TAs/graders/potentially licenses added on project level, not course, it feels that things could go smoother if we had a concept of the course project, not file, and that project could be duplicated. I imagine, however, that it would take way more development effort.

[williamstein]

Somewhat related - with TAs/graders/potentially licenses added on project level, not course, it feels that things could go smoother if we had a concept of the course project, not file,

Why? Maybe projects can just be made better in some way? What feature is missing?

E.g., in an operating system you don't have a special kind of login and account just to work on editing videos... you make the video editing software better.

and that project could be duplicated.

There should be a github issue about this if there isn't already. It's subtle mainly because of . config files (e.g., ssh keys) -- what exactly do you want duplicated? What surprise subtle thing is being copied?

[novoselt]

It is not that the feature is missing, but related things are "on different levels."

For a single user there is little difference between projects and the top level of a file system. As soon as collaborators are added into the picture, there is a big difference between projects and directories.

For a single instructor the same holds and it may be very natural to have multiple course files in the same project, especially if those course files are in different directories, and copying last term section to a new directory for this term seems very logical and should work fine. But as soon as TAs are in the picture there is again a big difference between projects and directories, so it is way better to have a single course in a dedicated project.

If instead of a course file we had a concept of course project, we could have all management, including adding TAs, in the same place.

But as a simple solution given our current code, perhaps there can be a tab next to "Students" for "TAs" that would just explain that TAs have to be added as collaborators, or perhaps even allowing adding them there directly? Still, this is a tab that logically is "per course", the same as with students, but in reality it will be "per project".

[williamstein]

Thanks -- That's a great start at an analysis of the problem, based on the needs of the constituents. Maybe we can have a sort of global configuration file (or database entry) associated to a project, which can configure some aspects of how the project works, and which can solve the problems you're describing here, once we figure out exactly what they are.

[novoselt]

That sounds like "installing a course file into a project", similar to installing an application which typically is present in a single version, is available throughout, and may modify user interface to some extent.

[novoselt]

I just had a personal encounter with this problem in 15867 and it took me a while to solve, especially since I didn't want to make things worse. The instructor copied a course file to teach it again and some of the students were actually taking it the second time. The reported problem was that they didn't get their assignments and only had old stuff. I've tried to suggest a logical solution with deleting students from a copy, then changing the title and adding them again, but projects of deleted students are still linked to the course, so they were renamed accordingly, it was necessary to purge them, then change the course title and add them again. There is no easy way for the users to figure it out.

A related problem that has surfaced multiple times with the start of the academic year - it is a very bad idea to have multiple course files in the same project due to privacy reasons. The TAs/instructors of each course will have access to all other class lists.

Plus we had a confusion between the file name of the course file and the course name/title in its configuration.

All of these problems would be addressed by a notion of "course project" which supports exactly one section. Cons: many users are used to the current interface, with extensive documentation, and there are some cases where it still makes sense to have many courses in a single project, like running a lot of small workshops by the same team.

[williamstein]

All of these problems would be addressed by a notion of "course project" which supports exactly one section.

This is definitely not going to happen. Our biggest users have tons of courses in the same project and we can and should support that fine.