Guidelines for the Teaching Team

Code of Conduct and Principles of Community
Administrative guidelines
Course Code of Conduct
Teaching team’s behavior guidelines
Teaching Interaction Guidelines and Reminders
Course-specific Components, Setup and Considerations

Code of Conduct and Principles of Community

The University of California, Santa Barbara has a general Code of Conduct and Principles of Community for all students, staff, and faculty, which is linked on the Code of Conduct page for the Computer Science Department: https://cs.ucsb.edu/index.php/diversity-equity-inclusion/code-conduct

Administrative guidelines

Remember that in all your interactions, you represent the Instructor and the Computer Science department.

Be prepared. Show up to all meetings / labs / lectures early or at least on time, ready and prepared to participate.
Be respectful. Maintain professionalism and respectful behavior at all times with the students as well as with your colleagues on this team.
- For example: Never discuss students or your colleagues, their work or behaviors, with other students or people outside of the course.
Read all information that is sent to you by the instructor and promptly respond to them: guidelines and task assignments contain valuable instructions to help you succeed in your job. Please read and follow them carefully.
- If something is unclear, reach out right away to the whole team to ask for clarification: if you have a question, someone else might have it as well; if you have an answer or a helpful tip, it might help the whole team if you share it.
Always communicate with the instructor first. Let the instructor know directly (and right away) via a private/direct message or via an email if you have any feedback or concerns.
- IMPORTANT: If emailing, make sure to add the course name “CSW8” in the subject of the email for consistent filtering.
Be considerate. Always give the instructor and the other mentors an advance notice if there is any change in the usual plans.
- While we do understand that things come up, let’s make sure that we all have enough time to adjust if necessary.
- If there’s even a small possibility of a potential absence or an inability to finish the assigned tasks, please give the team a heads-up right away, so that we are not blindsided by it.
- Repeated inability to finish the assigned tasks by the agreed deadline can result in an administrative action.
Be mindful. Always be polite and respectful, and always use the official channels to communicate with the instructor/students (e.g., do not use your personal email address or Discord to reach out to students - use the forum or the UCSB address). Do not say/write anything that you wouldn’t want to be posted on the front cover of a news site.

Course Code of Conduct

In addition, I expect everyone involved in this course (the professor, students, and mentors) to follow these guidelines:

Treat all members of the academic community (students, staff, and faculty) with respect regardless of their experiences and background, including (but not limited to) their cultural backgrounds, socioeconomic status, disabilities, age, religion, sexual orientation, neuro(a)typicality, and gender identity.
Be professional in all your interactions. Interpersonal conflict should not be made public and should be addressed in a respectful manner outside of public spaces.
Derogatory, demeaning language, physical or mental harm, sexual harassment, aggression, explicit or overt, is not acceptable in any form.
Respect the personal property of others and University resources or property.
The exchange and challenge of ideas should always be done in a thoughtful, respectful, ethical, and constructive manner.

Teaching team’s behavior guidelines

Make sure that you’ve read the Syllabus and the FAQ, so that you can direct students there when appropriate.
- Note the instructions regarding communication and ways to get help, extensions, dropped scores
Look through the roster on Gauchospace and notice students’ pronouns, especially for students who go by they or ask to be referred to by their name.
Dating a student or any display of romantic interest should not occur while the student is taking this course and is under your supervision.
Report any potential conflict of interest directly to the instructor right away (this includes having your friends/relatives in the class).
Be patient with students. Always. Be respectful. Maintain professionalism and respectful behavior at all times with the students
- If you are noticing that you are not able to be helpful or respectful:
  - ask another mentor to help instead. (“Seems like I’m not able to effectively help you in this situation. Let me see if I can get another mentor to take a look at this case.”)
  - ask the student to post on the forum
  - tell them to talk to the instructor. (“It would be best if you let the instructor take a look at this / know about this situation / address your concern / see what can be done…“)
It’s very important that we, as this course’s mentors, speak in one voice when interfacing with students. If they have critical feedback about the course, they should come to the instructor, not to the mentors or the other students in the class, since the instructor is the one who can/might/need to make an immediate change.
- Mentors should refrain from confirming or agreeing with a student’s criticism even if they agree with it: affirm that you hear their concern/frustration, explain the reasoning (if you are aware of one) behind the condition that is causing their reaction, and recommend that they reach out to the instructor directly or offer to relay your feedback (and make sure to follow-up with the instructor if the student agrees to the latter).
If you observe any unfair, preferential, or inappropriate treatment or behavior, let the instructor know right away or submit the anonymous feedback via a form linked in the Syllabus.
Always be ethical in your behaviors: for example, directly providing answers or other information to students, doing their work for them, altering their assignments, lying or knowingly misleading students is not acceptable and can have severe administrative consequences.

Teaching Interaction Guidelines and Reminders

This section is based on the Teaching Interaction Guidelines and Reminders that are usually shared with the ULAs.

