EEC 281 Collaboration Policy
There is a fine line between working together and copying. Working with
others, asking questions, and explaining concepts are important steps
in the learning process and are strongly encouraged. Copying someone
else's work or allowing your work to be copied does not promote learning,
is unfair to others, and is not allowed in this course.
The remainder of this document attempts to make the separation between
encouraged collaboration and unpermitted collaboration as clear as possible.
If in doubt, play it safe and ask the instructor first!
These things are encouraged and are allowed at all times.
- Discussing material covered in lecture, or the readings.
- Discussing the requirements of an assignment.
- Discussing features of the languages, tools, and libraries used in the
- Discussing general concepts of designing, coding, or
debugging. Encouraged example statements/exchanges include,
- "It worked well to test each module
independently before assembling the whole system"
- "When something doesn't work right, first look at all input signals
in the waveform viewer."
- "What should I do when I get a '(UID-4)' error?"
"Check if your module is located in a file of the same name."
- "Why doesn't matlab let me use an index of 0 in an array?"
- Any discussion between you and the instructor. You
are welcome to discuss any and all ideas, design, code, debugging,
and details with the instructor.
Permitted collaboration, but only if documented
When you engage in more detailed discussions of assignments, you
must include the name of the person(s) who assisted you and properly
credit their contribution to your work. This is akin to acknowledging
a reference in a research paper.
These cases include:
- Discussing more detailed concepts of designing, coding, or
- Some example exchanges requiring citation are:
- "I can't get test cases with a negative input to work."
"Did you check the sign extension of the subtracted input?"
- "My design for the viterbi block is enormous!"
"Did you take advantage of the timing requirements and time-multiplex
your ACS processor?"
The overall guideline for unpermitted collaboration is that you must
submit work which represents your original, independent effort. It should
not be based on, influenced by, or copied from anyone else's work--including
people not enrolled in the course.
- Copying code.
This is the most blatant violation. You should not
be writing down anyone else's work, or allowing anyone else to write
down your work.
- Using work from past quarters. Using someone's work or solutions
from a previous quarter is an obvious violation.
- Looking at someone else's work. You should never read anyone else's
work before yours is submitted, whether it is on the screen or written
out by hand.
- Debugging with another person. Working at the same computer as
someone and trying to fix a bug is not allowed. It makes it too easy
to look over someone else's code, and allows (sometimes unintended)
code-copying. Describing to someone your problem and asking for advice
on how to fix it is okay, but you should do the actual debugging yourself.
- Copying someone else's high-level design.
Discussing high-level design with someone
else and sharing ideas and critiquing each other's design is okay if
attributed. However, just taking someone else's design
is not allowed. It is akin to taking someone else's
outline for a research paper and basing your paper on that.
- Discussing assignments in such detail that you duplicate a portion
of someone else's work in your own design.
This policy is based on the collaboration policy for CS 106X at Stanford.
Last update: March 7, 2005