CS 61B: Collaboration Policy

Fall 2014

Deadlines can be stressful, and we know that under extreme pressure, it becomes tempting to start rationalizing actions that you would otherwise yourself consider inappropriate. Perhaps you'll find yourself facing a 61B project deadline, and under all this stress you'll convince yourself that you're just going to cheat for the moment so you can get the points, and that you'll come back later and really learn the thing you were supposed to have learned in order to restore your karmic balance (I've heard something along these lines a few times).

This is a terrible idea. Obviously it's important to learn how to deal with deadlines, but far more important than that, giving into this sort of pressure under not-so-dire circumstances is going to do some damage to your moral compass. Someday, when the consequences are higher than potentially losing a 1/3rd of a letter grade, you may find yourself committing dishonest acts at the cost of someone else's livelihood or life.

In CS61B, we have three types of assignments: Homeworks, labs, and projects. The entire point of homeworks and labs is to learn. You should feel free to collaborate with others, though keep in mind that greater independence is likely to give you a better learning experience (as long as you aren't totally stuck).

By contrast, the projects were designed for learning (particularly how to be self-reliant in the context of large unfamiliar systems), as well as for the dual purpose of evaluating of your mastery of the course material. As such, they are intended to be completed primarily on your own, particularly when it comes to writing the actual code.

Cheating on a project will earn you a negative score for that project, i.e. if a project is worth 127 points of your course grade, you will instead lose 127 points from your final point total. Cheating a second time or on an exam will earn you an F in the course. All incidents of cheating will be referred to the Office of Student Conduct.

What constitutes cheating? The golden rule of academic dishonesty is that you should not claim to be responsible for work that is not yours.

This is obviously open to some interpretation, and you'll be getting some help from instructors, the internet, other students, and more throughout the course. This is OK, and we hope that the class is an open, welcoming, collaborative environment where we can help each other build the highest possible understanding of the course material.

To help (but not entirely define) the bounds of acceptable behavior, we have three important rules for projects:

1. By You Alone: All project code that you submit (other than skeleton code) should be written by you alone, except for small snippets that solve tiny subproblems (examples in the Permitted section below).

2. Do Not Possess or Share Code: Before a project deadline, you should never be in possession of solution code that you did not write. You will be equally culpable if you distribute such code to other students or future students of 61B (within reason). DO NOT GIVE ANYONE YOUR CODE -- EVEN IF THEY ARE DESPERATELY ASKING. DO NOT POST SOLUTIONS TO PROJECTS ONLINE (on github or anywhere else)! If you're not sure what you're doing is OK, please ask.

3. Cite Your Sources: When you receive significant assistance on a project from someone else, you should cite that assistance somewhere in your source code. We leave it to you to decide what constitutes 'significant'.

For clarity, examples of specific activities are listed below:

Permitted: . Discussion of approaches for solving a problem. . Giving away or receiving significant ideas towards a problem solution. Such help should be cited as comments in your code. . Discussion of specific syntax issues and bugs in your code. . Using small snippets of code that you find online for solving tiny problems (e.g. googling "uppercase string java" may lead you to some sample code that you copy and paste into your solution). Such usages should be cited as comments in your hw, lab, and especially project code!

Permitted with Extreme Caution: . Looking at someone else's project code to assist with debugging. Typing or dictacting code into someone else's computer is a violation of the "By You Alone" rule. . Looking at someone else's project code to understand a particular idea or part of a project. This is strongly discouraged due to the danger of plagiarism, but not absolutely forbidden. We are very serious about the "By You Alone" rule!

Absolutely Forbidden: . Possessing another student's project code in any form before a final deadline, be it electronic or on paper. This includes the situation where you're trying to help someone debug. Distributing such code is equally forbidden. . Possessing project solution code that you did not write yourself (from online (e.g. github), staff solution code found somewhere on a server it should not have been, etc.) before a final deadline. Distributing such code is equally forbidden.

We have advanced cheating detection software, and we will routinely run this code to detect cheating. Every semester, we catch and penalize a significant number of people. Do not be one of them. If you find yourself at such a point of total desperation that cheating begins to look attractive, contact one of the instructors and we can maybe help somehow. Likewise, if 61B is causing massive disruption to your personal life, please contact us directly.

Submissions that are someone else's work, but which are appropriately cited, will be given zero points (as opposed to a negative score and a referral to the administration).

Obviously, the expressive power of Java is a subset of the English language. And yes, you can obviously obey the letter of this entire policy while completely violating its spirit. However, this policy is not a game to be defeated, and such circumventions will be seen as plagiarism.

The above rules apply for projects. When it comes to HW and labs, you should strive to do as much as you can alone, but it is OK to work with others (even sharing code, although we recommend that you do this very sparingly) if you feel that you'll learn better that way. Nonetheless, you should not submit other student's HW or lab code as your own, and identical or near identical submissions will be treated as plagiarism. Though we have not enumerated a specific penalty for plagiarising HW and labs in this document, we reserve the right to enact an appropriate penalty from the departmental policy on academic dishonesty.