Collaboration and Sharing
In line with MIT’s policy on Academic Integrity, here are our expectations regarding collaboration and sharing of work.
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.
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 laptop while you’re helping.
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, or problem sets), without need for attribution. Staff-provided code may not be publicly shared without permission, however, as discussed later in this document.
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 Java library, she mentions it to Ben. When Ben finds a StackOverflow answer that helps, he sends the URL to Alyssa. OK.
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 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. INAPPROPRIATE.
John and Ellen both worked on their problem sets separately. They exchange their test cases with each other to check their work. INAPPROPRIATE. 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.
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 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.
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 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 solutions publicly. This means you cannot post them on GitHub, in a public Dropbox folder, or on a public server accessible to others.
For group projects, before you can post any code for public distribution, all authors of the code must agree to public distribution, and their authorship must be acknowledged.
Acknowledged means the names of all authors appear either in a comment at the top of each source file, or in a
README.md(or other prominent README file) at the root of the project. If you’re posting on a site like GitHub, keep the commit history – and for projects that use code from a previous group, import that code with its commit history. This history demonstrates each person’s individual contribution, and shows off your software development process.
These rules are derived from the standard practice for open-source code projects, in which it’s necessary to clarify the origin of all the code and obtain Contributor License Agreements from all identified contributors. You should follow this standard ethical practice of the software development community even for your own projects. If you want to publish code from a hackathon where you worked with other people, then make sure all the authors agree and are appropriately acknowledged.