Collaboration in COMPSCI Courses

The Duke Community Standard

Duke University is a community dedicated to scholarship, leadership, and service and to the principles of honesty, fairness, respect, and accountability. Citizens of this community commit to reflect upon and uphold these principles in all academic and non-academic endeavors, and to protect and promote a culture of integrity.

To uphold the Duke Community Standard:

In the Department of Computer Science, we take the Community Standard seriously and expect you to do the same. Students who submit work that is not their own, shortchange not only their own learning but undermine the atmosphere of trust and individual achievement that characterizes Duke's academic community.

The purpose of this page is to make our expectations as clear as possible in the hope that we will reduce the number of Community Standard violations that occur. The basic principle under which we operate is that each of you is expected to submit your own work in this course. Attempting to take credit for someone else's work by turning it in as your own constitutes plagiarism, which is a serious violation of basic academic standards.

General Coursework

We encourage collaboration on much of the work you'll do in your computer science courses. However, in some situations, e.g., exams, your work must be done by yourself, consulting only those resources explicitly permitted by your instructor.

Studying together is always encouraged, especially when preparing for quizzes, tests, and final exams. At other times you may be assigned to a group, e.g., for labs or group programming assignments.

If you aren't sure what the collaboration policy is on a lab, classwork, programming project, or other assignment, please ask!

Programming Assignments

Programming assignments can be time consuming and challenging, but completing them on your own is an essential part of introductory computer science courses. On programming projects and APTs, you may consult with professors and TAs/UTAs about any aspect of the assignment. We strongly encourage you to seek such assistance when you need it. You can post questions to the Piazza, and we encourage you to answer questions posted by other students. Please do not provide answers that essentially give away the entire assignment.

You may consult with other students only in a general way, e.g., about debugging or Java/language issues, or questions about wording on the assignment. You cannot actively work with someone unless the assignment specifically grants permission for you to work together with someone else in the class. Consult means you can discuss the programs before writing code and assist each other in debugging your programs, but you should write your own code.

The general policy for programming assignments can be described with the following rules.

Rule 1: You must submit a REFLECT (formerly called a README) with every programming submission where you indicate any assistance you received. If you make use of such assistance without giving proper credit, you may be guilty of academic dishonesty.

For each assignment you are expected to include a list of the people with whom you have consulted (including students, TAs, UTAs, tutors, professors) and resources used (including webpages and source code repositories) as part of your submission. This information is required with each assignment. It is part of your REFLECT file, and failure to provide it will result in rejection of the assignment as complete.

In addition to providing proper citation in your REFLECT, it is also important to make sure that the assistance you receive consists of general advice that does not cross the boundary into having someone else write the actual code. It is fine to discuss ideas and strategies, but you should be careful to write your programs on your own.

Rule 2: You must not share actual program code with other students.

In particular, you should not ask anyone to give you a copy of their code or, conversely, give your code to another student who asks you for it. Similarly, you should not discuss your algorithmic strategies to such an extent that you and your collaborators end up turning in exactly the same code. Discuss ideas together, but do the coding on your own.

The prohibition against looking at the actual code for a program has an important specific application in computer science courses. Developing a good programming assignment often takes years. When a new assignment is created, it invariably has problems that require a certain amount of polishing. To make sure that the assignments are as good as they can be, Duke, like most other CS departments, reuses assignments over the years, incorporating a few changes periodically to make them more effective. This reuse helps TAs understand the assignment, builds community, and reflects the idea that a good assignment may stand a "test of time".

Rule 3: You must not look at solution sets or program code from other semesters.

Beyond being a clear violation of academic integrity, making use of old solution sets is a dangerous practice. Assignments can change in a variety of ways from year to year as we seek to make them better. Submitting a program that solves last year's assignment perfectly while failing to solve the current one is particularly damaging evidence of academic dishonesty.

Whenever you seek help on an assignment, your goal should be improving your level of understanding and not simply getting your program to work. Suppose, for example, that someone responds to your request for help by showing you a couple of lines of code that do the job. Don't fall into the trap of thinking about that code as if it were a magical incantation - something you simply include in your program and do not have to understand. By doing so, you will be in no position to solve similar problems on exams. The need to understand the assistance you receive can be expressed in the following rule:

Rule 4: You must be prepared to explain any program code you submit.

Although you should certainly keep these rules in mind, it is important to recognize that the cases that we bring forward to Undergraduate Conduct Board are not those in which a student simply forgets to cite a source of legitimate aid. In many cases, students take deliberate measures: rewriting comments, changing variable names, and so forth, to disguise the fact that their work is copied from someone else. Despite such cosmetic changes, it is easy to determine that copying has occurred. Programming style is highly idiosyncratic, and the chance that two submissions would be the same except for variable names and comments is vanishingly small.

We have no desire to create a climate in which students feel as if they are under suspicion. The entire point of the Community Standard is that we all benefit from working in an atmosphere of mutual trust. Students who deliberately take advantage of that trust, however, poison that atmosphere for everyone. As members of the Duke community, we have a responsibility to protect academic integrity for the benefit of the community as a whole.

Rule 5: Cite any code or ideas you use.
If you use code or ideas you've found online or from another person, e.g., as part of finding the answer to a question about how to do something in Java, you must cite your source(s). This includes commenting your code and providing the source within the code you submit. Failing to cite code or resources you've used is a potential violation of the Community Standard.
Rule 6: All submissions are subject to automated plagiarism detection.
We employ powerful automated plagiarism detection tools that compare assignment submissions with other submissions from the current and previous semester. These tools are amazingly effective at detecting unusual resemblances in programs, which are then further examined by the course staff. Submissions deemed to be potential cases of academic dishonesty are referred to the Office of Student Conduct. We really hope it doesn't come to that, but, sadly, all this discussion would not be necessary if we had not had such problems in the past.

Other Resources