Show up on time. Pay attention. Don't disrupt.
It is important that students attend class regularly, show up to class on time, be ready to work when class starts, and stay focused on the day’s computer science activities and materials throughout the entire class period. When it’s time for class to start — whether a bell rings or not — students should be seated, quiet, and attentive.
Students who are being disruptive or are not properly focused will be singled out. Depending on the situation, students may or may not be warned or reminded of expectations before being instructed to move to a different area of the room or leave the room entirely. Disruptive behavior will not tolerated. Unacceptable classroom behavior may have a negative impact on a student’s grade.
Cell Phone Policy
The following applies to normal, every-day situations (not emergencies). With one exception:
- Cell phones should never be handled or seen in the classroom.
- Cell phones should never be heard in the classroom.
- Cell phones should never be used in the classroom.
Food and Drink in the Computer Lab
Don’t bring food into to computer room. But if you do, leave it on a table at the front of the room. Whatever you do, don’s have food with you as your working in front of a computer.
Also, don’t bring drink into the computer room. But if you do, only bring water in a container with a lid on it and leave it on a table at the front of the room. In any event, make sure it’s in a container with a lid on it.
Tardiness
Students who are not ready for class (i.e. seated, quiet, and prepared to work) when it’s time for class to start may be marked tardy using the school’s attendance tracking system. It's not good enough to simply be in the room. Class periods are fairly short, there’s a lot of material that needs to be covered and students are generally very busy throughout the day and into the evening. It’s unfair to everyone when class is delayed even a for a minute or two because a small number of students are not present or are unprepared for class.
When a student is tardy, records will indicate that the tardiness was excused if and only if the the student provides a note from another teacher or staff member explaining why the student was late to class.
Absences
Students who do not attend class or are absent for the vast majority of class will be marked absent. Absences may be excused; however, it is the responsibility of the student to communicate with the main office to make sure excused absences are documented appropriately in the attendance tracking system. (Teachers are not able to indicate that absences are excused, given how PowerSchool is designed and accounts are managed at VCHS.)
Temporarily Leaving the Room
Before leaving the room, students should always try make sure the instructor knows where they are going and if they might be gone for very long. Ways of handling this communication that minimize interruptions will be discussed in class.
Needing to use the restroom is by far the most common reason students ask to leave the classroom. Sometimes things happen at unfortunate times, and sometimes we have enough advanced warning to take action. If a student really, urgently needs to take care something—anything—that requires a trip to the bathroom, then in almost all such cases they should just go. Unfortunately, there is one clearly stated exception to this rule of thumb. During an actual lockdown, students and teachers are instructed to stay in the classroom. In that unlikely event, a nearby container of some sort can hopefully be employed if necessary. In a nutshell or a panic, try to use good judgement. (Also, Don’t Panic.)
Students should not plan to use or get into the habit of using computer science class time as a regular break time. If it appears that this is happening, then the instructor will have a private conversation with the student about their behavior so it can be better understood and altered if possible.
If a trip to the bathroom can be delayed until after the day’s activities have been introduced and any important announcements have been made, then students should try to wait a few minutes if they can. Otherwise they might not receive information needed to effectively participate in class; this can result in disruption and wasted time when the student returns and things that were previously discussed just moments earlier have to be repeated, either by the instructor or another student.
VCHS Academic Integrity Policy
All VCHS students should be familiar with the VCHS Academic Integrity Policy.
Computer Science Academic Integrity Policies
Below are excepts from policies defined by computer science departments at some pseudo-randomly selected universities. The general theme is:- Do your own work.
- Cite your sources.
- Don't share your work with others.
- Don't cheat.
Violations of the precepts listed above or any of the detailed policies listed below will be dealt with per the VCHS Academic Integrity Policy.
Example 1. https://cs.uiowa.edu/graduate-programs/academic-integrity:
Work outside the classroom on assignments and programming projects plays a particularly important role in the learning process in computer science. It is essential that each student's work reflect his or her own effort. Our department treats cheating seriously. Instructors retain considerable latitude in the penalties they may invoke.
Example 2a. https://www.cs.rutgers.edu/academic-integrity/programming-assignments:
The purpose of programming assignments is to have students develop the skill of writing programs embodying concepts taught in class. Programming assignments must therefore be done independently unless explicit instructions are given describing the collaboration permitted (e.g., a team project).
Example 2b. https://www.cs.rutgers.edu/academic-integrity/introduction:
While you are a student at Rutgers you may be tempted to turn someone else's work in as your own, perhaps by copying their solution to an exam question or to a programming assignment. Rutgers University has a detailed policy concerning Academic Integrity (which can be found following this link). The Dept. of Computer Science endorses and adheres to this policy, and you should be familiar with it. You should know that copying or collaborating too closely on programming assignments is considered a violation of Academic Integrity, as is allowing others to copy your work.
Although it may seem self-evident, here are some reasons, both moral and practical, not to yield to the tempation of submitting under your name the work/program of another, or a program that was jointly developed:
- Programming assignments are meant to develop skills that are essential to anyone with a CS degree. By not doing the work yourself, you are cheating yourself of an education, and you are wasting your time and tuition fees.
- In most CS classes the exams are heavily based on the homework and programs, so if you do not do this work yourself, you are setting yourself up for failure on the exams.
- Most CS classes are graded on a curve, so if you cheat you may feel that you are helping yourself, but you are certainly hurting your classmates.
- The CS Department is serious about catching cheaters and seeing that they get punished. Formal charges are filed against a number of students each semester. The penalties include suspension or even expulsion from the university.
- Even if you do get away with cheating at Rutgers, when you get a job there will be no one to copy from and no way to hide incompetence. You will only make a fool of yourself and, in the process, reduce the job prospects of all other Rutgers graduates.
Copying on an exam is obviously cheating, but what constitutes unacceptable collaboration on a programming assignment? Unless the instructor has specified otherwise for a particular course or assignment, the following rules apply to programming assignments:
- It is unacceptable to submit the program of another student, or a program written jointly, even if it was edited afterwards.
- It is also unacceptable to have someone else debug your program: occasional help in determining the source of the error in your program is OK, but you must be the one who finds solutions.
- This means that if you discuss a programming assignment with a fellow student, you may not take anything written away with you from the conversation, either in hard copy or on-line. Suggestion: After a conversation, before you start working on your assignment, you need to spend at least a half an hour doing some unrelated activity. (Watching "Gilligan's Island" used to be the prototypical example.) This way, the program you are writing reflects your own understanding -- which is the purpose of the assignment.
Example 3. https://www.eecs.psu.edu/students/resources/EECS-CSE-Academic-Integrity.aspx:
The Department of Computer Science and Engineering expects all student programming work assigned in a class to be completed independently by students (or by teams if permitted/required) and to consist of code designed and developed solely by the students. The use of any other code is not permitted unless the course instructor explicitly allows it and such code is clearly identified as coming from an external source and that source is credited. Students will never be given credit for code which they did not construct.
...in an introductory course in which the programming assignments require relatively short solutions (i.e., less than 50 lines of code) we would expect to see similarities in student solutions rising to a significant percentage of the code. But in an advanced course in which programming projects may contain thousands of lines of code, only a small percentage may be similar but still constitute an academic integrity violation if the code in question was a significant/important aspect of the assignment and if the similarities found could not, in the opinion of the instructor, have been independently developed.
Example 4. https://www.cs.washington.edu/academics/misconduct:
Each student who accepts admission into the Computer Science & Engineering degree programs agrees to be bound by the provisions of this section.
Below, we outline the general academic integrity policies used by many courses in CSE. If a course declares its own academic integrity policy, that policy supersedes the information found on this page.
The basic principle under which we operate is that each of you is expected to submit your own work. In general, any activity you engage in for the purpose of earning credit while avoiding learning, or to help others do so, is likely to be an act of Academic Misconduct.
As a particular example, attempting to take credit for someone else's work by turning it in as your own constitutes plagiarism, which is a serious violation of basic academic standards. From the attention that the school pays to the Academic Misconduct issue, some of you will get the idea that any discussion of assignments is somehow a violation of academic principle. Such a conclusion, however, is wrong. In CSE courses it is usually appropriate to ask others -- the TA, the instructor, or other students -- for hints and debugging help or to talk generally about problem-solving strategies and program structure, as well as lecture and textbook content. In fact, we strongly encourage you to seek such assistance when you need it. The important point, however, is embodied in the following rule:
Rule 1: You must indicate on your submission any assistance you received. If you make use of such assistance without giving proper credit, you may be guilty of plagiarism.
For programs, proper citation usually takes the form of comments in the program. The instructor might indicate other methods of acknowledging help received, especially for other types of assignments. It is also important to make sure that the assistance you receive consists of general advice that does not cross the boundary into using code or answers written by someone else. It is fine to discuss ideas and strategies, but you should be careful to write your programs on your own. This provision is expressed in the following rule:
Rule 2: You must not share actual program code with other students. In particular, you should not ask anyone to give you a copy of their code or, conversely, give your code to another student who asks you for it; nor should you post your solutions on the web, in public repositories, or any other publicly accessible place. Similarly, you should not discuss your algorithmic strategies to such an extent that you and your collaborators end up turning in exactly the same code. Discuss ideas together, but do the coding on your own.
The prohibition against looking at the actual code for a program has an important specific application in computer science courses. Developing a good programming assignment often takes years. When a new assignment is created, it invariably has problems that require a certain amount of polishing. To make sure that the assignments are as good as they can be, our school -- like most others in the country -- may reuse assignments, incorporating a few changes each time to make them more effective. The following rule applies in all CSE courses:
Rule 3: You must not look at solution sets or program code from other years, nor should you make your own solutions publicly available even after the due date. Beyond being a clear violation of academic integrity, making use of old solution sets is a dangerous practice. Most assignments change in a variety of ways from year to year as we seek to make them better. Each year, however, some student turns in a solution to an assignment from some prior year, even though that assignment has since changed so that the old solution no longer makes sense. Submitting something that solves a previous year's assignment perfectly while failing to solve the current one is particularly damaging evidence of Academic Misconduct.
Whenever you seek help on an assignment, your goal should be improving your level of understanding and not simply getting your work completed correctly. Suppose, for example, that someone responds to your request for help by showing you a couple of lines of code that do the job. Don't fall into the trap of thinking about that code as if it were a magical incantation -- something you simply include in your program and don't have to understand. By doing so, you will be in no position to solve similar problems on exams. The need to understand the assistance you receive can be expressed in the following rule:
Rule 4: You must be prepared to explain any program code you submit.
Although you should certainly keep these rules in mind, it is important to recognize that the cases that we bring forward to the University are not those in which a student simply forgets to cite a source of legitimate aid. Most of the students we charge with Academic Misconduct have committed fairly egregious violations. Students, for example, have rummaged through paper recycling bins or undeleted trash folders to come up with copies of other students' work, or have e-mailed part of all of their solutions to other students in advance of the due date.
Rule 5: Modifying code or other artifacts does not make it your own.
In many cases, students take deliberate measures -- rewriting comments, changing variable names, and so forth -- to disguise the fact that their work is copied from someone else. It is still not your work. Despite such cosmetic changes, similarities between student solutions are easy to detect -- and we have effective tools for doing so. Programming style is highly idiosyncratic, and the chance that two submissions would be the same except for changes of the sort made easy by a text editor is vanishingly small. In addition to solutions from previous years or from other students, you may come across helpful code on the Internet or from other sources outside the class. Modifying it does not make it yours.
Your instructor may choose to allow exceptions in certain obvious instances. For example, you might be assigned to work with a project team. In that case, developing a solution as a team is expected. The instructor might also give you starter code, or permit use of local libraries. Anything which the instructor explicitly gives you doesn't normally need to be cited. Likewise, help you receive from course staff doesn't need to be cited. But help you receive from the outside the course, such as from tutors, even if the tutors are paid for by the university, must be explicitly mentioned. Finally, the instructor may have additional clarifications or additions to the policies on this page.
We have no desire to create a climate in which students feel as if they are under suspicion. The entire point of the Academic Misconduct Code is that we all benefit from working in an atmosphere of mutual trust. Students who deliberately take advantage of that trust, however, poison that atmosphere for everyone. As members of the CSE community, we have a responsibility to protect academic integrity for the benefit of the community as a whole.