Open gabindu opened 3 years ago
But this prevents the teacher from inspecting the file history (possibly important in exam situations, to notice blatant copy & paste plagiarism?).
Fortunately, it doesn't prevent the teacher from inspecting the file history. They can do so by clicking the link that leads to the version of the file in the student's project, then clicking TimeTravel there. The student can't modify the history so there is no possible loss of information.
I therefore suggest that TimeTravel information be copied with the original file.
This would result in a large amount of redundant wasted storage getting used, and make collecting homework much slower. Also, it could be pretty tricky to do in general, since an assignment is an arbitrary directory tree, which could contain many different TimeTravel histories.
I think something better would be to make it clearer how an instructor can browse the time travel history of files in an assignment. Any suggestions for this?
Note that a long time ago TimeTravel info in CoCalc was stored in a hidden file (rather than in a central database), and copied around with files. This led to a lot of bad situations and frustration, where private TimeTravel info got exposed to students, which annoyed instructors. This is also worth keeping in mind.
I understand the complications, so I could indeed live with just (easily) accessing the info that's already there:
Fortunately, it doesn't prevent the teacher from inspecting the file history. They can do so by clicking the link that leads to the version of the file in the student's project, then clicking TimeTravel there.
I presume you mean the buttons in the .course file to "open..." the project folder vs the collected folder? That works indeed (and I've used this as a workaround), but is rather cumbersome to do (and not obvious for many users I would think, most people will assume that TimeTravel will show the full history of the file...). A possible solution could be a direct link from the collected file, maybe when one opens its TimeTravel: "show student's edit history" or something like that?
The only potential problem I see with all this is if the student were to delete the file since it was collected. Even though it would presumably still exist in the .snapshots, it seems to me that its TimeTravel information would be very hard to access then, no? (admittedly, this is unlikely to happen, but a possibility to think of)
Somewhat relatedly, I've found that many (student) files start with a very large edit as the first revision (revision 1 already showing an almost full document) - which initially made me quite worry about cheating, but since it happened for many files, it seems to be more related to the first revision only being stored with the first "save"?
Finally, as you can probably tell, all of these topics come up for me because of the need of administering 100% online exams, and most of my private eye investigations would be rendered unnecessary by the existence of a true "lockdown"/"proctoring" mode as described in #1919 ... (nudge-nudge, wink-wink... ;-) )
I presume you mean the buttons in the .course file to "open..." the project folder vs the collected folder?
Yes, exactly.
That works indeed (and I've used this as a workaround), but is rather cumbersome to do (and not obvious for many users I would think, most people will assume that TimeTravel will show the full history of the file...). A possible solution could be a direct link from the collected file, maybe when one opens its TimeTravel: "show student's edit history" or something like that?
That's a very good idea, and would likely work well. We could also do this in a way that doesn't require starting the other project (as TimeTravel is in the database).
The only potential problem I see with all this is if the student were to delete the file since it was collected. Even though it would presumably still exist in the .snapshots, it seems to me that its TimeTravel information would be very hard to access then, no? (admittedly, this is unlikely to happen, but a possibility to think of)
Fortunately, deleting a file has no impact on the previous history of that file and .snapshots is just a filesystem level copy of the file which also isn't related to TimeTravel. The TimeTravel information would still exist at the original location. You can undelete the file in the project log (say) or just create a blank file in the same location, then click "TimeTravel".
Somewhat relatedly, I've found that many (student) files start with a very large edit as the first revision (revision 1 already showing an almost full document) - which initially made me quite worry about cheating, but since it happened for many files, it seems to be more related to the first revision only being stored with the first "save"?
No. Revisions in TimeTravel are made every few seconds, when the file is actively being used. If you're seeing a large revision representing substantial work being completed, then either the students are cheating, or they are doing their work somewhere else (e.g., in their own separate project or in Jupyter classic or something like that), then copying the file over when they are done. They might be doing this since they want to work privately, so you can't see how they got to the solution. Or they are cheating (depending on your rules -- maybe they are working in a group and that is allowed, then copying to their own separate collection locations?).
That's a very good idea, and would likely work well. We could also do this in a way that doesn't require starting the other project (as TimeTravel is in the database).
great!
Fortunately, deleting a file has no impact on the previous history of that file and .snapshots is just a filesystem level copy of the file which also isn't related to TimeTravel. The TimeTravel information would still exist at the original location. You can undelete the file in the project log (say) or just create a blank file in the same location, then click "TimeTravel".
As long one wouldn't have to actually do the undelete to see the TimeTravel information (at least for the above-mentioned assignment situation), that's great news indeed.
No. Revisions in TimeTravel are made every few seconds, when the file is actively being used. If you're seeing a large revision representing substantial work being completed, then either the students are cheating, or they are doing their work somewhere else (e.g., in their own separate project or in Jupyter classic or something like that), then copying the file over when they are done. They might be doing this since they want to work privately, so you can't see how they got to the solution. Or they are cheating (depending on your rules -- maybe they are working in a group and that is allowed, then copying to their own separate collection locations?).
hm, now my worries are back in full (thanks, but no thanks! ;-) ). They were not allowed to work in groups on this, and they were not supposed to use previous practice/solution worksheets - but I'm quite certain that both have occurred. In the past, these exams would have happened in a computer lab, and I could catch them quite easily just by walking around, but that's obviously impossible now. Hence my wish for a full proctor mode. ;-)
Currently, when "collecting" an assignment from students, the copied files lose their previous TimeTravel information (as far as I can tell), showing only changes since the copy was done. But this prevents the teacher from inspecting the file history (possibly important in exam situations, to notice blatant copy & paste plagiarism?).
I therefore suggest that TimeTravel information be copied with the original file. Since there are situations where it might be good to have "clean" copies, I'd suggest to make this configurable (and activated by default for collected assignments).