Table of Contents

• Course Info
  • Learning Goals
• General Policies
  • Responsibility for Course Material
  • Accommodations & Disability
  • Collaboration
    • Exercise Collaboration
    • Project Collaboration
  • Tutors
  • Disclosures of Discrimination, Harassment, and Sexual Misconduct

• Graded Work

  • Help
  • Grading Philosophy
  • Weekly Schedule
  • Exercises
    • Submitting Exercises
  • Projects
    • Submitting Projects
  • Quizzes
    • Quiz Philosophy
    • Quiz Mechanics
    • Honor Code Policy
    • Learning Goals
    • Retaking Quizzes

  • Exams

    • Midterm
  • Final Project
  • Extensions
    • General
    • Exercises
    • Projects
    • Quizzes
  • Grade Calculation

Course Info

CS111 is an introduction to the problem solving foundations of computer science. In this course, you will learn big ideas about solving problems, developing algorithms, and organizing programs.

These ideas include:

• Abstraction: capturing common patterns, hiding information, making specifications (contracts);
• Modularity: expressing programs as the composition of mix-and-match parts;
• Problem solving strategies: divide-conquer-glue, recursion, iteration;
• Models: ways to understand how programs are executed;
• Interdependence: computational technology should be in service of human flourishing.

You will get hands-on experience with these ideas by reading, modifying, debugging, designing, writing, and testing Python programs. Example programs will involve text manipulation, Python graphics, music, simple data analysis, and working with files.

Problem solving and programming are skills best learned by doing, which is the motivation for hands-on lab sections:

• CS111 students in lecture sections 01, 02, and 03 must register for and attend one of the weekly 2-hour laboratory sections in the range L01 through L05.

• Lecture section 04 is an experimental one with students who have significant previous programming experience. Students in this section will not attend a weekly lab section but must still complete (on their own) the same lab exercise notebook as all other CS111 students. Students in lecture section 04 must register for lab section L06, which is just the registrar's placeholder for a nonexistent lab for the labless students.

CS111 is required for students who wish to major or minor in computer science or elect more advanced courses in the field. Consult Choosing an Introductory CS Course for more information.

Prerequisite: None. No prior computer science background is expected.

Distribution: Mathematical Modeling. Does not satisfy laboratory requirement.

Unit: 1.0

Learning Goals

The aim of this course is to enable students to solve various sorts of problems by writing programs that emphasize some of the big ideas listed above (namely, abstraction, modularity, strategies, and models). This course happens to use the Python programming language to explore these ideas. Although students will learn a lot about Python along the way, our focus is on the big ideas. Students will really be learning and practicing techniques for solving problems — techniques that apply to any programming language, and, indeed, to any discipline.

Students who complete this course should be able to:

• Read, modify, debug, design, write, and test Python programs to solve computational problems
• Reason carefully about computational problems and design algorithmic solutions before writing code
• Work collaboratively with partners or small groups to solve computational problems
• Design and develop programs that use abstraction and modularity
• Develop a toolbox of problem-solving strategies (such as divide-conquer-and-glue, iteration, and recursion), identify appropriate strategies for a particular problem, and apply those strategies to solve the problem
• Use computational models (such as execution frames and memory diagrams) to reason about computational processes
• Translate computational problems, algorithms, and problem-solving strategies between English and Python
• Recognize how computational technology can be used both in beneficial and harmful ways.

General Policies

Responsibility for Course Material

This course has many different resources available to help you study, and we assume that students will engage with the resources that work best for their learning styles. However, when designing exams, we do assume that some resources will have been fully explored, and we also have some expectations for preparedness for each class meeting.

• Lectures: Before lecture, you should review the slides for that lecture (linked on the schedule). If your lecturer does not cover the entire lecture notebook and slides in class, we expect you to go over the remaining material on your own.
• Labs: Labs may have some preparation materials that will be announced beforehand that you are expected to go over. Typically this should not take more than 15-20 minutes per lab. But you should try to have a good understanding of all previous lectures before each lab.
• Exercises: In lectures and labs, we will work on some exercises that are graded, and there may be additional ungraded exercises. The graded exercises are your responsibility and you may often need to work on these beyond class time. The extra ungraded exercises do not need to be completed, and serve as extra challenges or learning opportunities beyond the basics required for the class.

Accommodations and Disability

