I’m finding that student work is carrying forward from level to level and lesson to lesson as intended. However, changes students make in later levels also seem to be propagating backward to earlier levels, which makes it very difficult to grade their work accurately.
For example, when I go back to evaluate an earlier level, it may no longer work as it did when the student completed it because a method has since been modified for a later level. These are not project levels where I would expect students to be working continuously on the same code.
I’ve double-checked the course settings, and I don’t remember this behavior when I taught the course two years ago. Is there a setting I’m missing, or something else I should be doing to prevent later changes from affecting previously completed levels?
Students work carrying forward from level to level is a feature of some level progressions suck as U2L2 - Attributes. The lesson has the students make a prediction about what the code does and then the levels that follow have the students change the code and notice what happens when they run it. Once the code is changed in later levels, the code also changes in the earlier levels.
The lesson plans/ slides for the lesson plan has discussion prompts and outcomes for teachers to hold with their class. These levels are designed for the “We do” in the instructional practice of I do/ We do/ They do progression.
I understand your desire to look at the steps taken by students at each level. One work around may be to check the students version history for the code. The drawback to this is instead of being able to see the changes level by level, you will have to figure out the times the students did each level.
Thank you for bringing this to the forum and please follow up and let us know what you decide to do. I’m sure others in our community are being confronted with the same dilema you are.