CS143 collaboration policy
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
Collaboration on coding projects
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 knowledgeable 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
Basically, 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
- 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.
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 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.