Gauging how a student is feeling may be important; you may need to adjust your demeanor/tone with the student accordingly to make them more comfortable or to diffuse stress. Empathy can go a long way.
It’s important not to trivialize students’ problems.
Ask clarifying questions at the beginning, before trying to tackle a problem head-on.
- Let students describe what their code is doing / what the problem is; don’t try to just look at the code first and figure it out on your own.
- Ask students what they are trying to do (not just what’s the lab/hw question they are on but what semantic step they are working on: e.g., checking if an item already exists in the list before adding it)
- Ask students to explain what they’ve already tried.
- If a student is running into an error, show them how to interpret the error and reason about the potential causes of the error; ask them what part of their code might be causing an error and ask how/what they can change and why. Perhaps, pull up the documentation if appropriate or ask them if they have seen this error before, what caused it, and how they solved it (has it been mentioned in the book?); if appropriate, search Stackoverflow for common errors.
- Tell them to print something specific in their code to help them with debugging and confirm their assumptions.
Do not be held hostage (e.g., where you spend more than 10 minutes with the same student), especially if there are other students waiting for your help.
- Look for a stopping point at which you can leave the student to work on the task independently (“It seems that you have enough information to continue working, so I’m going to check on the other students and come back to check on you later.”)
Lead the student towards the issue rather than telling them where the issue is in their code.
Encourage students to experiment with their code themselves rather than giving them direct answers.
Refrain from telling students whether their code is right, and instead have them walk through an example or run their code themselves after making modifications.
Refer to the lab/homework write up and syllabus where appropriate.
- Remind students that if they are lost and are not sure what to ask, go ahead and ask “Can you please show another example of X?”

If there are other helpful guidelines or tips that we can add here, don’t hesitate to use the “Edit this page on Github” button at the bottom to submit a Pull Request with your suggestion(s).

Course-specific Components, Setup and Considerations

Zoom

Please change your name on Zoom to include the word _MENTOR before your name and add your pronouns: https://support.zoom.us/hc/en-us/articles/4402698027533

Remember that anything that you say online can be recorded, so be mindful of what you share.

When working with students, if you ask them to share their screen, ensure that no other student can see the shared solution.

You can take a look at their work directly inside of zyBooks.
Alternatively, the student can share their screen when they are in their own breakout room with you.

Forum

When answering questions on the forum, point students to the appropriate concepts, slides, lecture notes, or book chapters, since sometimes they ask questions that are almost directly from the assignments.

If something is difficult to find, let the instructor know, so that we can add it to the quick links, highlight it during the review, etc.

Direct them to the post with the initial “Posting guidelines” post if they are missing relevant information in their post.

Also, when answering questions on the forum please double-check if the student posted anonymously to their classmates before using their name! If they posted anonymously, please do not address the student by their name.

Mark duplicate posts/questions as such, instead of responding to them again.

zyBook

See the relevant links under the “How to” section.

Releasing the labs

Note that the new labs will always be hidden, until at least one test is added to them.

Make a lab optional

From the main textbook page (the one that lists all chapters), click on the “Configure zyBook” link at the top right.
Select the lab on the left (by placing a checkmark next to it) and click on the link on the right that reads “Set selected sections as optional”. Note: do not mark as optional the book sections without first notifying/consulting with the instructor.

Reorder labs

From the main textbook page, click on “Configure zyBook”, then drag the labs by the tri-line icon on the left to reorder them. Note: do not reorder the book sections without first notifying/consulting with the instructor.

Lab guidelines

Read over the labs to ensure that they follow the format that was outlined in the sample lab on the course website:

learning objectives that help students review the relevant zyBooks sections (Read more about learning objectives here.)
- DO NOT USE “learn” and “understand” in the learning objectives
- use action verbs that explain what students should be able to DO / practice in this lab or know how to use before doing the lab
introduction that explains the motivation for the lab and provides the necessary information/data/clarifications
clearly states whether to define a function or write a program
- Checklist for a function:
  - description of what needs to happen that can go into a doctring
  - name
  - number of parameters and their types
  - print / return / both?
- Checklist for a program (written in the if __name__ == "__main__" block):
  - what input is needed
  - how/where to call the function
  - what output is needed and in what format
  - one or two example input and the corresponding output
Include a “Test your code” section that provides two or more example scenarios for students to check their code with.
Add a few Hints for the tricky concepts: e.g., a reminder of how to use a built-in function/method that they can use or what it does.
A “Troubleshooting” section, if appropriate - best to add it to the class website’s Troubleshooting section

Make sure that the code template provided for students is very clear and uses proper documentation.

Lab skeleton:

# Learning objectives
In this lab, you will practice
* 

# Instructions
motivation for the lab and the necessary information/data/clarifications

# Test your code
If the input is:
XXX

the output is:
YYY

# Hints / Troubleshooting

TBA

---
Code template -- this section is for the lab creators -- **remove the comments before publishing the lab**!

Make sure that the code template provided for students is very clear and uses proper documentation.

def func():
    """
    The function 
    Returns
    """
    pass
# Get from the lab instructions:
# description of what needs to happen that can go into a doctring
# function name
# number of parameters and their types
# print / return / both?

if __name__ == "__main__":
    pass
# Get from the lab instructions:
# what input is needed
# how/where to call the function
# what output is needed and in what format
# one or two example input and the corresponding output

Gauchospace / Gradescope

The setup for these platforms is more involved and our specific setup and considerations for this quarter are documented here.