Brown University has an Academic Code that governs all our transactions. This code includes a section on Respect for the Integrity of the Academic Process, which establishes its policy on cheating. We expect that you, as students and scholars, will abide by this faithfully and fully.
Please see the HTAs or the professor if you have any questions or concerns with the content of this document.
You may discuss any assignment with other students in the class. However, you are not allowed to take away any written psuedocode or code from joint work sessions (unless these are with your designated partner/group). Emails, IM conversations, and the like should follow this policy as well: they may contain high-level conceptual discussion, but not psuedocode or code. Importantly, after participating in a joint work session, you must take a short break and erase the whiteboard (if you used one) before writing up your solutions.
CS32 contains one individual project that you should primarily work on alone. However, you are welcome to ask for conceptual and debugging help from TAs and other students in the class. You should document any help you receive from peers, TAs, and otherwise in your README.
Ex. “I received debugging assistance from Tim.”
We expect you to fully comprehend everything you hand in. To that end, you must code your solutions entirely on your own. You are permitted to work together on debugging, and may look at someone's code or work together to modify code for the purpose of helping him/her debug, as long as your code is not open concurrently. However, do not feel you need to debug students’ code if a student should ask! Just know it is permitted. You are also permitted to collaborate conceptually (with no computers) with other students in the class. However, you are responsible for writing up and fixing all code that results of these debugging and conceptual discussion processes.
Two assignments will be designed for pair work. During these assignments, you will work collaboratively with your partner on a single codebase. All of the collaboration policies that apply to individual projects apply to pair projects as well, though you may share pseudocode and code with your project partner.
Pair programming should not be done using a divide-and-conquer approach. We want all students to fully understand all portions of every assignment. When we are grading, we expect both students to be able to answer what each part of the program does and how it works. We don't expect you to be programming together all the time, but it should be done most of the time.
The final project is designated as group work. You may fully collaborate and divide the work among group members. This will require more extensive communication between group members, and you will have to do extra work to ensure that all group members can access your project's code. In addition, it is allowed to speak with members of other groups to share helpful tips and resources and solicit debugging help.
External Contacts and Outside Resources
Collaboration with people who are not currently affiliated with CS 32, including those who have previously taken or TA'd CS 32 but are not currently on staff, is not allowed.
You may use Internet resources for reference. However, you are forbidden from posting questions to external mailing lists/forums like StackOverflow. You should not copy code from the Internet, but you may search for and take inspiration from blog posts, StackOverflow, etc. If you are ever in doubt, just go to TA hours or post on Piazza.
We use Piazza for CS 32, and it is expected that you check Piazza regularly for clarifications and course announcements. You are responsible for anything posted on Piazza by the course staff, such as clarifications or tips. Our Piazza can be found here.
You can also post questions on Piazza. Please ensure that any questions you post do not reveal your answers, and do not publicly post any code on Piazza. If a TA would like to see your code on Piazza or you have a question about your code, either go to TA hours or make your post private. Your default for posting on Piazza should be public. You should only be posting more than three lines of code if you have seen a TA at hours who could not help you.
As you are aware, the TAs will be grading your programs by running the program you submit using their permissions. This means that you could potentially write malicious code that could cause problems for the TAs or some other students the TAs may be grading. If we ever find a case where malicious code was written on purpose and handed in, that would be cause for a failing grade and a dean will be notified to take further action.
File Permissions and Printouts
You are responsible for keeping your files private by setting the appropriate protections. Students are held equally responsible regardless of who provided code or left files accessible and who prohibited assistance. Please note that your Github repositories should always remain private, even after you have completed the course. You may make your final project public after the course has ended.
We use a program called Measures of Software Similarity, or MOSS, to analyze all hand-ins and detect potential violations of the collaboration policy. The code you hand in will be uploaded to the MOSS server (which is hosted at Stanford) and compared structurally against others' code. MOSS is extremely robust; renaming things and even moving things around will not work. In addition, we feed previous year's handins to MOSS, as well as various code we find online.
Exceptions may be possible, at the professor's sole discretion, only if you admit your violation to Tim (not a TA) within 24 hours after the assignment deadline. This gives you an option if you cheated in desperation the night an assignment was due, allowed someone to copy your code, etc. and then regretted it soon afterward. (The University may still be involved in such cases.)
Please contact email@example.com if you do not have a CS login.