Collaboration Policy

Collaborating with other students is an important part of a rich and rewarding learning experience. However, Brown's academic code requires that we evaluate you based on your own work:

"Academic achievement is evaluated on the basis of work that a student produces independently. A student who obtains credit for work, words, or ideas that are not the products of his or her own effort is dishonest and in violation of Brown's Academic Code."

- The Academic Code

Our collaboration policy aims to strike a reasonable balance between appropriate collaboration and rigorous independent work. Guidelines for different parts of the course are listed below.

Labs

You are encouraged to work together with others on labs and to help each other debug them.

You are welcome to discuss the requirements of, and any high-level design strategies for, your projects. If you do discuss these with other students, you should not discuss any specifics about code, nor any pseudocode.

Please note the CS logins of each student you collaborated with in your project README.

All code you write must be your own. You should not use or refer to code written by another student (with or without their consent) nor code you found online (in a Github repository or Stack Overflow post, or from a previous offering of the course, etc). The only scenario in which it is acceptable to look at another student's code is when helping that student debug that code during TA hours; see the TA Hours section below for more details.

On the opposite side of the same coin, you should not share your own code with other students (including by making it accessible on a public forum like Ed, a public online repository, or your CS home directory with insufficient permissions).

Final Project

Because the final project can be big and open-ended, there may be cases where it makes sense for you to make use of third-party software/libraries. If you think this is necessary and appropriate for your project, please check with your mentor TA. If they approve it, then be sure to cite the software/library in your final project submission.

Regarding collaboration between teams, please abide by our policy for projects above.

TA Hours

In recognition of the long queues that can form during TA hours, we run hours a little differently in this course. Rather than structuring hours as TAs helping individual students in sequence, we instead structure each hours session as a community help space, where students can help each other under the supervision of the TAs. We permit (and encourage!) students to help each other work through conceptual issues, to discuss project design and organization, and even to help each other debug code. In fact, if you're particularly helpful to hours during hours, we'll take this into account when we compute final grades.

However, the policy from the Projects: Code section above still applies: all code you write must be your own. TAs in hours will be on the lookout for inappropriate code sharing/copying and will report any violations to the instructor. For example: while you can look at another student's buggy code to help them debug it, you should not show them your own (functioning) code as an example of how to fix it.

Ed

You are welcome to ask for help from other students (and TAs) on Ed, provided you have already tried your best to solve the problem on your own. All Ed posts asking for help in resolving an issue must include a description of the steps you have already tried to solve the problem.

In private posts, visible only to yourself and TAs, it is fine to share images, videos, and code.

In public posts, you may post images/videos of your program's output, but do not include any code (even pseudocode). This applies also to when you are responding to a public post.

ChatGPT, Github Copilot, etc.

Thus far, this document has addressed permissible forms of collaboration with people; however, we would be remiss not to address the growing trend of collaboration with machines in order to write code---specifically, large language models (LLMs) such as ChatGPT and Github Copilot. We believe that it is foolish to forbid the use of such tools, because (a) it is not possible to reliably detect when code has been (partially) written by an LLM, (b) these tools can be genuinely helpful and will be a part of the software development landscape for the foreseeable future, and (c) it is important for students to understand the limitations of these tools and to be appropriately skeptical of their output.

Thus, you are welcome to use LLM-based code generation tools to help you write code for your projects. In particular, you may find them useful for writing so-called "boilerplate" code, e.g. the many lines of code required to set up an empty OpenGL program that does nothing. If you choose to use such tools, keep the following in mind:

You must disclose that you used the tool, and how you used it, in your project README (just as you would if you collaborated with another student).
Do not use generated code that you do not understand. It may well be incorrect, and if you don't understand it, how will you debug it? Note that TAs will not spend time in hours helping you understand or debug code that you did not write yourself. Also, during your mentor meetings, your TA will ask you to explain how your code works; if you can't do that, you'll be in violation of this collaboration policy (see below).

Violations of this policy

We take this collaboration policy very seriously. All project code submissions will be run through MOSS, a sophisticated code similarity program designed to detect software plagiarism. During mentor meetings, your mentor TA will check that the code you submitted can reproduce the result images/videos you submitted, and they'll also ask you to explain how your code works. Consequences for violating the collaboration policy range from receiving a zero on the assignment in question to having the case referred to the university Academic Code Committee (which can result in an NC grade for the class and a note on your transcript).