Self-plagiarism and collusion in source-code

Academics were asked to provide their opinion as to which academic offence applies to given scenarios regarding group actions,self-plagiarismandcollusion. In non-programming assignments, self-plagiarism occurs when a student reuses parts of an assignment previously submitted for academic credit and submits it as part of another assignment without provid- ing adequate acknowledgement of this fact. In programming modules where source-code reuse is taught, self-plagiarism may not be considered as an academic offence. Collusion, occurs when two or more students collaborate on an assignment when the assignment re- quires students to work individually.

The scenarios presented to academics are as follows:

• Scenario A: For a group assignment, students in different groups exchange parts of source-code with the consent of their fellow group members, and integrate the borrowed source-code within their work as if it was that group’s own work.

• Scenario B: For a group assignment, students in different groups exchange parts of source-code, without their fellow group members knowing, and integrate the bor- rowed codes within their work as if it was that group’s own work.

• Scenario C: Assume that students were not allowed to resubmit material they had originally created and submitted previously for another assignment. For a graded as- signment, a student has copied parts of source-code that he had produced for another assignment without acknowledging it.

• Scenario D: Two students work together for a programming assignment that requires students to work individually and the students submit very similar source-codes.

The responses of academics for are shown in Figure 3.5.

The majority of the academics consider scenarios A, and B as plagiarism. Consider- ing the comments given by academics to previous questions, these scenarios can consti- tute plagiarism, collusion or another academic offence depending on university regulations. Scenario B can constitute plagiarism, collusion as well as another academic offence since material was obtained without permission (the type of academic offence depends on the academic regulations of each university). Regarding scenarios A and B, some academics

Figure 3.5: Scenarios and responses (5)

expressed some concerns on the issue of plagiarism in group assignments. One academic commented,

“I avoid group assignments for just these reasons. I permit students to work together as long as they individually write their own code and documentation. I regard this as pedagogically valuable”,

while another academic observed

“...Some students learn better while working in groups but they must ensure that the work submitted is original and their own. The tell tale here is the comments (and spelling mistakes) are identical.”

or ‘another academic offence’. However, as mentioned above the name depends on univer- sity regulations. Academics commented,

“the last one [scenario D] is very tricky to decide; I’m very happy for students to work together, but very unhappy when I have to make this kind of decision. I’d be inclined to say ‘plagiarism’, but treat a first offence leniently,”

another academic considered this scenario as

“very common and usually accompanied with denials that they had submitted the same code and/or they didn’t know they weren’t allowed to work together.”

In student assignments, self-plagiarism occurs when a student copies entire or parts of his/her own assignment and submits it as part of another assignment without providing proper acknowledgement of this fact. However, when we asked academics whether it con- stitutes plagiarism if a student resubmits source-code they have originally created and sub- mitted previously for another assignment (see scenario C) we received some controversial responses. The majority of the academics (48 out of 59) characterised this scenario as an academic offence (17 as plagiarism and 31 as other academic offence). In their comments, those academics characterised this scenario as “self-plagiarism”, “breach of assignment reg- ulations if resubmission is not allowed”, and “fraud if resubmission is not acknowledged”.

Some academics argued that in object-oriented environments, where reuse is encour- aged, it is inappropriate to prevent students from reusing source-code produced as part of

another programming assignment. The comments and responses provided by the academics who do not consider the given scenario to constitute plagiarism or another academic offence point to the controversial issue on source-code reuse mentioned above. One academic who provided a ‘do not know’ response remarked that students should reuse source-code where possible, while another, who was clear that the given scenario ‘was not an academic of- fence’, emphasized

“I find it hard to assume that students were not allowed to resubmit material.”

A third academic, who also stated that the given scenario ‘was not an academic offence’, asked rhetorically

“Would this ever happen in an object-oriented programming module when we behove students not to reinvent the wheel?”

In conclusion, since 48 out of 59 academics characterised the action of resubmitting source-code produced as part of another assessment as a type of academic offence (plagia- rism or other) we can conclude that resubmitting source-code without providing appropriate acknowledgements may lead to an academic offence if this is not allowed for the particular assignment.