If you have a disability or condition, either long-term or temporary, and need reasonable academic adjustments in this course, please contact Disability Services to get a letter outlining your accommodation needs, and submit that letter to your instructor. You should request accommodations as early as possible in the semester, or before the semester begins, since some situations can require significant time for review and accommodation design. If you need immediate accommodations, please arrange to meet with one of us as soon as possible. If you are unsure but suspect you may have an undocumented need for accommodations, you are encouraged to contact Disability Services. They can provide assistance including screening and referral for assessments. Disability Services can be reached at disabilityservices@wellesley.edu, at 781-283-2434, by scheduling an appointment online, or by visiting their offices on the 3rd floor of Clapp Library, rooms 316 and 315.

We strive to be inclusive and provide an equitable learning opportunity for all in this class, and we believe that accommodations for disability make the class more fair, not less.

Collaboration Policy

We will do a lot of work in pairs in this class, including in lectures, in labs, and on projects. We have a pair programming guide that helps explain how pair work should happen and some of the reasons why we use it so much. However, collaboration outside of people you are working with directly on a team must be limited:

• It is never acceptable to present someone else's work as if it were your own. It violates the basic principles of academic honesty. Unless explicitly instructed otherwise, assume all work you hand in is to be yours and yours alone.
• If you get study materials from a student who has already taken the course, it's fine to review their notes, but solutions to exercises, project tasks, quizzes, and exams should not be consulted, because some of these will be the same from semester to semester! You are welcome to consult a faculty member for specific guidance in these cases, but submitting work that is based on a past semester's solution will be considered an honor code violation, especially if you represent that work as your own individual work.
• When is it acceptable to collaborate with other students?
  • While you are working on a project with a partner, you may collaborate freely with that one partner (and you should be working together on the same computer anyways). You (and your partner if you're working with one) may collaborate with other students by talking about the problem or your solution in a natural language (e.g., English), but you may not use any programming language, and especially not Python. In other words, you should not be looking at other people's code (or project solutions), and you should not show your programs to another student. (See below for more details.)
  • When working on exercises, you are allowed to freely collaborate with any other students in the class, including looking at each others' code, but it is your responsibility to ensure that:
    1. You understand and can explain the operation of all code you submit.
    2. If you are sharing your code with another student, they understand it fully and could explain it themselves. This means you cannot simply send someone your solution to an exercise for them to look at: you need to have a conversation with them about it, and they should re-write your code in their own style rather than copying it verbatim.
  • When working on quizzes or exams, you may not communicate with other students in any way.
• When you turn in a project, you must list all other students with whom you collaborated. If you get significant help from any of the course staff, including the TAs, you should acknowledge that, too. Academic honesty requires it, and it helps us advocate for maintaining funding for things like TAs. If you are not sure what constitutes collaboration or significant help, err on the side of caution.
• You may consult public literature (books, articles, the web, etc.) for hints, techniques, and even solutions. However, you must reference any sources that contribute to your solution.
• When you use a public computer, save your work, remove the local copy when you are done, and log out. If you find someone else has forgotten to log out, then log them out without looking at any files or work in open windows.
• We will interpret a violation of any of the collaboration policies stated above as a violation of the Honor Code, and will bring any such violation to the attention of the Honor Code Council. Sadly, we encounter such violations almost every semester. For your sake and ours, please don't be tempted to cheat; you are likely to be much better off getting a poor grade on an problem set or exam than you are if you are found guilty of cheating, and we offer multiple opportunities to revise and make-up work on almost every aspect of the course.

Collaborating on Exercises

As outlined above, we expect the following forms of collaboration when working on the weekly exercises:

• You may work with any student in the class, or any group of students, and may work with multiple different groups of students on the same exercise.
• You may also look at each others' code and share it, which you may NOT do for projects (except for sharing code with your specific partner if you have one).
• However, each student is responsible for fully understanding the solution they submit for each exercise, including solutions that were worked on in pairs or groups. If your partner does something to solve the problem that you don't understand, ask them to explain it, and if they can't do so in a way that you understand, it's best to re-work through that exercise on your own later.
• As a corollary, it is the responsibility of every group member to make sure that all group members understand every solution submitted. If you think your partner doesn't quite follow what you're doing, stop and explain it to them. The act of explaining is actually a great way to solidify and improve your own knowledge.
• If you don't understand something about a project task and want to ask a friend for help, consider instead identifying an exercise that's similar to that project task and going over the exercise with your friend, since that way you can both look at and share code, while sharing code for a project task is not permitted except with your partner for that project.

Collaborating on Projects

Note: If you are looking for a partner to work with on a project, you can use this partner-finding spreadsheet.

All project tasks may be worked on individually, but are designed to be tackled by two people, and you will find that working together closely with a partner can be quite productive. We have some guidelines for partner work: you are not allowed to simply split the task into two parts and each do part of the task (neither of you would understand the entire task in that case).

You should write both partner's names on the "Authors:" row of your top-of-file information, and put the names of the people either of you consult with (including other classmates, tutors, and instructors) on the "Consulted:" row.

In partner work, each two-person team will create one or more solution files together for a task. Each team member will submit their own electronic copy of the solution files, and every member of a team should ideally submit identical files. Each member will be given the grade for the file they submit. (If the files aren't the same, the team members may receive different grades; it is your responsibility to communicate with your partner and make sure you each have a copy of the most up-to-date code to submit.)

Although you can work with the same partner on multiple tasks throughout the semester, we strongly encourage you to seek different partners for different tasks so that you get a better sense for the range of collaboration styles, and so you do not become too dependent on a particular partner.

All work by a team must be a true collaboration in which members actively work together on all parts of the task. It is not acceptable for team members to split up the task and work on parts independently. All programming should be done with both team members working at the same computer or remotely via a shared screen. Both team members must share the responsibility of "driving" (typing at the keyboard), swapping every so often. The only work that you may do alone is debugging code that you have written together and talking with the instructors and drop-in tutors (we understand that you may not both be able to attend drop-in hours at the same time, but when you attend drop-in hours and get help individually, it is your responsibility to explain what you learned to your partner and make sure they understand it).

Note that with COVID, there may be times when two people working at the same physical computer is not optimal. In these cases, we suggest the following alternative collaboration methods (pick one that works well for you):

1. Remote pair programming. Using Zoom, it is possible for one member of a meeting to take control of the other's computer (the option to request remote control appears when someone is sharing their screen). You can therefore program together on one computer remotely. Remote control offers the advantage of easily supporting the driver/navigator model that is essential to pair programming because both partners can edit the code directly. One partner should open up a window with the particular task and then allow access to the remote partner to control that window. You can, of course, use screen sharing and discuss each task if you are uncomfortable with the remote control model. However, make sure that each partner has an opportunity to write code. This will likely require copy/pasting code back and forth or sharing/emailing python files, which is why we recommend the remote control model. Note that you cannot copy/paste code through Zoom chat, because copying from Zoom chat introduces invisible characters that will break the code.
2. Independent work + verification. To ensure that each member of a team actually understands the full solution to a problem, if remote pair programming is not feasible (perhaps connections aren't good enough) you may work independently on a problem, and when you each have an attempt (they need not be working perfectly), you can come together to compare your code and discuss the differences between your attempts. This method of working together is more work than pair programming, but still offers some advantages over individual work, like the ability to discuss your solution in depth at the code level with another student and the opportunity to do debugging together.

Tutors

Tutors for this course are available to help you figure out the sticky parts of programming. They should help you polish your debugging skills and help spot tricky situations when you're stuck on an assignment. To ensure that your time and the tutor’s time is used efficiently, we have drafted the following policy that you should follow while interacting with tutors:

• Tutors will not simply give you answers if you ask for them. Tutors are there to help you reason through problems. You are the one who is learning to apply your programming and debugging skills to solve problems. It is detrimental to your learning to have a tutor solve a problem for you.
• You can expect a tutor to help you for no more than 5 minutes at a time. Because of the size of the class, tutoring hours will also get very busy, especially as the deadline for each project approaches. As a result, the tutors will try their best to help you efficiently. Be ready to explain your problem as clearly as you can, including which part of your code is not working as you'd like, and which debugging techniques you have used to help diagnose the problem already. In many cases, the tutor will be able to help by supplying a critical hint. Work with this hint, and if you get stuck again, feel free to request more help. If a tutor gives you advice that you don't understand, let them know.
• In many cases, you may have questions about fundamental course concepts that seem too abstract to address your immediate problem, but that are preventing you from seeing a simpler solution to the problem at hand. Don't be afraid to go back and review some conceptual material, and asking tutors for help with this is a great thing to do.
• Attend drop-in hours ahead of deadlines. They tend to be less crowded, and tutors will be able to devote more time to your concerns.

Faculty Responsibilities on Disclosures of Discrimination, Harassment, and Sexual Misconduct

Pursuant to Wellesley College policy, all employees, including faculty, are considered responsible employees. That means that any disclosure of discrimination, harassment, or sexual misconduct to a faculty member will need to be shared with the College's Director of Non-Discrimination Initiatives / Title IX and ADA / Section 504 Coordinator (see the Wellesley Title IX page for more info). Students who do not wish to have these issues disclosed to the College should speak with confidential resources who are the only offices at the College that do not have this same reporting obligation. On campus, confidential resources include Health Services (781-283-2810 available 24/7), the Stone Center Counseling Services (781-283-2839 available 24/7) and the Office of Religious and Spiritual Life (781-283-2685). You should assume that any person employed on campus outside of these three confidential offices has an obligation to share information with Wellesley College through the Office of Non-Discrimination Initiatives.

Graded Work

Getting Help

The CS111 staff expects that you will have some questions every week. You can see our whole team on the Instructors page, and see when we are available for help on the Drop-in Schedule page. We have a super talented crew of tutors who hold afternoon and evening drop-in hours (sometimes we refer to this as "help room"). You can also post a public or private question using Sakai.

Tips for your questions

• When asking questions during drop-in hours, try to make sure you have clearly identified a problem and can explain what you're asking about. "My code doesn't work," is not a question, but "I tried to do X and got Y as the result, when I expected Z, can you help me figure out why?" is a great question. With limited time to help each student when things get busy, having your question prepared and as specific as possible helps immensely. And while you're waiting for help, spending that time to try to narrow down your question or make it more specific is always useful.
• Submit your questions in Sakai rather than privately e-mailing the instructors: this is more productive because your classmates probably have the same question too!
• If your public question contains part of your solution code, we may remove it. Do not include code in public questions submitted via Sakai. (You can include code in private questions, but should try to ask questions without including code if you can).
• You are encouraged to talk to your classmates (in a human language, not code) about exercises and projects. Sometimes bouncing your ideas off the person next to you can be really helpful and illuminating!

Grading Philosophy

In CS111, we believe in both “growth mindset” and “mastery grading”. Growth mindset is the belief that individual attributes like talent can grow and develop through hard work, good strategies and constructive feedback. In contrast, a fixed mindset is the belief that human attributes such as intelligence cannot be changed. A growth mindset focuses on the incremental progress we all make as we learn new material.

In other words, you are not "good at" or "bad at" computer science, nor do you have a fixed "potential" as a computer scientist. You are "getting better at" computer science, and how much better you get over the course of this class, as well as what cool things you'll ultimately achieve in the long term, depends on how you spend your time.

Mastery grading is the teaching philosophy that articulates clear learning goals. Grading is based on the ability to master those goals. In CS111, we want to give students every opportunity to master the learning goals we set out for the course. Exercises, projects, and quizzes will offer multiple opportunities to complete learning goals through revisions and retakes. We want students to have the ability to continue to improve their knowledge of the material and to look at assignments as less of a judgement of their intellectual capacity and more as an opportunity to show the skills they have mastered.

For more information on both of these philosophies, please look at an article on mastery grading by Oscar Fernandez from Wellesley's math department.

Weekly Schedule

During a typical CS111 week, you will complete exercises, quizzes, and one or more project tasks:

• Some graded exercises are completed in lectures and labs, although you will usually have to finish some of these outside of class time.

  • There may be some additional graded exercises to work on beyond those seen in lecture or lab.
  • Graded exercises from a lecture should generally be completed before the next lecture, even if that's earlier than their due date.
  • Additional graded exercises must be completed by the weekly exercise deadline (normally 11 p.m. ET on Tuesdays), although you will usually want to do these before working on project tasks, because they will help prepare you for the project, and you should usually start the project before the exercise deadline.

• The quiz for each week will be taken online. You will need to find the time to take both a quiz and a retake quiz each week before the quiz deadline (normally 11 p.m. ET on Mondays). Each quiz or retake should take about 20 minutes (although the absolute time limit is 30 minutes). If you have a perfect score on a quiz, you do not need to do the retake, but otherwise, you are expected take the retake quiz the following week to ensure that you understand the problems you got wrong on the original quiz. The retakes will have different questions that cover the same material as the original quiz.

• The weekly project will normally be due at 11 p.m. ET on Thursday, practicing concepts covered the previous week. Each week, there may be some choices as to which tasks to do, or some specific tasks may be required. There may be multiple tasks required in some weeks.
  • You will be able to take an automatic 24-hour extension on the initial project deadline deadline if you need it.
  • You will also be able to submit revisions after the initial deadline, usually about 5 days later (normally Tuesday at 11pm); check the schedule for exact deadlines).

Holidays or other factors may create some deviations from this schedule, check the course schedule page for detailed deadlines.

For any and all deadlines, if you have extenuating circumstances, contact an instructor to request an extension. We also accept late make-up work for partial credit for exercises and project tasks (but not quizzes without an explicit arrangement).

Exercises

Exercises are small graded coding challenges that you will work on both in and outside of class. Both lectures and labs will typically have exercises associated with them, and there will be some extra exercises each week to be completed on your own. Exercises differ from ungraded coding examples that will sometimes be used in lecture to explain Python coding. Exercises and examples will appear in different notebooks to help you understand the distinction between them.

Use the schedule to access the exercise pages where you can find links to the code files that contain the exercises.

Submitting Exercises

Each exercise will come with testing code, and when you run the testing code, it will also submit the results to Potluck. You can resubmit as many times as you like until you get it right, and only your best submission will count for your grade. If you are working offline, this won't work, but you can still see any error messages produced by your code and can simply run the tests again later when you're online to submit then.

During this process, you will be asked to list the names of people in your group (since we will typically work in groups of 2-3 in both lectures and labs). Make sure to enter everyone's username correctly so that everyone gets credit. Please also remember to share your code with any partners you work with so that they can revisit it later (e.g., if they need to resubmit).

On the Potluck server near the top of the dashboard, an overview of submitted exercises will be shown; you can click to expand the individual exercise groups and see details of which ones you've completed or not. Your code must pass the associated tests to count as complete, although you will get partial credit if it passes some of them.

Your average score across all weekly exercises (in terms of % completed) is one portion of your grade (see the grade calculation section).

Projects

There are weekly projects in CS111. Projects will typically be due on Thursday at 11pm of each week and will come out the week before. You may work with a partner on projects, but you may only work with one partner in each week (see the project collaboration section for more details).

You will normally have a few choices each week about which task to work on, although in some weeks certain tasks may be required. Normally, your project grade for each week will be based on the best score you receive on a single task. But during some weeks, you may be required to complete more than one task. However, if you plan on being a CS major or minor and want to deepen your understanding of the material, you are encouraged to complete more than one task each week. Doing more than one task per week will prepare you for subsequent programming classes.

Task scores will be available via the Potluck submission server shortly after you submit a task, and you can re-submit as many times as you like until you are happy with your score. We will check whether your code works correctly, is properly documented, and is submitted to the server on time.

Each task within a project will come with a rubric that explains in detail how we will grade that task. The rubric has core goals and extra goals. The core goals are the concepts and tasks that we feel are most pivotal to your understanding of the project material. Extra goals are the concepts and tasks that provide additional learning and challenges beyond the basic material; the extra goals are not worth any points.

You can receive one of four scores on each task of each project task:

• 100 ("complete" or "excellent") indicates successful completion of all core goals
• 85 ("almost complete") indicates successful completion of nearly all core goals
• 70 ("partially complete") indicates successful completion of at least half the core goals, but not all of them
• 0 ("incomplete") indicates successful completion of less than half the core goals

On top of the 100 coding points for a project task, there are 10 additional timeliness points for timely submission (so project task scores are based on a total of 110 points, not 100 points).

• If you have a submission that earns at least partially complete before the initial deadline (possibly after taking the 24-hour extension) you earn 5 of these points.

• If you have any submission that earns at least almost complete points, including during the revision period, you earn the other 5.

Some examples:

• Someone who misses the initial deadline and never goes above partially complete would earn 70/110 points (63.6%) for that task;

• Someone who submits a partially complete task on-time (including with a 24-hours extension), but never revises it, earns (70+5)/110 = 75/100 points (68.18%) on that task.

• Someone who has no on-time initial submission (or has one but it doesn't reach partially complete) but eventually revises up to almost complete, will earn (85+5)/110 = 90/110 points (81.8%).

• Someone with a partially complete or almost complete initial submission who revises up to almost complete earns (85+10/110 = 95/110 points (86.36%).

• Someone with a partially complete or almost complete initial submission who revises up to complete earns (100+10/110 = 110/110 points (100%).

Note that you may submit a "revision" even if you didn't submit anything by the initial deadline (all you'll lose is 5 timeliness points). We strongly suggest that you take the time to submit a revision if you score 75/100 or lower on a task, in order to make sure that you understand the concepts from that task going forward.

If you know you will miss the initial deadline, you can take a 24-hour extension by requesting an extension (through the submission page) before the deadline. See the extension policy. Alternatively, you can still submit by the revision deadline for full credit minus 5 timeliness points, even if you do not have an initial submission.

Submitting Projects

Submission of projects in CS111 is entirely electronic.

Use Potluck for all actions involving projects: submitting initial and revised tasks, declaring a 24-hour initial submission extension, reviewing feedback on your submissions, and reviewing task solutions.

• For the initial submission of a task, use Potluck to navigate to the task entry, then use the Browse button to navigate to your solution .py file on your computer, and click Submit task. You can submit a particular task as many times as you want before the initial deadline. Any new submission will supersede the previous one. Because feedback is automatic, You should be able to see feedback within about a minute of submitting.
• To declare that you are taking a 24-hour extension for the initial submission, within Potluck navigate to the project entry, and click on the link that says "Take an extension" on the left-hand side underneath the due date. (There is currently no way to "un-take" an extension besides getting in touch with an instructor.)
• Feedback for the initial submission will be available shortly after you submit. To view this feedback, use Potluck, navigate to the task, and click View initial feedback.
• Once an initial project deadline has passed, there is a revision period (typically 5 days; check the schedule for details) during which you can submit revised versions of any tasks for that project. You can earn full credit for a revised submission, but if your initial submission was incomplete, you will forfeit some timeliness points. You can see revision feedback via the "view revision feedback" link for each task.

Quizzes

Quiz Philosophy

CS111 uses an approach to quizzes that may be unfamiliar to you. We use a mastery grading approach that is designed not just to assess your learning but to enhance your learning.

A study guide (with solutions) will be provided roughly once a week on topics covered that week in class. We strongly encourage you to review the study guide and solutions when preparing for the weekly quiz, and to have a filled-out copy of the study guide on hand as part of your notes when taking each quiz.

There are two versions of every quiz:

1. The regular quiz (graded): This quiz is taken in Gradescope (see details below) and will generally test the material from the previous week's lectures + lab. You should also be nearing completion of that week's project by the time you take the quiz.

2. The retake quiz (graded): This is a second graded version of the quiz, with the same learning goals. It is optional but we expect you to take it if you did not score well on the regular quiz, and it can be used to improve your score on the regular quiz in the week following the regular quiz. The regular quiz may highlight areas where your understanding could still be improved (see details below on Retaking Quizzes).

Quiz Mechanics

• All quizzes and retakes are done in Gradescope. Setting up a Gradescope account is part of homework 0.
• There is a 30 minute limit on each quiz and each retake.
• Grades will be released through Gradescope (you will get an email notifying you when you have graded work to view).

The regular and retake versions of a quiz are graded by the instructors. Quiz solutions will also be made available once grades are released.

Honor Code Policy

Quizzes are open-notes, but you may not consult other students or look things up on the internet during a quiz or retake, nor may you consult other students who have already taken the quiz. Using Thonny or a Jupyter notebook or anything that runs Python code is explicitly forbidden during quizzes and retakes. Doing so is considered an honor code violation.

You should not talk with other students about a quiz even after you have taken it and/or the deadline has passed, because they may not have taken it yet if they have an extension due to special circumstances. The instructors are happy to answer any questions you might have about quiz scores or other details.

Learning Goals

Each quiz will assess a series of learning goals to test students’ comprehension. Each question is designed to target one or more learning goals. Each quiz question will be labeled with the learning goal tested. Upon receiving feedback, we strongly suggest that students examine their performance on each learning goal so they have a complete understanding of what they know and what they need to improve on.

Retaking Quizzes

As indicated above, a week after taking a regular version of a quiz, students have the option to take a retake version of the quiz if they want to improve their understanding and/or score on the quiz.

In the retake quiz, students do not need to complete the entire quiz; they only need to complete the questions with the learning goals that they would like to improve. There is no grade penalty or grade limit for retake quizzes.

To illustrate: suppose that Wyeth Wellesley takes the regular version of Quiz 1 during the third week of classes. They are satisfied with their score on Question 2, but would like to improve their score on Questions 1 and 3. Before the next week's retake deadline, they can take Quiz 1 Retake, ignoring Question 2 and answering only Questions 1 and 3.

For each Quiz question your final score on that question will be the maximum of the two scores for that question across the two graded versions (regular and retake) of the quiz.

For example, suppose that on a regular version of a quiz, Wyeth scores 3 out of 8 points on Question 1, 11 out of 12 points on Question 2, and 8 out of 10 points on Question 3. On the retake of this quiz, Wyeth submits only Question 1 (earning 6 points) and Question 3 (earning 7 points), but does not submit Question 2 (earning 0 points). The following table shows the result of the maximization procedure for this quiz. Wyeth's final quiz score is 6 out of 8 points on Question 1, 11 out of 12 points on Question 2, and 8 out of 10 points on Question 3, for a total of 25 out of 30 points on the quiz.

Quiz Version	Question 1 Score (max 8 points)	Question 2 Score (max 12 points)	Question 3 Score (max 10 points)	Total (max 30 points)
Regular	3	11	8	22
Retake	6	0	7	13
Final Quiz Score	6	11	8	25

Note that the unit of maximization for a quiz is an entire question. If a question has subparts, you must submit all the subparts of that question on a retake if you want to improve your score on that question.

Exams

Exams are graded collectively by the CS111 instructors. Many questions require us to use judgement, and we do our best to be both consistent and fair. If you think we made a mistake grading your exam submit a regrade request in Gradescope.

You should not communicate with any other person about the contents of any CS111 exam before, during, or after taking it except CS111 instructors (again, your classmates may have extenuating circumstances that warrant taking the exam later than usual). Any violation of this policy will be brought before the Honor Code Council.

In-Class Midterm Exams

There will be two in-class midterm exams during lectures (see the Schedule for the exam date).

These are both pencil-and-paper exams; you are not allowed to use any computers or other electronic devices (including smartphones or tablets!).

This is an open-notes exam: you may bring with you any of your own notes, as well as hardcopies of any course materials from the semester. However, your time to consult notes during the exam will be limited, so we encourage you to make a one- or two-page summary of key notes you may want to consult as part of studying for the exam.

Final Project

Details of the final project will be announced later in the semester.

Extension Policy

General Policy

We recognize that this academic year is likely to be influenced by the ongoing COVID pandemic. We strongly encourage you to speak with any of the faculty for CS111 for any reason --- whether COVID-related or not --- that might inhibit you from successfully completing your coursework. We are empathetic to the many hardships that students will face as we learn together during this crisis. Do not hesitate to reach out!

Extension Policy for Exercises

If you need extra time to complete exercises, contact an instructor. You should be making some progress on the weekly exercises in lectures and labs each week and then finishing up any leftover exercises as homework.

Extension Policy for Projects

The initial submission for a project is typically due at 11pm Thursday with revisions typically due 5 days later (check the schedule. If you submit an attempt that receives at least "partially complete" before the initial deadline, you will receive 5 of the 10 timeliness points, and if you submit an attempt that receives at least "almost complete" any time before the end of the revision period, you will receive the other 5 timeliness points. During both periods, you may submit as many times as you like, with each submission replacing the previous one.

In any (or even every) week, you can declare an automatic 24-hour extension for the initial due date. In order to receive the extension, you must declare it via the Potluck submission server before the 11pm deadline. If you feel that you need more than an extra 24 hours, please contact one of the CS111 faculty members directly.

Taking the automatic extension for the initial deadline does not affect the revision deadline.

Grade Calculation

Your course grade will be based on the following components:

• Exercises: 15%
• Participation: 5% (attendance and in-class Plicker exercises)
• Project Coding: 30%
• Quizzes: 20%
• Midterms: 20%
• Final project: 10%

Your combined course grade must be at least 75% to pass the class.

Additionally, you must individually pass each of the six core components of this course (quizzes, projects, exercises, midterms, participation, final project), by earning 75% or more for that component (or 70%* or more for the midterms).

*You must score 70% or higher for at least one of the two midterms, but you don't have to do so for both. However, both midterms contribute together to your overall course grade, which as stated above must also be 75% to pass, so you cannot simply ignore the second midterm if you do well on the first one. We reserve the right to lower (but not raise) the percentage required to pass a midterm based on actual midterm performance if the midterm turns out to be more difficult than we intended.