Collaboration policy

CS143 collaboration policy

General philosophy

We are confident that all of you have come to Stanford planning to respect and uphold the Honor Code. We would like to define what is and what isn't considered acceptable collaboration, so there is no ambiguity. The general premise of our policy is that your submissions must be your own independent and original work. You should not give or receive any aid which makes the assigned tasks significantly easier. We do allow for discussion and help among students, but expect you to document any significant help that you receive. On our part, we will treat you with trust and will protect the honorable student's interests by investigating and prosecuting dishonorable behavior.

Collaboration on coding projects

"Your code is like your boyfriend or girlfriend. It's okay to talk about it on an abstract, high level. But you don't want to go into the specific details, and you certainly don't want to share."

- Pascal Van Hentenryck, Professor of CS, Brown University, 1997

For the purposes of the collaboration policy, students choosing to work with a partner are effectively considered as one entity, and are freely allowed to exchange, help, design, and code with one other, but the guidelines below apply outside the partnership (neither of you should be debugging, sharing code, etc. with other people or teams). There are also some specific rules that apply within the partnership.

Things that are always allowed

These things are encouraged and allowed at all times for all students.

Discussing material covered in lecture or handouts.
Discussing the requirements of an assignment.
Discussing features of any programming language (including the one for which we are writing a compiler).
Discussing how to use the tools or development environments.
Discussing general techniques of coding or debugging.
Any discussion between the student and a TA. You are welcome to discuss any and all ideas, design, code, debugging, and details with the course staff. They are the best folks to talk to because they are knowledgable about all the material and know how to help you without giving away the farm. They also have the authority to give you definitive answers to your questions.

Collaboration that is allowed if documented

Two students engaging in a more detailed discussion of the project specifics can cross into the area of collaboration that is acceptable only if documented. We require that you include the name of those whom you received specific assistance from and properly credit their contribution, as you would cite a reference in a research paper. This documentation should be in the README file for the assignment, NOT within the source code. Some examples of valid documented collaboration:

Discussing the design of the project. Design is a crucial part of the programming process, and discussion can be valuable, but you should take care to document any design input you got from others.
Helping another student debug their code. In general, we prefer that you get this sort of help from the TAs, but if you do get detailed debugging advice from someone, you should credit their assistance.
Sharing advice about testing. For example, if the team next to you tells you about some lesson learned ("our program didn't handle the case where the input file didn't end with a newline") that you then use to improve your program's robustness, you should credit them for providing you with that insight.

Collaboration that is NOT allowed

Bascially, the rule is that you should be handing in code which represents your original, independent work. It should not be based on, influenced by, or copied from anyone else's.

Copying code. This is the most blatant violation. You should not be copying anyone else's work. You should also not allow anyone else to copy yours. You should keep your work secure (restrict access on the filesystem, don't leave printouts lying around, etc.)
Using work from past quarters. Using someone's work or solutions from a previous quarter is an obvious violation. If you are re-taking CS143 and want to re-use your previous work, you must tell us this to avoid coming under suspicion for using work that came from a previous quarter.
Studying someone else's code. You should not be reading anyone else's code whether it is on the screen or written out by hand.
Debugging someone else's code. Debugging along with someone makes it too easy to look over their code and allow (sometimes unintended) code-copying. Describing to someone a problem and asking for advice on how to track it down is okay, but you should do the actual debugging yourself.

Guidelines that specifically apply to programming partners

You can freely exchange ideas and assistance within the partnership, but outside it, the same rules apply (your or your partner should not be sharing code with others, etc.). A few special rules regarding partnerships:

Partnership is equal.We assume that both students will contribute roughly equally to the creation of each program. If you find that one partner is doing most or all of the work, you should end the partnership. Both partners are responsible for understanding and being able to explain the entire submission.
Partnership is monogamous. You may work with at most one partner for the duration of any one assignment. If you start the assignment with a partner, you can either finish with that partner or separate into two individuals (each should note on their submission that part that was jointly conceived), but you cannot switch to another partner to finish that assignment. Two individuals who started on a project independently can join up to finish the project as long as they did not work with anyone else during that project. You are welcome to switch partners between assignments or do some assignments with a partner and others alone.

Collaboration on problem sets

The policy described above for programming projects gives you a good idea of our general philosophy about collaboration and how the Honor Code applies in this course. For the problem sets, we have similar expectations about academic integrity but there are some differences in the ground rules:

The problem sets must be completed individually (you cannot hand in a joint solution with a partner).
We strongly encourage you to discuss and work the problems with other students. A group of two or three probably is best, any larger and it can be hard for all people to participate effectively. It is allowed to sit down and work through the problems on scratch paper or a blackboard. Set the goal of the joint work to be that everyone participating fully understands the concepts and techniques being used to solve the problem. Teach and learn from each other!
When the time comes to write up the solutions, the group should separate and without referring to the jointly conceived notes each student must write up their own solution to hand in. The requirement about not referring to/copying the joint work is to ensure that each of you completely understands the material and is able to independently generate a solution from your own understanding. You'll need this skill for exams, too!
Your submitted solution should credit any student with whom you worked/discussed problems.
A good rule of thumb is that you must be able to explain and duplicate all the steps in any work you submit.

Closing thoughts

Above all you should use your common sense. If you suspect that what you are about to do is a violation, play it safe and ask a staff member first rather than take risks with your academic career.

The Honor Code is taken very seriously in this course and we have no tolerance for behavior that falls outside our boundaries for acceptable conduct. Please do your part in maintaining a community where academic work is done with a high standard of integrity!

Some parts of this document are based on a similar collaboration policy for Brown's CS courses.