T-Th 9:05
or
T-Th 11:15
in Olin 155

CS 1110: Introduction to Computing Using Python

Spring 2016

Academic Integrity

Whatever the reason or intention, cheating is about seeking an unfair advantage over your classmates. It will not be tolerated.

Some forms of cheating are pretty straight-forward. Others, less so. Every year, we find several academic integrity violations. In many of these cases, the students were not necessarily intending to cheat. In particular, while they understood how plagiarism applies to writing paper, they did not understand the concept of plagiarism in computer science. If you are interested in a global perspective on this issue, a web search on that phrase will reveal that these same questions arise again and again at universities everywhere.

Summary

(1) show your group’s code to anyone except a member of the course staff.

(2) look at another group’s code.

(3) “ask for solutions” by posting questions to online services like StackOverflow.

If you are worried about your reliance on outside sources, then cite the source in your submitted code. See below for details.

(1) Disrespect for classmates. The violator seeks an unfair advantage.

(2) A misguided approach to learning. The violator thinks that perfect scores are more important than working towards mastery through honest practice.

(3) Failure to guard against the loss of better judgment. The violator induced high-stress-panic-thinking by not starting the assignment early enough.

Cornell Code of Academic Integrity

Cornell University has a Code of Academic Integrity, which explains clearly what is academic cheating and what is not. This website explains the academic integrity procedures from the standpoint of the student, the instructor, and the members of an Academic Integrity Hearing Board. Spend some time right now, and read it:

http://www.theuniversityfaculty.cornell.edu/AcadInteg/

Violations of the Cornell University Code of Academic Integrity occurring in Computer Science courses are taken seriously. While there are various ways the Code might be violated in CS 1110, plagiarism is far and away the most common transgression. Therefore the most of this page discusses how to avoid plagiarism.

However, the fact that we focus on plagiarism does not exempt you from the rest of the code. Other major infractions, such as copying from another student's exam, or changing answers on exam for a regrade, will be taken just as seriously as plagiarism.

Avoiding Plagiarism in Computer Science

One of the key things to understand about programming, and computer science in general, is that it is a writing-heavy discipline. When you create a computer program, you are writing a document, just like you write documents in an English class (or any class that involves a lot of essays). Therefore, many of the same rules that apply to writing essays also apply to computer programs, particularly regarding plagiarism.

Plagiarism is essentially a form of fraud. Every time you hand in a program in this course, you are representing it as the work of the stated authors (i.e., the members of the CMS group who submitted it) subject to any exceptions that are clearly stated in the submission itself. To avoid committing plagiarism, simply be sure always to accurately credit your sources. To do otherwise is to commit fraud by claiming credit for the ideas and efforts of others.

It really is that simple. If you have accurately acknowledged your sources, you are not committing plagiarism. You might not be doing what we asked you to do (if we asked you to work in separate groups), but you are being honest and are therefore not in violation of academic integrity, as far as CS 1110 is concerned. When you hand in an assignment without remarking on others' contributions, you are claiming credit for everything in it as your own creation. To turn in code that someone else invented and claim it as your own is fraudulent and punishable under the Code of Academic Integrity.

Acknowledging Sources

We do not require a formal bibliography like you would use for an essay. An acknowledgement can be a simple sentence such as

I wrote this function after looking at the following page on Stack Overflow: http://stackoverflow.com/questions/9189172/python-string-replace.

Just tell us the source, and how you it helped you with your code.

When explaining how it helped you with this function, you should be specific. If you say "Bob helped with this function", that means Bob gave some advice. If you say "we wrote this function with Bob", that means we should expect the code to be the same as Bob's and we should expect to see a corresponding citation in Bob's program. If you say "Bob wrote this function", that means Bob did it first and then you transcribed the code into your program (and Bob does not need to cite your code).

It is also very important where you place your acknowledgements. All acknowledgements are written using comments. There are three primary places to put acknowledgements, depending on how the source was used when writing your program. Depending on the contribution of the source, we may ask that you put your acknowledgements in more than one of these three places.

Header Comments

