Ticketing System #

This summer, we are trialing a new system for requesting help outside lab, called a “ticketing system”. This system differs from tools like Piazza and EdStem in that there is no public forum - all questions are private. As a result, you are encouraged and expected to show us your code, and explain your solution when submitting a ticket.

However, (curated) crowdsourced knowledge is incredibly useful, so we will maintain an FAQ for every assignment. We’ve initially populated the FAQs with good questions from previous terms. As you all continue to ask questions, we will add good questions and answers about each assignment to the wiki.

Whenever you’re stuck, we expect you to refer to the FAQ as the first step.

You can find the link to the ticketing system at https://qa.debuggi.ng/cs61bl.

Asking For Help #

Submitting a Ticket #

You can submit a ticket at any time of day. Course staff will respond as quickly as they can. We aim to resolve tickets within 12 hours on weekdays, and 24 hours on weekends. You can help us resolve tickets faster by following our suggestions below.

The categories below cover some kinds of questions that you might ask, and how you can ask these questions to help us help you most effectively.

Logistical Questions #

If you have a question about a logistical aspect of the course, just ask! However, tickets are visible to all TAs, so if you have a sensitive question for just the instructors, please email cs61bl@berkeley.edu.

Setup Questions #

If you have a question about a technical issue, check out the following resources first, depending on what you’re having trouble with:

You might also find your answer in the assignment spec.

If your question isn’t answered in these pages, then go ahead and ask in the ticketing system. You can also ask in a lab section, where the TA can click around on your computer themselves.

Conceptual Questions #

Often, you’ll have a question about a conceptual idea in a lab or project, or on a problem on a worksheet, quiz, or exam. To make sure you get a helpful answer, you should tell us:

  • What are you working on?
  • What is your thought process so far?
  • Why are you asking this question, and what do you hope to gain from our answer?

Note: “I don’t understand this problem.” is not a question, and will be responded to with “What don’t you understand about the problem?”

Similarly, please don’t ask for a “hint”. We don’t know what kind of hint you want, or where you are stuck. We don’t even know if you’ve worked on the problem. We will ask questions if you don’t tell us, and your ticket will be resolved more slowly.

Debugging Questions #

Another common question is when you have a bug in your code that you can’t figure out. To make sure you get a helpful answer, you should tell us:

  • Where is your code?
    • GitHub repo link (make sure to push!)
    • Gradescope submission link, if applicable
  • What assignment are you working on?
  • What is the bug?
    • What tests are you failing, or what error are you getting?
    • Note: “everything”, “it isn’t working”, “it fails the autograder”, “I don’t know”, and similar descriptions are not sufficient. We are not mind readers, and won’t magically know what you need help with.
  • What have you tried?
    • We expect you have used the debugger. What have you learned about your bug?
    • Note: “I’ve tried everything”, “I’ve tried debugging”, “I don’t know how to fix the bug” and similar statements are not sufficient. We will take these statements to mean that you haven’t tried anything, and want us to do debug for you. We will not.
    • Lab 4 will be very helpful once you’ve completed it.
  • Provide a screenshot of the section of code that you believe has a problem.