Collaboration and Sharing

In line with MIT’s policy on Academic Integrity, here are our expectations regarding collaboration and sharing of work.

Collaboration

We encourage you to help each other with work in this class, but there are limits to what you can do, to ensure that everybody has a good individual learning experience. This section describes those limits.

The following table provides a brief summary of the policy, and the following sections provide more explanation and examples.

Activity	OK?	Details
Help from this semester’s 6.031 staff	YES	Encouraged; there are many ways to get help from trained staff members. You may make use of any help our staff give you (one-on-one, on Piazza, or material on the course web site).
Collaboration with current 6.031 students	MAYBE	Encouraged for high-level discussion only; forbidden for code-level communication. This one gets subtle, please consult the complete policy below.
Help from tutors through MIT programs (e.g. HKN)	MAYBE	Allowed, according to the same rules as collaboration with current 6.031 students. Please make sure your tutor has read and understand these policies as well.
Help from anyone who is not current 6.031 staff or student	NO	Forbidden! Please ask the instructors for permission to get any kind of help from such a person. They often aren’t trained in how to help effectively and might really “do most of the work for you.”
Consulting code you didn’t write yourself	MAYBE	Forbidden if the code was written in the context of 6.031, except for code distributed by the staff this semester. Any external code used must be properly attributed in your solution.
Sharing code that you have written	NO	Forbidden in any format, including through public code repositories like GitHub or GitLab.

Individual work

Problem sets in this class are intended to be primarily individual efforts.

You may not use materials produced as course work by other students, whether in this term or previous terms, nor may you provide work for other students to use.

You are encouraged to discuss approaches with other students, but these discussions must not involve step-by-step, algorithmic instructions in either written or spoken form, and your code and your write-up must be your own. Literal code is the most obvious example of a form of communication that is not allowed between students, but this policy also disallows communicating in “pseudocode,” which mixes programming syntax with fuzzier bits of natural language. Pseudocode gives away too much of the algorithmic formulation that we want you to figure out for yourself on each assignment. A consequence is that, within a group of students collaborating or having some help others, no one may be looking at any code (including pseudocode) they wrote for 6.031.

It’s good to help other students. But as a general rule, during the time that you are helping another student, your own solution should not be visible, either to you or to them. Make a habit of closing your code while you’re helping.

During code review, you will see classmates’ solutions to a problem set. While it is fine to take inspiration from their approach, do not copy their work.

It’s fine to use material from external sources like StackOverflow, but only with proper attribution, and only if the assignment allows it. In particular, if the assignment says “implement X,” then you must create your own X, not reuse one from an external source.

It’s also fine to use any code provided by this semester’s 6.031 staff (in class, readings, problem sets, or projects), without need for attribution. Staff-provided code may not be publicly shared without permission, however, as discussed later in this document.

It’s also fine to use anything that is built-in to JavaScript or TypeScript or included in the Node standard library. (Previous courses like 6.009 sometimes restrict importing from the standard library; 6.031 does not.) But you should not use npm install to add an arbitrary JavaScript or TypeScript library from the npm package repository. If you do, your code will not compile on Didit.

Examples

Alyssa and Ben sit next to each other with their laptops while working on a problem set. They talk in general terms about different approaches to doing the problem set. They draw diagrams on the whiteboard. When Alyssa discovers a useful class in the JavaScript library, she mentions it to Ben. When Ben finds a StackOverflow answer that helps, he sends the URL to Alyssa. OK.
- As they look at their code, they speak specifically about the steps the code takes to solve the problem, to make sure both people have the right working solution. FORBIDDEN.
- In a tricky part of the problem set, Alyssa looks at Ben’s screen to make sure her code is right. Ben is sitting on the other side of the table, so Alyssa goes back and forth between her laptop and looking over Ben’s shoulder, but never has both screens in view at the same time. FORBIDDEN.
Jerry already finished the problem set, but his friend Ben is now struggling with a nasty bug. Jerry sits next to Ben, looks at his code, and helps him debug. OK.
- Jerry opens his own laptop, finds his solution to the problem set, and refers to it occasionally while he’s helping Ben find the bugs in his code. FORBIDDEN.
Louis had three problem sets and two quizzes this week, was away from campus for several days for a track meet, and then got sick. He’s already taken two slack days on the deadline and has made almost no progress on the problem set. Ben feels sorry for Louis and wants to help, so he sits down with Louis and talks with him about how to do the problem set while Louis is working on it. Ben already handed in his own solution, but he doesn’t open his own laptop to look at it while he’s helping Louis. OK.
- Ben opens his laptop and reads his own code while he’s helping Louis. FORBIDDEN.
- Ben has by now spent a couple hours with Louis, and Louis still needs help, but Ben really needs to get back to his own work. He puts his code in a Dropbox and shares it with Louis, after Louis promises only to look at it when he really has to. FORBIDDEN.
John and Ellen both worked on their problem sets separately. They exchange their test cases with each other to check their work. FORBIDDEN. Test cases are part of the material for the problem set, and part of the learning experience of the course. You are copying if you use somebody else’s test cases, even if temporarily.

Note that in the examples marked inappropriate above, both people are held responsible for the violation in academic honesty. Copying work, or knowingly making work available for copying, in contravention of this policy is a serious offense that may incur reduced grades, failing the course, and disciplinary action. Copying, or helping somebody copy, may result in an F on your transcript that you will not be able to drop.

This policy applies to all coursework that is handed in by an individual: problem sets, reading exercises, nanoquiz makeups, etc.

Group work

You should collaborate with your partners on all aspects of group project work and in-class collaborative exercises, and each of you is expected to contribute a roughly equal share to design and implementation.

You may reuse designs, ideas and code from your own work earlier in the semester. You may also use any code provided by this semester’s 6.031 staff.

You may also use material from external sources, so long as: (1) the material is available to all students in the class; (2) you give proper attribution; and (3) the assignment itself allows it. In particular, if the assignment says “implement X,” then you must create your own X, not reuse someone else’s.

Finally, your group may not reuse designs, ideas, or code created by another group, in this semester or previous semesters.

No public sharing

People often want to share their code publicly, e.g., on GitHub, in order to show off a portfolio of code they’ve written to potential employers. Building a portfolio is a great idea, but 6.031 is not a good class to use for it, because the problem sets and projects are fixed by the course staff, not chosen by you. Personal projects, hackathons, and IAP contests are much better ways to build up your portfolio.

Copyright for the starter problem set and project code is held by the 6.031 course staff, and does not allow redistribution of derived works without prior permission. Your solutions are a derived work, so you may not distribute your problem set or project solutions publicly. This means you cannot post them in a public Dropbox folder, on a public server accessible to others, or on GitHub. (Be aware that GitHub repositories are public by default.)

Keep in mind that when work on a problem set or project is copied, both the provider and the consumer of copied materials are violating academic honesty standards, as described above.