CSCI S-51 Grading Policy File: cs51-summer-grading-policy.txt Author: Bob Walton Version: 1 ======================================================== Scoring: There are 9 assignments worth a total of 600 points, or 60% of the total course grade. A typical assignment is divided into a code part worth 40-50 points and a theory part worth 10-20 points. The two parts are submitted separately: the code is graded by the course grader and the theory is graded by the course instructor. The midterm is worth 100 points, or 10% of course grade. The final is worth 300 points, or 30% of course grade. Each point on an exam is worth an estimated 1/2 minutes work during the exam. ======================================================== Principals of Grading Code: (1) Code should be readable. Small numbers of points are deducted for violation of principals for writing readable code. (2) Highest debugging priority goes to making code that will not crash when run, even if it does not produce the right answers. DO NOT submit code that crashes on normal test input. Get help and fix the code instead, even if it makes the submission late. Code that crashes will NOT be graded. (3) Next highest priority goes to making code that will produce the right answers when given input one would normally be expected to test the code against. Tests should ideally include not just test cases distributed with the assignment, but also test cases written by the student that ensure each part of the student's code is exercised at least once. If a test reveals a bug the student cannot find, it will help the student's grade if the student places a comment in his test input (.in) file describing the failed test. (4) More obscure errors will result in the loss of a minimum amount of points. For each assignment, a schedule assigning the number of points lost for each type of mistake is developed and applied uniformly to all students. This schedule follows the above principals, but may otherwise vary with the assignment and graders. To avoid bias, students are not permitted to nitpick the grader's judgment, and to avoid this, the schedule is not published. The student should understand the errors the student makes, and see any instructor if the student cannot understand why something is in error. The same mistake repeated a few times in a program counts as a single bug. The schedules are strictly adhered to for submissions that receive grades of 70% (35 points) or more. For submissions of poorer quality, the grading becomes less strict as the point score goes down, and as the grader finds more bugs, she/he may start taking off fewer points per bug than indicated above. Submissions that run correctly a substantial majority of the time should get at least 50% of possible points. Specific point allotments may be designated for parts of an assignment. These are guides and not absolute limits on the number of points that can be deducted for errors in one part. Only if a student omits a part of the assignment are these point allotments guaranteed to be used to determine the value of the part. ======================================================== Submission Dates and Lateness: Code must be submitted using the `make submit' command by 11:59 PM on the day the assignment is due. After doing a `make submit' you must do a `make sprint' to obtain a printout. This printout and the theory part of the assignment are due in class on the first class day AFTER the assignment due date. The theory part is generally handwritten. Students are permitted a certain number of late days before lateness penalties are considered. By a late day we mean a day in which one assignment is late: so if one assignment is 3 days late and another is 2 days late, that is a total of 5 late days. The schedule of allowed late days is as follows: What Your Grade Would Be If Late Days You All Your Submissions Were Are Allowed On Time Before Penalty A 10 A- 12 B+ 14 B 18 B- 20 C+ or less infinite All assignments must be submitted before exams start, no matter what. The last day for submitting assignments without any penalty is the Saturday before exams. The last day of submitting is the Sunday before exams, and a fixed penalty, usually 20% of grade, is applied to submissions on this Sunday. This Saturday and Sunday are referred to as the DROP DEAD dates. One assignment is due approximately every 3 weekdays. Because of this rapid schedule, it is hard to catch up once you have fallen much behind, and usually falling significantly behind means not finishing the last assignments and accepting zeros thereon. Normally this is all the lateness penalty that is really needed, and the above schedule is intended to keep us from having to bother about lateness penalties. We do not usually give additional late days for minor illnesses; the above late day schedule should be enough to take care of one minor illness. If you have more serious problems, get written notes from doctors or officers of the summer school, and present them to the instructor, who will have to make special accommodations that will probably last into exam week. To get a C in this course you need to get 500 points, which typically means you need to do well on 6 of 9 assignments, and OK on the exams. It is much better to do 6 assignments reasonably well than to do more assignments poorly. ======================================================== E-mail Help: Because this is not a large course with many instructors, it is not possible to have an instructor in the terminal room ready to answer questions as frequently as we would like. But you can often get a useful answer by sending a question via e-mail to lib51 which is a mailing list that includes the instructor, assistant instructor, and grader. When you send e-mail questions to instructors, it is a good idea to include your code file at the end of your message (e.g. after your signature). Please do NOT include files in MIME format in e-mail messages to instructors. Not all instructors use mailers that can understand this format. ======================================================== Solutions: When you get a graded assignment back, you will get a solution with it. You may NOT show or discuss this solution with any student who has not gotten their assignment back. You also MUST NOT look at solutions from previous teachings of this course; and you must see to it that your solutions are not shown to students who might take this course later. ======================================================== Multiple submissions: If you run `make submit' more than once, only the last submission is graded, if all submissions are before the deadline. If you submit for a second time AFTER the deadline, you MUST e-mail the instructors at lib51, or else the second submission may not be the one graded. Furthermore, if you submit a second time after the first assignment has been graded, the second submission will not be graded. The best way to forestall this difficulty is to inform lib51 by e-mail that a second submission is coming very soon after the first submission. These rules do not apply when an instructor asks you to fix some things in an assignment and resubmit. ======================================================== Collaboration Rules: You may NOT write code, design documentation, or problem solutions together. You may NOT copy code, documenta- tion, or problem solutions written by another person. There are a number of exceptions to the above rule, mostly for code. In all cases, the result should be that your code is essentially different than that of any other person. The purpose of the exceptions is to be sure that students do not get stuck for very long. Because preparing lectures and grading this course takes a lot of the instructor's time, instructors cannot help students as much as we would like. Therefore in general students should help each other when a student gets stuck. As long as only the information necessary to unstick the stuck student is transmitted, this is good. You may talk freely about assignment CODE, if you do not write anything or read each other's writing while talking. You may ask any question and give any answer, as long as you don't try to proceed in a way that circumvents the injunction against copying written work. You may share single lines of code and design formulas occasionally. The usual context for this is to answer questions such as ``how do I print a space in LISP''. If you are really stuck on a design problem, you may ask another student for a formula to unstick you, but this should not happen often. If you get stuck on a bug, you may ask another student for help, but that other student should have written her/his code already before looking at yours. Bugs can be rated according to how long they take to solve: e.g. a 2 minute bug, a 10 minute bug, a 24 hour bug. After 30 minutes you should definitely go into the help seeking mode. Implied in this is that a student who helps you will read your code, which is why she/he should be finished writing his/her code before looking at yours, though it is OK if the other student has not finished debugging his/her code before trying to help. Problems with learning the programming languages in this course are a special case. You may quickly ask for and give help if the only issue is understanding a programming language feature. This includes trying to understand compiler error messages. Good students are reminded that their value to the world, and to potential employers, depends as much on their ability to help and teach others, as on their ability to do the work themselves. It is definitely permissible to help other students find their bugs when these students are seriously stuck, after you have mostly finished your code and documentation. But you should also feel free to say `no' if being asked to help interferes with your own work, or for any other reason. If you find yourself getting a lot of help on problem sets, you should document this in comments at the beginning of appropriate submitted files. Your TF will figure out what to do, if anything. If the amount of help you are getting is appropriate for the grades you are getting, and it should be if you are honestly trying to learn, then the TF will typically do nothing. You may NOT discuss theory problem solutions or design documentation with other students. But you may freely discuss lecture examples and textbook problems that have NOT been assigned. ======================================================== Honesty: If you are an employee of a company and are dishonest in a way that costs the company money, you are likely to be fired. Universities will not graduate students who might do this, and therefore any similar behavior in a course results in administrative action against the student. The purpose of the administrative action is to ensure that the student has `reformed' before the student is permitted to continue at the university, and this often means at least a leave of absence (temporary expulsion). Universities are not like high schools in this respect. Universities must maintain their reputation with employers, and are under no obligation to keep students who are dishonest. In companies unfortunate things happen occasionally, and do not by themselves constitute dishonesty. Dishonesty is NOT informing your boss when something unfortunate happens. Courses are run similarly. If you violate any course rule in a way that might affect a grade, you MUST inform your TF in writing (usually by comments at the head of a submitted file, and sometimes by e-mail). Violating the rule does NOT constitute dishonesty: rules may be violated due to ignorance or carelessness or impracticability of the rule in some situation. What constitutes dishonesty is NOT reporting the violation. If you report the violation the TF will deal with it, e.g. by adjusting grades appropriately. ======================================================== Computer Security: Any professional programmer can break into your account IF she/he has physical access to your terminal. Therefore, within an organization, like a company or a university, computer security requires honorable behavior. Dishonorable behavior in this respect is treated like dishonesty: if it causes injury, and violating privacy is often injurious to the party whose privacy is violated, then it is a very serious manner which will get you fired from a company or forced to withdraw from a university.