Prevent withdraw after deadline

[John J. Camilleri]

It shouldn't be possible to withdraw a submission after the deadline has passed, even when it hasn't been corrected first.

I've had groups that did this because they wanted to re-submit, but then couldn't because the deadline had passed. It could also be abused.

[Evgeny Kotelnikov]

This should be well thought through. I guess we should allow withdrawals after the deadline if one of the previous resubmission was already reviewed. So, this is currently the logic: https://bitbucket.org/cse-fire/fire/src/6eb7ffa35b97f69401674cf379d671ee796effca/fire/models.py?at=develop#cl-908

[John J. Camilleri]

Maybe it's also important that it's the first submission. Consider this:

submit 1
<rejected>
submit 2
<deadline>
withdraw
submit 3
<accepted>

Here the withdrawal after the deadline should be accepted, since there was already an initial submission & review. Or do you think this could be problematic?

[John J. Camilleri]

Oh, after re-reading your comment I think we are saying the same thing. Therefore I am in agreement.

[Evgeny Kotelnikov]

Jonas suggested a scenario when one might want to allow students to withdraw after a deadline.

Scenario: Student submits crappy solution at 23.55. Student wakes up next morning filled with horror and regret. Student proceeds to write a proper submission. Desirable behavior: Student submits the new solution before I even notice the bad one is there. Observed behavior: Student waits for me to reject the bad solution then submits the new one.

Admittedly there are pros and cons to allowing resubmissions before rejection: Pros: Saves time and sanity for TAs. Cons: Students can give themselves deadline extensions by submitting placeholders. There may be some race conditions where resubmissions are accidentally overlooked.

IMO the pros outweigh the cons, and students can already give themselves deadline extensions by submitting placeholders - only now it creates extra work for me. Regarding the race condition, requiring the grading teacher to verify that the resubmission has been observed would solve it, possibly the request is omitted if the teacher has accessed the new files.

It's quite common in the database course that students discover errors before TAs do (because of how later assignments depend on earlier ones). It feels very wasteful that they can't at least notify the grader of the error (if not upload a fix) since the grader will have to provide feedback that the student does not even need.

I think it makes sense and I'm inclined to implement withdrawals after deadline as an option to a lab.

[Gregoire Detrez]

I'm a bit late to the party here, but are you talking about the first or the final deadline?

[Evgeny Kotelnikov]

The first deadline.

[Gregoire Detrez]

What about having two different operations: withdraw and resubmit where "resubmit" would atomically perform a withdraw and create a new submission but could have different permission (e.g. after the first deadline, a simple withdraw is not allowed anymore but students can still resubmit).

But then I'm wondering if withdrawing is useful in any other situation than before resubmitting? If not, we could even remove the withraw button in favor of the resubmit feature.

[John J. Camilleri]

As such I agree that after the deadline, withdraw should be replaced with resubmit.

But I'm not sure I like the idea of resubmissions. I can appreciate Jonas' scenario, but students will quickly realise that they can abuse the resubmission feature to effectively extend every deadline. Also, what if I spend 15 mins reviewing some code, and then when I go to leave my comments in Fire I see they've resubmitted another version?

So I stand by my original vote, which is simply to disallow withdrawal after the deadline.

[Gregoire Detrez]

But I'm not sure I like the idea of resubmissions. I can appreciate Jonas' scenario, but students will quickly realise that they can abuse the resubmission feature to effectively extend every deadline.

I tend to see the first deadline as more of a way to help students than a hard constraint. As such, I don't really care if they can bypass it by abusing the system. In my experience as long as you allow resubmission (even only after a negative review), you will anyway get those sorry-I-didnt-have-time-to-do-it submission with just a text file with an excuse in it.

Also, what if I spend 15 mins reviewing some code, and then when I go to leave my comments in Fire I see they've resubmitted another version?

I think this argument goes both way: what if you spend 15 minutes reviewing some code or writing a comment for something that the student has already fixed and they are just waiting for the rejection to send the new version? (which actually is basically Jonas' argument phrased differently.)

So in both cases you loose 15 minutes but if we allow spontaneous resubmission, it only happens if they fix the mistake wihle you are reviewing the submission whereas if we don't allow spontaneous resubmission you also loose your 15 minutes if the student already found their mistake before you started grading their submission. So it seems that the later case, not allowing spontaneous resubmissions, is strictly worst.

In addition, we could mitigate the problem even more by notifying the grader immediately: if a grader has a submission page open and the student resubmit to the lab, we can use some javastript magic to show a message like "new submission, click here to reload page" (I think github does that on issues and pull requests). Or maybe even use the cool new desktop notification API .

[John J. Camilleri]

In my experience as long as you allow resubmission (even only after a negative review), you will anyway get those sorry-I-didnt-have-time-to-do-it submission with just a text file with an excuse in it.

Well it's not exactly the same; if the grader needs to reject it first I think that's a bit of a deterrent for students.

I think this argument goes both ways

I agree and maybe the benefits will outweigh the cases of abuse. It's worth implementing, and providing an option in the admin for enabling/disabling this feature.