Skip to content

Worksheet Review

Jump to bottom
gabeclasson edited this page Mar 21, 2023 · 2 revisions

This document details how to review a worksheet draft for CSM 61A.

Finding the PR in GitHub

First, please go to the PR for the worksheet you are reviewing. In the "conversation" tab, the content team has left PDF documents of the worksheet for you to review. If there are multiple sets of PDFs, please go to the most recent (farthest down) set.

Reviewing the worksheet

First, please read the following points that we will ask you to comment on during the review process.

  1. Approximately how long did each problem take you? (The relative length is what we care about here, I don't care how fast you actually are.)
  2. Minor errors: Are there any formatting issues or typos? Is there sufficient space for solutions and scratch work? Are answer blanks long enough? Does anything look weird?
  3. Problematic problems: Were there any problem statements/explanations that could use clarification or simplification? Any wrong doctests, skeletons, or solutions? Was anything even a bit confusing?
  4. Worksheet design: Did the problems work well together? Is the number of problems acceptable? Was there a variety of difficulty levels available? Were the problems listed in order of difficulty?
  5. What were the best and worst problems on the worksheet? (Why?)
  6. (Highly optional) What might be a good problem to include on this sheet?
  7. Anything else?

Then, complete the worksheet from start to finish in a focused setting. Look through the attached solutions and meta as well. Finally, write your review of the worksheet, solutions, and guide according to the template.

**Note: none of these review points are mandatory. They are simply recommended. Please feel free to ignore the template if there are any irrelevant points or if there is something you feel is more important. **

Approving

When you're done reviewing the worksheet, go to the PR for the worksheet. In the "Files Changed" tab, select "Review Changes" and put your review into the text box. Select "Approve" (not "Comment") and then click "Submit Review." You are now done.

image

Markdown template

Here's a copy-pastable markdown template for your review:

## Approximately how long did each problem take you? (The relative length is what we care about here, I don't care how fast you actually are.)

## Minor errors: Are there any formatting issues or typos? Is there sufficient space for solutions and scratch work? Are answer blanks long enough? Does anything look weird? 

## Problematic problems: Were there any problem statements/explanations that could use clarification or simplification? Any wrong doctests, skeletons, or solutions? Was anything even a bit confusing? 

## Worksheet design: Did the problems work well together? Is the number of problems acceptable? Was there a variety of difficulty levels available? Were the problems listed in order of difficulty? 

## What were the best and worst problems on the worksheet? (Why?)

## (Highly optional) What might be a good problem to include on this sheet? 

## Anything else?

What makes a good worksheet problem?

  • Targets misconceptions
    • Example: environment diagram with parent frame of lambda
    • Put blanks in place where students may mess up
  • Combines topics and targets similar patterns
    • Note: even though problems may be similar, each should have a unique twist or gimmick that appreciably distinguishes it from the other
  • Good balance of withholding and disseminating clues to solve the problem
    • Skeleton code design is a key aspect
    • Problem description should give clear instructions
      • Confusing language, unnecessarily wordy descriptions, etc. can further convolute the problem and distract from crucial hints
  • Good balance of difficulty and continuity
    • Multi-part problems can help streamline thoughts in an organized way
      • Balance difficulty between parts
        • Example: part B is significantly harder than parts A and C, but most students can solve parts A and C without too much trouble
      • Maintain a continuity between parts
        • Example: part A and part B are independent, but part C allows students to use both parts A and B
    • Factors that affect problem difficulty
      • Conceptual complexity: combining concepts within a problem
        • Example: a recursive generator problem is conceptually more complex than most plain recursion problems
        • Note: be wary of combining too many concepts, or concepts that are not closely related
      • Explanatory complexity: challenges with introducing the problem and/or describing technical language
        • Example: a problem that requires a lengthy description and introduces lots of technical vocabulary is generally harder than one that has a short, crisp description and utilizes no new technical definitions
      • Code complexity: challenges with implementing the problem
        • A longer skeleton, or a skeleton with less blanks, provides less structure for the student to gather information from
        • Note: be mindful to consider leaving out crucial information from the skeleton versus more trivial information
          • Example: you may as well put "return ____________" instead of a blank line for a base case, since the student doesn't gain much information from having the word "return" as a given

Major Contributors: Gabe Classon

Clone this wiki locally