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.

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.

Canvas

Respond to students in Canvas, if you can help, especially if you graded the work under discussion.

Grading

Homework is submitted & graded via Canvas.
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.
Don’t apply a curve—if the average for an assignment or test turns out to be 40%, 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 something 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.
Grade from the top down. That is, for a five-point assignment, the student initially has 5.0 points. If the first test, worth 0.25 points, fails, then the student has 4.75 points. Another test fails, down to 4.5 points, etc. The possible penalties usually add up to more than the total points.
Explain grading decisions to the students, if they inquire. If they disagree, refer them to the instructor.

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 as “verticle”. 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, 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.
Don’t trust student code—isolate it. For each submission:
- create a temporary directory
- copy the student code there & build/compile it
- copy in any required data files
- run the program with a time limit, e.g.:
  # Run ./HW5 with a five-second time limit:
  timeout -v -s kill 5s ./HW1
- extract the results from the temporary directory
- remove the temporary directory.

Grading feedback

You must provide useful feedback to the students. It is not good enough to merely give them a score. They must know what test cases they failed, and why. They need useful feedback.
It is not acceptable to merely say “run my grading script; the output will explain everything”. You must break down each case in the feedback.
It is ok to provide data files used in testing in a subdirectory of ~/pub, e.g., ~/pub/HW3-files.
The trailing signature tells the student who to contact for questions. This is especially useful if we have more than one TA for the class.
Explanations are only required for homework, not quizzes or tests.
Don’t create grades unless something was turned in.
- If a student doesn’t take a given quiz, his zero score shouldn’t be curved up to a non-zero score.
- I need to be able to distinguish between a score of zero that was earned and a default score of zero because nothing was submitted.
- 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.

Cleanliness

When grading homework, don’t litter the class home directory. Create your own directory (~/Grading or ~/your-name is fine) and use that.
Don’t change config files such as ~/.bashrc or ~/.vimrc without consulting me.

Cheating

If you suspect cheating, 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.

Jack Applin