Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include submission times in grade book exports #1375

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

cycomachead
Copy link

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 is helpful when trying to calculate slip days.

I think this works, but dunno much about okpy. Written based on just reading the code. :)
@Sumukh Sumukh requested a review from kavigupta January 5, 2020 04:51
@kavigupta
Copy link
Contributor

this looks good to me but @rahularya50 how does this interact with your change for a faster export?

@cycomachead
Copy link
Author

Thanks -- also if it's useful to others, I could try to format this as a lateness calculation -- the result in HH:MM:SS.

@rahularya50
Copy link
Contributor

rahularya50 commented Jan 8, 2020

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.

@cycomachead
Copy link
Author

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.

@rahularya50
Copy link
Contributor

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?

@rahularya50
Copy link
Contributor

Also, I'm pushing a test implementation of this to the other PR now.

@cycomachead
Copy link
Author

cycomachead commented Jan 8, 2020 via email

@rahularya50
Copy link
Contributor

rahularya50 commented Jan 9, 2020

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?

@cycomachead
Copy link
Author

Wow, thanks! I suppose the other PR's behavior of earliest backup that's included sounds best to me.

@rahularya50
Copy link
Contributor

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.

@rahularya50
Copy link
Contributor

rahularya50 commented Jan 9, 2020

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.

@cycomachead
Copy link
Author

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
Copy link
Author

oh this is neat, lol; #1148

@matulka
Copy link

matulka commented Feb 19, 2020

@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: - . So it becomes kind of complicated to look through each submission. I think it would be reasonable to make a csv such that rows are different users and columns are different submission kinds (total, composition, etc.). For each user and each kind the csv would indicate the slip days used for the submission that gained that user the biggest score on that kind. Do you agree with this architecture? And what exact kinds should I add there? One possible solution would be to list just two kinds: Total score and Composition score. Another would be listing a submission for each of the following: Effort, Total, Regrade, Composition and Revision. What would be the most useful way for staff to calculate slip days?

@cycomachead
Copy link
Author

. 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.

@matulka matulka mentioned this pull request Mar 4, 2020
@matulka
Copy link

matulka commented Mar 4, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants