ok
ok copied to clipboard
okpy
Include submission times in grade book exports
This is helpful when trying to calculate slip days.
I think this works, but dunno much about okpy. Written based on just reading the code. :)
this looks good to me but @rahularya50 how does this interact with your change for a faster export?
Thanks -- also if it's useful to others, I could try to format this as a lateness calculation -- the result in HH:MM:SS.
Sorry for the delay. Unfortunately, I don't think this PR interacts well with #1376, since my change makes it such that export_student_grades only gets access to all_scores, not the assignment status object from the ORM. I'll see if I can modify my PR to support this functionality.
No problem.
Hmmm, #1376 uses the DB more... could we use TIMESTAMPDIFF to get the difference right in that query and then here convert it to HH:MM:SS
https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_timestampdiff
I’m willing to help figure that out.
In some cases, the assigned score comes from multiple submissions. For instance, the total score may come from one backup, but the composition score from another. Currently, your implementation returns the submission time of the earliest backup. Should I keep this behavior?
I think the earliest backup time makes sense, or at least the earliest of the ones that’s graded
Thank you!
-- Michael Ball From my iPhone michaelball.co
On Jan 8, 2020, at 1:15 PM, Rahul Arya [email protected] wrote:
Also, I'm pushing a test implementation of this to the other PR now.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
I did some testing, and it seems that this PR finds the latest, submitted backup, whereas the other PR finds the earliest backup whose score for at least one category is part of the final computation.
Note that multiple backups can be submitted and scored, and backups can be scored even if they are not the one originally submitted.
Which of these behaviors is desirable?
Wow, thanks! I suppose the other PR's behavior of earliest backup that's included sounds best to me.
Actually, Kavi and I were discussing this, and your PR's behavior may make more sense. Otherwise in multi-part projects, a backup could be given a checkpoint score, and then it'd push the submission time earlier.
Whereas your PR looks at the latest submission / flagged backup, which might be more reasonable. I'm not sure though. The worry is that the behavior is probably course-dependent, so if we arbitrarily pick one way of computing the time, then it could hurt other courses.
What could be done is to leave Export Grades the way it is, but add a new job that exports just the submission times of various assignments computed in many different ways (e.g. earliest backup for each kind, as well as time of earliest / latest submission). That way every course can do what it wants, but we don't clutter up Export Grades with non grade-related behavior.
Otherwise in multi-part projects, a backup could be given a checkpoint score, and then it'd push the submission time earlier. The worry is that the behavior is probably course-dependent, so if we arbitrarily pick one way of computing the time, then it could hurt other courses.
I do think there's a reasonable default, which is that if you have multiple parts you count the main one -- slip days don't really make sense for a checkpoint, and if you have N equal weights, you'd probably do that as 2 separate assignments. I definitely think stuff like comp scores and revisions would be excluded. At least, as a default.
Right now isn't there only 1 submission time on the assignment grades export? That's what I think I was following....
What could be done is to leave Export Grades the way it is, but add a new job that exports just the submission times of various assignments computed in many different ways (e.g. earliest backup for each kind, as well as time of earliest / latest submission).
This actually seems pretty good to me, as long as it's still one sheet. 😄 Though, as I said, for slip days, the delta is much more useful than the absolute time.
@cycomachead Hello Michael,
I have looked through #1148 and it looks functional, but there is one problem. It calculates slip days for all of user's submissions in a csv with the following format:
. It calculates slip days for all of user's submissions in a csv with the following format
It's important for usability that all submissions are in a single table / row, since the point is to sum things up / review.
In general, I think slip days only really matter for the main submission, and if that's what you means by the biggest score, then I agree. Breaking down the score is potentially helpful, but not critical.
@cycomachead Take a look at #1384 , I took #1148 and updated it so it works the way we discussed and also took into account most of the comments under it.