The header comments are the comments at the very top of an assignment file, where we ask you to put your net-ids and the date. These comments should contain the names of everyone who contributed to the submission. You can omit obvious contributions such as the course staff, but you should list everyone else.

If you talked to someone not in your CMS group and got an idea from them that became part of your solution, write this at the top of your submission. If someone other than the course staff gave you some debugging help, write this at the top of your submission. If you found a key solution to some sticky problem in a post on stackoverflow.com and incorporated that idea into your program, write this at the top of your submission.

Any and all contributions should be acknowledged in the header comments. These comments work as a summary for the rest of the assignment.

# a1.py
# Walker M. White (wmw2)
# September 1, 2013
# Some of my test cases were suggested by Lillian Lee (ljl2).

Function Specifications

If your source only helped you with a specific function, then you should include your acknowledgement inside the specification for that function. This is in addition to the acknowledgement in the header comments. You do not have to write anything new; you can write exactly the same thing in both the header comment and the function specification. It just makes it easier for us to find the acknowledgement if it is in both places.

collide(shape1,shape2):
   """Returns: true if shapes shape1 and shape2 overlap.
      
   Acknowledgement: Uses the Gilbert-Johnson-Keerthi algorithm.
   http://wikipedia.org/wiki/Gilbert-Johnson-Keerthi_distance_algorithm
    
   Precondition: shape1 and shape2 are both shape objects."""

If you copied an entire function from someone else, it is best that you use this type of comment so that we know exactly how much was copied (and how much was your own) when assigning you a grade.

Block Comments

Sometimes the source helps you with an even smaller amount of code, such as small part of a function, or a few test cases. If it is just a single line of code, you can write it using a # comment off to the side. If it is more than one line (but much less than a whole function), you might want to write the comments in a block. You write a comment with the acknowledgement at the start of the code, and another comment at the end.

As with function specification, these comments are in addition to the acknowledgement in the header comments. You do not have to write anything new; you can write exactly the same thing in both the header comment and the block comment. It just makes it easier for us to find the acknowledgement if it is in both places.

cornelltest.assert_equals(trim(' a'), 'a')
cornelltest.assert_equals(trim('b '), 'b')

# Lillian Lee (ljl2) suggested these additional test cases
cornelltest.assert_equals(trim(' '), '')
cornelltest.assert_equals(trim('a b'), 'a b')
# End of Lillian's suggestions

Implications and Grading

Integrity is about being honest about the sources of the work you are handing in. Grades on course assignments, on the other hand, are about you showing us what you have learned. If you turn in someone else's work for course credit, and forthrightly acknowledge you are doing so, you are not acting dishonestly and are not violating your integrity, but that also does not show us you have learned anything.

If two people are grouped for an assignment on CMS, they will receive the grade for the assignment, and so they should be the primary co-authors of the submission. This means they wrote the code without copying wholesale from other sources (even though they may be credited), and they both understand what is in the submission. Their submission should not be excessively similar to other groups' submissions.

If you want to be sure that you earn full credit for an assignment, we recommend following this Rule of Thumb:

Never look at any other group's assignment code, or have their code in your posession, in any portion or form whatsoever. Also never share your assignment code with students not in your group.

Scenarios

We do not want to discourage all forms of collaboration. You can certainly talk with students outside your group about an assignment. And sometimes students find themselves in a bit of a "grey area" where they are unsure of whether or not some form of collaboration will hurt their grade. For that reason, we present several scenarios that highlight the types of things that we see in this course.

Scenario 1 (Good Collaboration)

You work on your program with your partner, trade debugging strategies and maybe a test case or two with your friend Joe. You also get a pointer for a neat way of writing up one line from your friend Mary. At the top of your submission you write

We discussed this project with Joe and Mary, and we thank Joe for suggesting some test cases (noted below). The idea of implementing compute_widget as a one-liner with map() is due to Mary.

In addition, you add detailed comments at the appropriate places. A few of the test cases are marked with a comment like "This test case is due to Joe." You also repeat "The idea of implementing compute_widget as a one-liner with map() is due to Mary" in the specification for compute_widget.

