This document lays out my policies on what I expect of my students with respect to collaboration and citation---in other words, how to avoid honor charges of "academic cheating" or "plagiarism". The policy itself I've tried to keep short, but after the policy I give a number of examples to illustrate its application. It is broadly similar to the policies of other professors in this department BUT this document is NOT a department policy, and promises made here may not apply in other professors' classes. --Prof. Blaheta
When you make use of others' work, acknowledge it, and on any assignment where I restrict who you can talk to or what you can look at, observe those restrictions.
Citing sources. Regardless of any other aspect of an assignment or situation, the cardinal rule is to always identify both who you worked with and where you got your material.
If you prefer to think in terms of punishments and consequences, here's a big one: if you use someone else's idea (even if it's not a direct quote) and don't cite it, I will probably take you to the Honor Board for plagiarism and/or cheating.
But more positively: this is your insurance policy. If you always make it clear what ideas, text, or program code were borrowed, and who they were borrowed from, you're being upfront and honest and if there's anything amiss we can handle it with a discussion rather than anything unpleasant.
Observing restrictions. There are three categories that nearly all of my assignments fall into:
| When I say | it means |
|---|---|
| Group work | Sharing is allowed; hand in one copy and put everyone's name on it. |
| Collaborative | Individual handins, but some discussion and sharing is permitted. |
| Non-collaborative | No talking to anyone at all (except me) about any part of the assignment. |
Note that the word collaborative implies input from all parties, including you; if you work with someone (inside or outside the class) that may be fine, but if you get someone else to do it for you, and you use their answer without adaptation or understanding, you're not holding up your end of the bargain.
Including guidelines for three kinds of work (papers, other written work, and programs) and what makes acceptable collaboration.
If the assignment is basically text, whether it's a full-blown paper or just a written description of something, the following guidelines apply.
This is a group paper; work closely with the rest of your group and put everyone's name at the top. (You still need to cite outside ideas; see below.)
You should be writing the paper yourself, but you're encouraged to talk it over with classmates and friends. You should not let them dictate the format and structure of your paper, and you most certainly should not be getting them to contribute any actual text of the paper; but you can bounce ideas off of them, and use their questions to help you focus your thinking about the paper. If in these discussions your fellow student contributes an idea that you end up using in the paper, this should be at least informally cited (perhaps in a footnote).
You're also welcome (and encouraged) to get other people to proofread your work for things like grammar, spelling, and flow. The good people at the Writing Center are great about this, although you can't leave that to the last minute. In general, proofreading assistance doesn't need to be cited, but if they're giving significant help (especially in a longer paper), it's good to put in an acknowledgement somewhere.
No talking to anyone at all (except me) about any part of the assignment. This includes high-level ideas discussions, proofreading, and even "How far have you gotten?" The policy says not to talk to anyone about it; don't talk to anyone about it.
In CS there's a lot of handed-in work that is written (or typed in a word processor) or drawn out by hand, that aren't really "papers" in any meaningful sense, and for which the above list of guidelines doesn't really fit well. These could include program traces, diagrams of memory, E-R diagrams of database schemas, algorithm pseudocode, or many other things. This section tries to address them generally.
This is group work; work closely with the rest of your group and put everyone's name at the top, handing in one final version for the whole group. That doesn't license you to hand all the work to one person, of course; you should balance the workload equitably. (And you still need to cite outside ideas; see below.)
You should be writing/drawing the final work yourself, but you're encouraged to talk it over with classmates and friends. You should not let them give you the answers, and you especially should not copy out what they've written. However, you can definitely discuss the problems with them in detail, to help you understand the problem and to help you understand the path to the solution. If, after talking all of this over with other people, you can write out an answer entirely on your own, you're fine. You should, however, mention who you were working with.
| OK | Not OK |
|---|---|
| You and a couple other students are having a rough time on a problem, so you meet in the Math/CS lounge and bang at the problem on the whiteboard for a while. All of you are clustered around the board with markers in hand, and are contributing to the process (not necessarily equally, but equitably). You have a few "aha!" moments and have collectively worked out more or less the whole problem on the board, and feel like you all understood how you got there. You erase the board, go back to your rooms, and write out your answers (mentioning that you'd worked with the others). | You and a couple other students are having a rough time on a problem, so you meet in the Math/CS lounge and bang at the problem on the whiteboard for a while. One of you writes out the answer on the board while the others watch or give some suggestions; at the end you all copy down the answer onto your paper to hand in. |
There are quite a few problems in the scenario on the right: one person is dominating the process, it's not clear that everyone actually understands the answer that "they" have developed, the answer is copied down rather than phrased/drawn in each student's own words, and no mention is made of the group working together. Real-life situations may involve a bit of grey area, but you should still try to emulate the "OK" scenario as much as possible---and your trump card is that whatever other troubles there might be, if you say who you worked with, you're off the hook for dishonesty or honor violation.
No talking to anyone at all (except me) about any part of the assignment. This includes discussion, answer-checking, and even "How far have you gotten?" The policy says not to talk to anyone about it; don't talk to anyone about it.
Of course, a lot of the assignments you'll turn in for a computer science course are computer programs. It can be difficult to interpret guidelines designed for written assignments to apply to computer programs, so I've written separate program guidelines below.
This is a group project; work closely with the rest of your group and put everyone's name in the readme. To the extent possible, you should identify which team member(s) worked on which part(s) of the project. (And you still need to cite outside ideas; see below.)
You should be writing the program yourself, but you're encouraged to talk it over with classmates and friends. You should not let them tell you in detail how to write the program, and you most certainly should not be copying their code, either in structure or in detail. However, discussion of high-level program design, of the particular data structures and language constructs that might be useful in the program, and of helpful examples, are all fine (and in fact encouraged). If your fellow student(s) put you on the track of a design idea that you end up using in the program, or if you feel like your program design was significantly refined by one of these discussions, you should mention that in a comment or in your readme.
You're also welcome (and encouraged) to give and get help with debugging your programs. Sometimes, debugging help is easy---when someone can just explain what exactly a compiler error really means, for instance, or when someone can just point to a bug and you immediately see how to fix it. That's super for everyone. (The smartest and most experienced programmers still make this kind of bug sometimes.)
It's a little trickier if the bug is more complicated than a simple misplaced semicolon, particularly if the problem is a "conceptual bug", where the code as written reflects a deeper misunderstanding of the problem or of its solution. In this situation, helping is no longer "debugging"---it's either "writing someone's code for them" (which is bad), or it's backing up and "having a high-level discussion about the problem" (which is fine). If you find yourself on either side of this situation, be prepared to set aside the actual program for a moment and talk more generally, or talk about a particular test case, or return to an example from class.
| Very OK | OK | Not OK | Very bad |
|---|---|---|---|
| "You have a fencepost error in line 73." | "Should that semicolon in line 47 be there?" | "Get rid of the while loop and type, 'for, open paren, int, i, equal sign, ...'." |
"Here, give me the keyboard...." |
"The variable foo is never getting initialised." |
"That method probably ought to be virtual." |
"That needs to be a struct, and it needs to be passed in here, and returned there...." | "Let me show you how I did it...." |
"That error message means you forgot a semicolon in your .h file." |
"You need to use a separate counter variable to keep track of this." | ||
| "You're barking up the wrong tree. Let's look at the problem we did in class on Monday...." | "Did you see the program on page 215?" |
As with proofreading, very light debugging help need not be mentioned, but significant help, and especially if they turn into design discussions, should be mentioned in the readme.
Rule of thumb. Don't help debug someone's program if you're in the same course but haven't started that program (or are way behind the other student on the program). If you do, you end up reading their code before you've made your own design decisions, and you can't un-see their code.
Rule of thumb. If you try to point out a bug and keep feeling the urge to explain the other person's bug in terms of your own code, what you're doing has probably moved past "debugging".
No talking to anyone at all (except me) about any part of the program. This includes high-level ideas discussions, debugging, and even "How far have you gotten?" The policy says not to talk to anyone about it; don't talk to anyone about it.
Including guidelines for three kinds of work (papers, other written work, and programs) and how to cite things.
If the assignment is basically text, whether it's a full-blown paper or just a written description of something, the following guidelines apply.
Regardless of the level of personal collaboration allowed, you may be including ideas that are not your own, from outside sources (unless this is prohibited---see the assignment for details).
Exact words. If you decide you need to use someone else's words exactly, put quotes around them and make it clear whose words they are.
Paraphrase. It's better, both for the flow of the paper and to indicate your understanding, if you can rephrase most of the outside material in your own words. You still need to cite it. Since you don't have quotes around these paraphrases, it's a little harder to indicate exactly which ideas are being cited, but as a rule of thumb, a citation will usually be seen to apply to the previous sentence or two. If you are including more than a couple sentences of material from a single source, and you suspect that the reader won't be able to tell what is and isn't yours, do something to make it clear (additional citation, other sources, more restructuring, etc).
Special note about paraphrasing. It is not a paraphrase if you simply use a few synonyms or break up and recombine sentences. You either need to use the exact words (and quote it), or really rewrite it in your own words.
| Exact quote---good. | Pseudo-paraphrase---bad! | Actual paraphrase---good. |
|---|---|---|
| Rather than accepting it as a helpful test of system security, Cliff Stoll likens the virus to "going into a small town and breaking into people's homes, so as to impress upon the townsfolk the need to buy strong locks." (Stoll 349) | Rather than accepting it as a helpful test of system security, Cliff likens the virus to entering a village and breaking into houses, in order to impress on everybody the need for better locks. (Stoll 349) | Cliff Stoll draws a comparison with another trusting environment---a small town without strong locks---to highlight the idea that an attack that causes actual damage can't simply be written off as exposing security flaws. (Stoll 349) |
In this case, the source material includes a nice analogy, and it's a good candidate for a direct quote, to bring out a bit of the source author's sarcasm and sharpness, so the version on the left is good. Actually paraphrasing the idea may make it fit better in the paper, allowing the lesson to be drawn a bit more explicitly, so the version on the right is fine too. The version in the middle is a big problem, because although it does acknowledge Stoll's book as the source of the idea, the lack of quotes implies that the idea's expression here is original, which in this case it really is not---it is directly lifted from the source material. (The cited work is Cliff Stoll, The Cuckoo's Egg, 1989. An excellent book, by the way; you should read it.)
Citation format. Some professors care a lot about whether you use APA, MLA, Chicago, or some more obscure format for your citations and references. I mostly don't. (APA's good if you're mostly citing articles, MLA's better if you're sourcing from books, and they're all still sort of a mess if you're citing websites.) But even if I did, problems with the format of a citation are akin to a spelling error, not an honor violation. So, try to follow some format, but the overarching question should be, "can the reader tell that this is someone else's idea?"
This section addresses the non-paper written assignments, such as program traces, memory diagrams, etc.
For most assignments, you'll use outside sources (unless this is prohibited---see the assignment for details). There is a broad assumption that you'll use the course textbook for many assignments, and you don't have to keep constantly citing it, but if you use a specific algorithm or diagram style or answer format, even if it's from the book (and especially if it's from elsewhere) you should mention that. (Aside from honesty concerns, this also makes it easier for me to understand your reasoning and give you credit for your answer.)
It doesn't have to be big or complicated. "Worked with Rick and Lisa on #2 and #5." or "adapted from p522." are just fine.
Rule of thumb. If you can write out the answer without looking anything up, based on "common knowledge" known by computer scientists, you don't have to cite it. If you have to have the book or website open next to you and keep referring to it while you write out the answer, you need to mention it.
Guidelines for written assignments often don't fit well for computer programs, so I've written separate program guidelines below.
Sometimes, you'll be in the situation where you've found program code, either in the textbook or online, that will (partially) solve your problems with only minor modifications. There are two important points to make about this case in comparison to "finding the perfect source" when writing a research paper.
It would be staggeringly unfair to both encourage you to use online resources and forbid you from making use of them if they're too good a match for the problem (not least because it's impossible to "un-see" the code---even if you try to write it yourself you'll be subconsciously influenced by the solution you've seen). You'll learn more from the assignment if you get as far as you can on your own before consulting the internet! But in the end, if you do find that (for instance) some C++ website out there has an exact solution to the problem I've given you, and you use it with little or no modification (and cite it!), there's at least some credit due for your resourcefulness and recognition that it was indeed a correct solution; and your citation makes it clear that you are being academically honest.
An important caveat! The above paragraph was written from a perspective that assumes you are looking at general-purpose websites and forums that other people have been asking typical questions on. This is not, however, an open invitation to circumvent other rules, nor is it a guarantee that you will get full credit for the solution. If you happen to stumble on a former student's posted solution for the exact assignment I gave (rather than a highly similar problem on a general website), and quote it in full and cite it, you might not be up for dishonesty charges, but you also won't be getting much (if any) credit for understanding the problem or its solution. Furthermore, if you go on a forum and actively solicit answers to the problem, or ask another student to help you on the problem, then you may be in violation of a different aspect of academic dishonesty even if you cite them---it may not be plagiarism, but it is cheating.
Citing a piece of program code tends to be somewhat more informal than
citation in papers, but it still occurs, and it's just as important.
In the case where you use an entire function, and
especially if you use an entire class, from another source, it has
become standard to indicate this using @author tags, a practice
originating in javadoc documentation but which has since spread to other
languages. Precede the function or class in question with a "doc" comment as
follows:
/** General description of class.
* Some further specifics...
* @author Alex Q. Programmer */
If you use another author's class as a starting point but add your own
methods (or modify theirs), you would include your name in an
additional @author tag:
/** General description of class.
* Some further specifics...
* @author Alex Q. Programmer
* @author Your Name */
However, you should still be citing when you use any significant piece of code written by someone else, even if it's smaller than a function, including translating it from another programming language or from pseudocode, by including a code comment to that effect. For example,
//function adapted from left-rotate on CLR p. 266or
//for-loop body from http://tesoga.com/articles/balanced_red_black.html
Rule of thumb. If the only thing you learn from the outside source is the name of a function, or the order of its arguments, or an idiomatic expression to accomplish your goal, you probably don't have to cite that.
Rule of thumb. If you're using more than two or three lines from the source, you should cite it.
Rule of thumb. If in doubt, cite it.