This document collects policies for the DB lecture course (CS 4320/5320) and practicum (CS 4321/5321). All students must be familiar with those policies. In this document, “4320” refers to both CS 4320 and CS 5320; similarly for 4321. “Assignments” refers to both 4320 homeworks and 4321 projects. “We” means the course staff, i.e. the instructor and all graduate and undergraduate TAs and graders. These policies are not arbitrary bureaucratic rules to make your life harder. They are necessary to make things run smoothly with our large class sizes. If you know and follow these policies, we can focus on helping you with the academic material. These policies also help us treat everyone in the class fairly.
Any policy may be waived by the Instructor (not by a TA) in an emergency. You must obtain written (email) approval from the Instructor before you do anything that would violate a policy.
4320 and 4321 require a mastery of basic computer science material at the level of CS 2110 and CS 2800. The first lectures of 4320 and 4321 explain in detail the specific knowledge and skills we expect. Every year, most students who choose to stay in 4320/4321 do have the prerequisite knowledge. However, if you don’t, do not expect that we will teach it to you. If you ask a question about material you should already know (e.g. “what is a unit test and how do I write them in Java” or “what is a preorder traversal of a tree”), we may help you at our discretion, but only if we have time -- in particular, if nobody else is waiting in office hours. This enables us to prioritize helping students who “did the right thing” and came in to the class with the required background.
You are encouraged to visit the Instructor and your TAs during office hours. The office hours calendar is linked from CMS or from Piazza. Sometimes, office hours may need to be moved or cancelled; if this happens, the staff member will update the calendar and/or post an update on Piazza. We will make every effort to hold our office hours but remember that we are human too, and many of the TAs are busy students like you.
Please respect our time and do not “drop in” on us outside office hours unless you have made a prior appointment; you can always make an appointment to see any of us by emailing us.
Be aware that we will not be able to spend a lot of time debugging your code in office hours. As you well know, finding bugs can take many hours even in your own code, let alone in someone else’s; we do not have the resources to give each of you many hours of debugging support. It is still worthwhile to bring us your code and ask for advice about your bug, but be aware that:
The rationale for the above policy is to allow course staff to manage their time fairly. Limiting debugging help to 10 minutes per student/group enables us to see more groups. That way we can become aware of common problems/bugs and hopefully resolve these common problems more efficiently, which is beneficial to more students in the long run. To be successful in the course given the above debugging policy, you need to take responsibility for your own code. You need to start early, allowing yourself plenty of debugging time. If you start early and come to office hours early, there is also a better chance that no-one else will be waiting, in which case you can get more than 10 minutes of our time. Also, do everything you can to identify and isolate the bug before you come in to office hours; if you have tracked down the bug to one small portion of your code already, this will greatly increase the chance we can help you. You cannot expect that we will deploy extra office hours before a due date, nor can you expect that a TA will be on Piazza on the evening the assignment is due answering questions right until midnight. You need to start early on every assignment to make sure you have the best chance of getting help.
We expect you to ask all academic questions on Piazza. You should only email the Instructor or TAs about administrative issues that affect only you or your group. Do not post assignment answers or partial answers on Piazza in a public post, even if you are not sure that your answer is correct. If you need to post a question that includes an assignment answer, set the post visibility to ‘private’ so that only you and the course staff can see it. We expect you to monitor Piazza. Important announcements about assignments, such as known bugs, clarifications, etc., will be sent via Piazza emails and posted as sticky (pinned) posts on Piazza. If we post an assignment-related clarification in a sticky post on Piazza more than 48 hours before the due date for an assignment, you are responsible for knowing about the clarification.
You will work on some assignments with partners. All of you will receive the same grade. You can look for partners via the appropriate Piazza thread; the Instructor is not able to match you up with a partner. For submission, you must form a group with your partner(s) in CMS before the due date, as CMS won’t allow you to join a group after the due date. In particular, make sure that all members of the group accept the invitations to join the CMS group before the due date. Individual submissions may be permitted in exceptional circumstances by arrangement with the Instructor. You will need to give a compelling reason why working in a group is impossible for you. For example: “I don’t want to work in a group” is not a compelling reason; “I need to travel back and forth to Asia to care for a sick relative, and it will be difficult to work with partners in Ithaca due to a 12-hour time difference” is a compelling reason.
You do not need to work with the same partner(s) for every assignment. If you experience serious trouble with your partner(s), let the Instructor know. We may or may not take action on the first instance, but talking to us early creates a “paper trail” to protect you if the problems persist.
Extensions to assignment deadlines will be granted only for severe situations that were sudden and unforeseeable. In all cases you must email the Instructor before the due date, unless you are unable to do so because of the nature of your emergency. If you submit late without arranging for an emergency extension, your submission will not be graded and you will receive zero points. Be aware that CMS often slows down a lot just before a due date as everyone tries to submit. It is in your own interest not to wait until the last minute to submit. You can make multiple submissions for an assignment, so there is no harm in submitting a partial version early even if you are still working on the final version.
Double-check you submitted the right file(s) via CMS - rather than, say, submitting the skeleton code or an assignment for a different class. For assignments that have a written part, all answers must be typed and all diagrams must be drawn using a program of your choice. Scans of handwritten/hand-drawn answers will beb penalized, and if they are sufficiently unreadable may receive zero points.
Once assignment scores are released, you will have the opportunity to request a regrade. All regrades must be requested via CMS, within one week from the release of the scores. Please do not come to the Instructor directly with a regrade request. The process starts with requesting a regrade via CMS, and escalates to the Instructor only if you are unable to resolve the issue with your original grader.
After the week-long regrade window has passed, regrades will no longer be accepted, barring exceptional circumstances (e.g. you were in hospital). It is OK to submit a regrade request if you do not actually wish to contest your score, you are just unsure how it was computed. The regrade request is the preferred way to proceed in this case also. When processing a regrade request, we may choose to regrade your entire assignment, in which case you may lose points if we discover a grading error was made in your favor. This happens rarely, but you should be aware of the possibility.
Most of your code in both 4320 and 4321 is graded by running it on a set of automated tests, so if your code fails the tests you will receive very few points We have a “breaking automation” policy that is intended to mitigate hardship due to genuine misunderstandings. Once you get your score, take a look at the automated tests. They will be released in CMS as one of the “assignment files” when we release the scores. The breaking automation policy may apply to you if:
If all these conditions apply to you, you may be able to get some points back. In this case, submit a regrade request via CMS, together with your code fix, and explicitly state that you are requesting consideration under the breaking automation policy. The grader will examine your fixed code and run it; depending on the situation, you may get some points back. However,
Note that the breaking automation policy exists to help students who lost a lot of points due to a good-faith misunderstanding. It is not intended to allow arbitrary resubmissions after our tests are made public, and we will not allow it to be abused in that way.
In both 4320 and 4321, there are no firm numerical cutoffs for grades, nor does the Instructor forcibly curve to a particular median. It is theoretically possible for everyone to get an A in the class. The cutoffs between grades vary year to year as the assignments and exams fluctuate in difficulty. In 4320, sometimes the ‘A’ band has extended well into the 70s (i.e. people with an aggregate score less than 80% still got an A), but you should not treat that as any kind of guarantee for this semester. In particular, in 4320, the prelim and final exam are usually challenging and the scores and medians on those are usually quite low, so you should strive to do as well as possible on the homeworks.
The following are the standards used as a starting point for letter grades:
In addition, we take into account factors such as improvement over the course of the semester, individual circumstances/hardship, etc. Typically the median in 4320 ends is around B+ or possibly A-, but this can vary semester to semester. At any time, if you have an individual inquiry/concern about your grade, you are welcome to see the Instructor during office hours, or (preferably) make an appointment for a more private meeting.
There is a lot of official material about academic integrity policies, but the essence is the following: You must not cheat. The most common form of cheating is taking someone else’s work and representing it as your own. Another form of cheating relevant to 4320 is altering your prelim or final exam after you get it back in an attempt to get more points in a regrade.
Cheating is morally wrong and it violates official Cornell policies. If you are caught cheating you can expect a formal hearing (with official paperwork that Cornell keeps on file afterwards) as well as a significant grade penalty if you are found guilty. For 4320 prelims and final exams, be aware that we photocopy a subset of the papers. If we can prove you altered your prelim or final exam paper, you will receive an F grade for the entire course, not just a zero for the exam. Don’t even think about it, it is not worth the risk.
It is NOT a violation of academic integrity to consult external sources (books, websites, people), in fact we encourage this. It is not even a violation of academic integrity to copy material – text or code – as long as you tell us exactly what you copied. Of course if you copy a lot material, this means you are not completing the assignment yourself, so you can expect a deduction in your score appropriate to the extent of the copying. Copying three lines of code, especially if you make it clear that you understand the code, will not attract a deduction. Copying a whole proof or three hundred lines of code will probably give you a significant deduction. Nonetheless, as long as you tell us exactly what you copied, you won’t end up in an academic integrity hearing, which is much more serious than losing points. Therefore, for all assignments:
If you follow the above two rules strictly, you will never end up in an academic integrity hearing for a 4320 or 4321 assignment, because you are not representing someone else’s work as your own.
We will be running your code submissions through automated tools that detect code similarity. These tools are very good nowadays; we have caught students who copied code and refactored it substantially, breaking up into methods so it had a significantly different structure from the original. If you copy or “are inspired by” any code, be very sure to acknowledge it and explain how you used the source material. Note that we often compare your submissions against submissions from previous semesters, so if you copy from a friend who took the class before you, you are almost certain to get caught.