Regular readers may have sense that I was running out of steam when I wrote my reflection of Spring's CS222 class. It wasn't a bad class, but the frustrations around the lack of participation drained my will. It was good to step away from it for a few months. This week, I continued the course planning work that I started last week, and my goal was to determine what I should do with CS222. The results are posted in the public course plan (CC-BY, as usual).
My reflection on Spring's class ends with some ideas about completely overhauling the class. It did not take long for me to realize I would not have time for that, especially not while teaching three classes and leading two independent research groups in the Fall. I did make one major change to the grading policy: I changed the final grades to be determined by specifications rather than weighted average. The major difference is that completing some achievements is now necessary for a C or better grade whereas they used to be a way to separate high performance from standard performance. I took this trick from David Largent, who regularly teaches this course as well. Many of the "achievements" are in fact remedial for students who have bad study habits, and so I think it will be beneficial to be able to push students toward ways that they can use this system to improve those skills. For example, if someone does badly on an assignment from the reading, I can easily point them to the "Re-reader" achievement (also one of Largent's inventions).
The other major change that I am trying is using EMRF grading rather than triage grading of assignments. Triage grading is elegant although many students refuse to engage with it. (I blame the brainwashing of the rest of their educational experience, particularly the abuse of tools like Canvas and the administrative state's succumbing to the tyranny of metrics.) For years, students in CS222 have been free to resubmit any assignment from the class, whether they got a middling (2/3), low (1/3), or no (0/3) marks on it. However, unless my perceptions are wrong, I have seen a drop-off in the number of students taking advantage of this. To be clear, I don't know exactly why this is, and there are many competing as well as overlapping hypotheses. Suffice it to say, I don't have much to lose by trying something different.
I came across EMRF grading from Robert Talbert's blog. What strikes me about it is that it's not that different philosophically from triage grading. However, because numbers are removed and replaced with letters, students cannot turn to a quantiative understanding. Whereas a student might look at "2/3 points" and think of it as "66% That's failing!" rather than "This is halfway good and halfway poor," I don't think I will see the same thing with someone who gets an "M" despite its serving a similar purpose. It's not exactly the same purpose, and I wonder if I will miss triage grading's ability to call something "kind of right, kind of wrong," whereas the output of EMRF grading essentially Boolean: either you pass or you don't. The choice of "F" for "fragmentary" is the one place where I am sure students will think of it as "failure," and that's an unfortunate impact here: it continues to put a negative rather than a hopeful connotation on the necessary step of getting things wrong on the way to getting things right. I suppose I have time before Fall to replace my link to EMRF grading with the invention of a variation such as EMRX.
The EMRF system works well with the change to specifications-based final grade. I took another page from my colleague Dave when I characterized the requirements for A, B, C, etc. as having all the assignments passed, all save one, all save two, etc. I have not yet decided whether I will use EMRF grading, triage grading, or something else when it comes to the projects. Right now, the final course grade is based on the letter-grade achievement in the final project, and so I can punt on the decision on how exactly that will be graded; that will give me time to see how the first few weeks with these other changes works.
One other structural change to the course is worth mentioning. For years, I've used a structure where we have a three week ramp up to the two-week project, then a short break, then nine weeks in the final project, which is completed in three three-week iterations. When I switched to Dart and Flutter, I had to remove some interesting content from those three weeks so that the students could have time to learn more about the technical details of these. I missed some of the elements I pulled out, though, and I desired to add them back in. As another experiment, I annotated each assignment with an estimate of how long I expect it to take, and this exercise actually helped me see that I needed more time for this introductory portion of the course. There was just no way to get all the things in there that I thought were important to practice before getting into bigger projects. Hence, I added an extra week at the beginning of the semester and shrunk down the duration of the iterations of the final project. I think this will be a positive change: it will give students more time to practice some fundamentals such as TDD and Dart programming, and I think shorter iterations of the final project will reduce sandbagging.
Last semester, an administrator forwarded this blog post by Alanna Gillis to all faculty in my college. To summarize, she frames participation as a skill to be formatively developed rather than summatively graded, managing this with student participation self-reflections at the beginning, middle, and end of the semester. I think this is a great idea, and I tinkered with different ways of incorporating it into this class. In the end, though, I ran into a problem that always strikes me when I think about this course: there's already enough (or too much) going on here. There is a definite overlap between the course's four essential questions and Gillis' participation grades, but I fear that students may not have the wisdom and experience to see this. Similarly, many of the achievements could help students directly make progress in these forms of participation, but I already have students reflect on this regularly, such as at the end of each iteration of the final project and the final exam. I do want the students to think about how their participation in the class shapes their learning experience, and I already do that through these reflections. I fear that I would get less coherent reflection by adding more requirements and nomenclature. In the end, then, I decided to work some of Gillis' ideas into my discourse around participation and to use this to encourage students' engagement with achievements (which, again, is now more "required" than it was before), but not to go so far as to bring in new surveys and additional self-assessments.
I am eager to see how this semester goes. The course is back to Tuesday/Thursday, which I think is much better for the students, but I had to rearrange all my plans to deal with it. Also, it will be directly after my game programming class, so I am little worried about my own ability to maintain focus. It may be a two-coffee semester.
No comments:
Post a Comment