One of the finest universities north of Prospect in Fort Collins

Jack Applin

PmWiki

Responsibilities of a TA

Terminology

  • TA: a Teaching Assistant, whether an undergraduate student (UTA) or a graduate student (GTA).
  • Instructor: the person giving the lectures.
  • Test: a quiz, midterm, final exam, etc.

Lectures

  • You are expected to understand the class content, well enough to help students with it.
  • Whether you knew it before this semester, or whether you learn it with the students, is all the same to me.
  • If you already know the material perfectly, then feel free to skip lectures.
  • Otherwise, attend lectures. Don’t make me teach the subject to the students and to you separately.
  • Confessing a lack of knowledge to me will not harm your standing in the Computer Science Department. I have nothing to do with your degree program. Be honest.

Tests

  • Proctor tests with the instructor. Notify the instructor if you see something suspicious—do not confront the student.
  • Answer questions from the students during tests. If the question requires a judgment call, signal the instructor.
  • Stay away from the instructor when proctoring, to maximize coverage.
  • Collect tests and grade them.
  • Quizzes are returned to the students, graded, at the beginning of a subsequent class. Final exams are not returned.

Recitation

  • The TA runs the recitation.
  • Become familiar with the lab equipment before the first recitation. Otherwise, the students’ first impression of you is of incompetence.
  • Take attendance; each recitation is worth a point.
  • Grant the point if the student participates. They needn’t do well, or even learn the concept, but they must try. If they only surf the web, then they receive no points.
  • It’s acceptable to make up a missed recitation later in the week, if there’s room in the lab. If not, well, it’s only a point.
  • Create ~/Checkin/RECITnn/name.grade files, as described below.
  • Recitations are numbered by the CSU week. If there is no recitation the first week, then the first recitation grades go into ~/Checkin/RECIT02/*.grade.

Email

Students will ask you questions about homework via email. If you make a decision (for example, telling a student that error-checking is not required on a particular assignment), then cc: the instructor, so that we both tell the students the same thing. Feel free to use cc:—email is cheap.

Grading

  • Homework is submitted via the checkin program.
  • Scores, homework comments, and grades are via the grade program.
  • Grade homework and tests within five days of due date. For example, a Wednesday quiz should be returned to the students on the next Monday. Similarly, homework due on Wednesday should be graded by Monday.
  • Grade the final exam with the instructor.
  • When grading homework, don’t litter the class home directory with files. Create your own directory (~/Grading is fine) and use that.
  • Read the assignment, particularly the requirements section. It is your responsibility to identify gradeable requirements. For example, an error message may have mandatory text, or input may be case-independent.
  • Any directories in ~/Checkin are visible to students via the grade program. For example, ~/Checkin/HW3.temp/smith.grade will be visible to student smith.
  • Don’t apply a curve—if the average for an assignment or test turns out to be 10%, or 90%, so be it.
  • Partial credit and fractional scores (e.g., 3.6) are up to you.
  • No matter how bad an assignment is, don’t give a negative score.
  • Avoid a zero score, except in extreme cases (the student turned in poetry instead of a program). Even if penalties should take their score to zero, give them a point for trying and getting it to compile.
  • Grade the assignment on a scale that corresponds to its value in the class. For example, if an assignment is worth 5% of the overall points, then grade it on a scale 0–5. This makes it much easier for students to compute their grade.
  • If a student turns in the executable instead of the source file, give them no points and put in a note to contact me. I generally let them turn in the source file with an additional penalty if they can show me an untouched source file.
  • Explain grading decisions to the students, if they inquire. If they disagree, refer them to the instructor.
  • Create Checkin/what/who.grade files for tests, as described below.
  • If you change a *.grade file (for example, if a student points out that you made a mistake) then inform me, so I can change the curved version.

Automated Grading

  • Grading is hard—don’t just write a script and let it make all the decisions.
  • For example, if the assignment specifies that the output contain the word “vertical”, some students will misspell it. This will cause all of their output to be different than yours, and so they will lose most, if not all, points. It is not acceptable to lose all points for a simple misspelling. Check the output to see why students lost all points, assign a small penalty for this, and regrade.
  • Similarly, students will issue an incorrect prompt. Manually correct this, assign a penalty, and move on.
  • Implement multiple test cases as separate programs. Writing a single giant test program will not work if the student code aborts in the first test case. Similarly, the student might not have implemented all of the required methods in a class—separate programs will ensure that he doesn’t lose all points because a single test case failed to compile.
  • As a spot-check, after automated grading, inspect a few of the submissions that scored 100%, and all of poor saps that got 0%. Make sure that it’s not a problem with your process.
  • I don’t mind extra trailing spaces in the output of student programs, or if they use tabs instead of spaces, as long as the output lines up properly. Filter the student output through col -px to expand tabs and eliminate trailing spaces.
  • Interactive programs are best graded with ~applin/bin/runner, which stops runaway programs (too much CPU time, too much output, repeated reading at EOF, etc.) Use runner -h for an option listing.
  • Use the program ~applin/bin/globals, if global variables are forbidden.

*.grade files

The first line of each *.grade is points/max-points, and nothing else, because scripts process these files. Subsequent lines provide rationale for losing points on homework.

    4.25/5

    Points lost:

    -0.25      incorrect story.sarah
    -0.25      incorrect runme
    -0.25      incorrect permission for runme

    Graded by TA’s Name Here <email-address@ColoState.Edu>

The signature at the bottom tells the student who to contact for questions. This is especially useful if we have more than one TA for the class.

Don’t provide a *.grade file if the student didn’t turn anything in. I need to be able to distinguish between a score of zero that was earned (a *.grade file that contains 0/max-points) and a default score of zero because nothing was submitted (no *.grade file).

I curve quizzes & tests. If a student doesn’t take a given quiz, his zero score shouldn’t be curved up to a non-zero score.

Also, if a student receiving financial aid fails the class, the financial aid people ask me the date of the student’s last participation, so I need to know which tests the student showed up for.

Returning tests

It takes forever to return tests to students one at a time. We put the tests in a packet that only reveals the top half of the test, and pass the whole packet throughout the room, letting the students find their own test.

  • Sort the tests by last name.
  • Put the score at the bottom of the page for confidentiality.

Cheating

  • If you suspect cheating, on homework or a test, notify the instructor. Do not discuss it with the student.

Lab Op

  • You’re required to be a lab operator in the Linux Lab, which also serves as office hours.
  • When scheduling that time, keep in mind when homework is due. It’s useless to have office hours just after the work is due.