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

Allow staff to remove early submission bonus when grading assessments #2226

Open
chownces opened this issue Sep 19, 2022 · 4 comments · May be fixed by source-academy/backend#1089
Open

Allow staff to remove early submission bonus when grading assessments #2226

chownces opened this issue Sep 19, 2022 · 4 comments · May be fixed by source-academy/backend#1089
Assignees

Comments

@chownces
Copy link
Contributor

There are occasional 'low effort' submissions from students to gain the early submission bonus XP. This is more prevalent amongst 'optional' assessments within the course (such as Quests in CS1101S). Staff should be able to remove the early submission bonus where deemed fit.

@martin-henz
Copy link
Member

Staff should be able to remove the early submission bonus where deemed fit.

Yes. In addition, we could automatically remove the bonus, if there are 0 marks for the assessment. That would mean: no need for staff to remember to remove the early submission bonus. To keep things simple, we would just leave the early submission bonus as soon as the marks are non-zero.

Staff would need to be aware of this: with non-zero marks, they enable the early submission bonus.

Any views @Sanka-R @boydanderson ?

@emptygx
Copy link
Contributor

emptygx commented Aug 7, 2023

Proposed Changes:

  • Allow staff to view any bonus XP awarded in the grading submissions table
  • Provided the ability to enable and disable this bonus XP where deemed fit
    • Can be achieved with a switch
  • Maintain the default of early submission bonus to be enabled i.e. no action required unless staff wishes to manually disable the bonus for any reason

Possible UI Design:

image

@RichDom2185
Copy link
Member

  • Allow staff to view any bonus XP awarded in the grading workspace

I agree with this, but your image shows the grading submissions table, not the grading workspace, so I'm not sure which one exactly you're referring to.

Whether or not to award the early submission bonus XP comes from the judgment of the staff after having gone through the submission itself (whether it's "low-effort", etc.). So in my view, it does not make sense that there is a toggle to award/not award the bonus XP in the submissions table, where the staff has not looked through the submissions yet.

It should be in the grading workspace, together with where a staff would award XP for all the submissions' answers.

  • Provided the ability to enable and disable this bonus XP where deemed fit

    • Can be achieved with a switch
  • Maintain the default of early submission bonus to be enabled i.e. no action required unless staff wishes to manually disable the bonus for any reason

Instead of a switch, why not as discussed the other time, something like the following (already exists in grading workspace at the moment):

image

My counter-proposal:

  • Something like a combination of the two above → (input field) / (max bonus XP), where the max bonus XP is set by the submission time (the existing behaviour), and the default value of the input field is also equal to the max bonus XP
  • That way, staff will have more granular control of the bonus XP awarded, instead of just 0 or max (e.g. maybe they want to award the bonus XP for attempting and submitting half of the questions early)

What do you think?

@emptygx
Copy link
Contributor

emptygx commented Aug 7, 2023

I agree with this, but your image shows the grading submissions table, not the grading workspace, so I'm not sure which one exactly you're referring to.

Oh yes, I was referring to the grading submissions table sorry, edited the original comment.

My counter-proposal:

  • Something like a combination of the two above → (input field) / (max bonus XP), where the max bonus XP is set by the submission time (the existing behaviour), and the default value of the input field is also equal to the max bonus XP
  • That way, staff will have more granular control of the bonus XP awarded, instead of just 0 or max (e.g. maybe they want to award the bonus XP for attempting and submitting half of the questions early)

What do you think?

Thanks for the suggestions, I do think there is merit in this solution as well. However, my concern is that granular control could result in more confusion for the graders and inconsistencies in grading, like how would one decide how much bonus XP a student should get exactly based on differing amounts of effort? It may also add one more level of grading work to the job of a grader in deciding this amount. Perhaps it should be simpler in that there either is a bonus or there isn't, might be easier for the students to understand their grades too.

Whether or not to award the early submission bonus XP comes from the judgment of the staff after having gone through the submission itself (whether it's "low-effort", etc.). So in my view, it does not make sense that there is a toggle to award/not award the bonus XP in the submissions table, where the staff has not looked through the submissions yet.

It should be in the grading workspace, together with where a staff would award XP for all the submissions' answers.

I do think it is a possibility to have it in the workspace, but the early submission is not a per-question basis bonus so would it be on the last question after all questions have been looked at? I feel that having it in the submissions table makes more sense to me as it is a per-submission basis bonus and can be toggled on/off for the whole submission there easily.

My proposal to ensure staff has looked through the submissions already would then be:

  • grey out/disable/not show the switch until the submission has been fully graded.

Would this be feasible?

@thortol thortol assigned thortol and unassigned thortol Feb 24, 2024
@InfinityTwo InfinityTwo linked a pull request Mar 17, 2024 that will close this issue
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging a pull request may close this issue.

5 participants