In this scenario, you understand why the test cases are useful. You also understand how compute_widget works and typed in the implementation yourself after Mary explained it to you. In this case we are happy. You learned a lot by doing the project and had fun helping each other out. There is no academic integrity proceeding, and no grade penalty.

Scenario 2 (Grey Area)

You work on your program with your partner, but you copied some test cases from Joe. You also copied the one line implementation of compute_widget from Mary, carefully transcribing it straight from her program because you are not sure why it works. You write all the same things at the top of the submission as in Scenario 1.

In this scenario we are sad that you did not learn as much as you should, and you will likely perform poorly on the next exam or the next time you need to use your programming skills in real life (skills for are paying a significant number of tuition dollars to acquire). However, we will not hold an academic integrity proceeding, and you will probably still get full credit for your solution, unless this amount of collaboration was explicitly forbidden in the assignment instructions.

If you want to avoid this scenario (or the worse Scenario 3), it is best to go back and remember our Rule of Thumb. The difference between Scenario 1 and Scenario 2 is that you did not actually look at any code files in Scenario 1.

Scenario 3 (Grade Penalty, But no AI Proceeding)

You run out of time and copy test_widget.py entirely from Joe's version and widget.py directly from Mary's. You intended to rewrite it all but there was no time. So you write at the top of your program

We discussed with Joe and Mary. The testing code was implemented by Joe. The widget class was implemented by Mary.

You also write us to let us know you worked with two other students quite closely and are concerned your code will be very similar. In this scenario you have kept your integrity, and we will not be upset with you or hold an academic integrity proceeding.

However, we cannot give you full credit for the assignment either. We will take off some points, but we will be relatively fair.

Scenario 4 (Major Grade Penalty, But no AI Proceeding)

This scenario is the same as Scenario 3 but you did not mention it to us other than in the credits lines of your submission. In this scenario we will discover your code is identical and be annoyed that you did not let us know, and will definitely give you a low grade. The grade penalty will be much worse than if you had let us know ahead of time.

However, you have still kept your integrity and there would be no academic integrity proceeding.

Scenario 5 (Academic Integrity Proceeding)

This scenario is the same as Scenario 3 but you did not credit your other sources at all, or credited them but untruthfully downplayed their contributions. Maybe you did this because you were hoping we would be too busy to notice, or maybe because you were so busy and so uninterested in your own integrity that you did not bother to think before handing it in. It does not matter either way.

In this scenario you are guilty of an academic integrity violation and will receive a serious grade penalty that can be worse than a zero on the assignment. This will go along with the other consequences discussed in Cornell's AI code.

Detecting Integrity Violations

We detect academic integrity violations by looking for unusual code similarities. We say unusual, because some parts of the assignment are so straight-forward that everyone is likely to have the same code. But as the assignments get more and more complex, some parts are statistically unlikely to be the same between independent groups.

We detect these similarities with Moss, which was developed by a Cornell PhD. We give the Moss web-based software a directory containing all the submissions and another file containing the skeleton we gave you for that assignment. Moss returns a list of pairs of submissions, ranked by the percentage of similar lines and showing exactly where the similarities are. Changing variable names or comments does not help.

When we detect similarities, we then look for the proper acknowledgements in the submission. If the acknowledgement is there, then there is no integrity violation, but we may impose a grade penalty depending on the nature of the collaboration. If there is no acknowledgement at all, then we will hold an academic integrity proceeding to learn exactly what happened, and what penalty (if any) should be proscribed.

If you are interested in how Moss works, you may take a look at it the Stanford website.

Final Thoughts

Yes, keeping track of who is due credit for ideas is work. But we want you to get in the habit of thinking seriously about these issues every time you write your name on your work. We do, and so does every reputable creative professional in any field. Learning to do this is part of what we want you to get from studying at Cornell.

If you find yourself in a situation where you are not sure what the right thing to do is, contact the professor and head TA all in one email, explaining the situation (ideally before submitting the work). It is always better to ask when you are uncertain, and we are here to help you figure out what to do.