Grading

[khufkens]

A section on grading is missing which needs to include:

• points allotted to each topic / section / component?
• the option to discuss or at least consult grading?
• how cheating will be handled?
• if and how there are retakes?
• your stance towards the use of LLM?

I suggest not to postpone this until after the course.

[stineb]

Thanks for the input. Here are the planned points to be added:

• Students hand in reports of the two Report Exercises in the form of a link, sent to Prof. B. Stocker, to a git repository that contains code for two separate, reproducible workflows (RMarkdown, see here) for the two Report Exercises (vignettes/re1.Rmd and vignettes/re2.Rmd).
• Each of the two reports will be equally weighted for the final grade.
• For grading, we consider the following criteria:
  • Reproducibility (25%). Make sure your RMarkdown code is reproducible and generates a html document as intended. You can check this by letting a colleague clone your git repository and run your code on their machine. If it fails, it's not reproducible, and you won't get points for this aspect.
  • Workspace organisation and code (25%). Follow the principles for workspace organisation and coding as described in the AGDS book (here and here).
  • Presentation (25%). This considers the appearance of the generated html document, its text and figures. Provide context, create good data visualisations, and discuss your findings.
  • Analysis and modelling (25%). This considers the correctness of analysis and modelling implementations, and the reasonable application of methods.
• Each student will hand in their own reports. This is not a group work.
• Code duplications are not permitted and affected code will be graded with zero points for the respective Report Exercise.
• Reports cannot be re-submitted after having received the grades. Make sure all is reproducible before you submit.

Anything else?

[stineb]

What would be a way to handle LLM? I don't think that they (ChatGPT) will be of much use for the specific problems addressed in the two Report Exercises (one on generalisability, one on a topic of their choice among digital soil mapping, phenology modelling, or land cover classification).

[khufkens]

LLM can cause problems with (involuntary) code duplication - false positives for failing the course.

I'm not against the use of these tools (or lifting code from the course or stack exchange for that matter - if it is well communicated that students understand the underlying choices - and demonstrate it as such). This is a fine line, but one which has to be communicated clearly (up front) if this is a disqualifying factor. In many ways, if not doing in person exams, it is hard to probe for this in the current (open) setup. This needs to be resolved before we find "As a large language model I ..." in a report.

[khufkens]

Just some context on why this matters, as this is one of my exercise questions - which need to be implemented but still.

[khufkens]

It will be hard to evaluate things purely on the content or even the code, the interpretation will be key (but even there I see openings for easily prompt engineering your way out of it).

[stineb]

Suggesting to add:

Note of caution

The use of large language models (LLMs), such as ChatGPT, for supporting code development should be considered with caution and is not permitted for writing report text. We are aware that LLMs can help solving technical tasks and the right use of LLMs for solving your problem is not discouraged. However, be aware that code produced by LLMs is not tested to be functional and error-free. Therefore, you have to understand what you get and verify and correct code with a view to your problem. Note that LLMs use text from various sources on the internet. Your report text must not contain copied text from unidentified sources. This would be considered plagiarism.

[khufkens]

This would be good, maybe adding "... not contain verbatim copied text ...". There will be copying involved no matter what, it is the intent and use case that matters.