Policies and procedures

The Department of Computer Science has established policies and procedures covering a number of situations.

The department policies described on this page augment the University policies as described in the Brock University Act, the Brock University Faculty Handbook and Faculty of Mathematics and Sciences policies.

  1. Students fill out an override form specific for overriding prerequisites.
  2. Where the student is claiming prior knowledge equivalent to the prerequisite, the form should be approved by a Program Advisor.
  3. Where, due to special circumstances, a student must take courses out of normal sequence, the form should be approved by a Program Advisor.
  4. Where the override is due to program requirements, the Administrative Assistant will approve overrides according to criteria that have been established and reviewed annually by the Department Committee. If no established criteria cover the case, a Program Advisor will approve the request.
  5. Where the override is due to an inadequate grade in the prerequisite, the Administrative Assistant will approve the overrides according to criteria that have been established and reviewed annually by the Department Committee.
  6. In special circumstances, the course instructor may either request to approve override requests not covered above, or establish a set of criteria to allow the Administrative Assistant to approve the request.
  7. The Administrative Assistant will process all approved requests and will track requests by a single student. If a student has submitted multiple requests at different times for courses in the same term, the complete set of requests will be re-evaluated by a Program Advisor before processing.
  1. An instructor may choose to opt out of the following procedure (2-11) for a course. If so, the instructor will personally supervise the inspection of all exams in the course following procedures consistent with University policy.
  2. A student may book an appointment to inspect his/her examination with the Administrative Assistant. The booking must occur no later than 2 weeks after marks are mailed to the students by the Registrar’s Office.
  3. The student is granted a maximum of 30 minutes to inspect his/her examination. The student will be provided a copy of the examination script, the marking scheme, sample solutions or both and an examination review form.
  4. If the student determines that an error occurred during marking, such as a question, or part thereof being missed or an error in totaling the paper, he/she indicates this on the examination review form.
  5. If the student wishes, the student may request that the examination be remarked by indicating so on the examination review form.
  6. If the student has not detected an error and does not wish a remark, he/she indicates so on the examination review form.
  7. The student will sign the examination review form and the Administrative Assistant will date it.
  8. If the student has detected a marking error, the instructor will verify the correctness and, if necessary correct the result within two weeks of the inspection of the exam. In any case, the instructor will record his/her decision and sign and date the form.
  9. If the student has requested a review, the instructor will carry out the review within one month of the last appointment for an exam inspection in the course. If the exam mark changes and that change affects the final grade, the instructor will record his/her decision and sign and date the form.
  10. A student may only inspect his/her paper once. If the student is still not satisfied with the result, the standard University Appeals process may be used.

Preamble

The computing systems in the Department of Computer Science are intended to support its educational and research purposes and to enhance the educational environment. The following is a list of goals that the Department hopes to achieve:

  • To ensure that the computing systems are properly maintained.
  • To ensure that computer system up-time is at a maximum.
  • To announce in advance any down time that is scheduled.
  • To make available state of the art computer systems and software. This is of course subject to available funds and space.
  • To make available suitable stations for those with special needs. This is of course subject to available funds and space.
  • To make the Department’s computer systems readily available to our students (see also Policy on Keys).

The hardware in the Department’s facilities is the property of the University; the software, and the files of users are intellectual property. All require respect. Therefore, access to the Department’s computing facilities is a privilege that can be withdrawn should a user or users abuse the hardware or software or violate the rights and needs of others. It is imperative that your conduct in a computer environment be in accordance with the rights and responsibilities that direct society in general.

Privacy Issues

Users must respect other users’ computer files, as these are their own private property. This also includes any University files such as grades, budgets, and research data. Such actions as destroying, altering, copying or simply snooping through the data of other users is a serious breach of ethics and will be treated seriously by the Department.

System Security and Cracking

Threats to the integrity of computer systems and networks can adversely affect the ability of others to effectively accomplish their work. Threats include such activities as trying to obtain access to computer files that are restricted, trying to obtain passwords for other accounts, trying to remove or change restrictions or charges on a computer account, and trying to affect system performance or behaviour. Activities of this nature are serious breaches of ethics, and will be treated seriously by the Department. They may involve disciplinary hearings or criminal charges.

User Codes

As per CCCP’s policy on user codes (April 1994), all registered Brock University students will receive a user code on a central system for electronic mail and will have general internet access.

The Department of Computer Science will provide user codes for students registered in the programme. The students will be allocated user code(s) (with the required resources) on appropriate machine(s) as required for completion of the courses in which they are enrolled.

Users are to use only those computer accounts that have been authorized through the normal Department channels. It is unethical to use another user’s account. Users are responsible for the use of their own computing accounts. They should maintain secure passwords and take precautions to prevent others from obtaining unauthorized access to their computing resources.

The user codes provided are to be used solely for the completion of course projects, assignments, and for academic research. Use of a user code for the purpose of financial gain is strictly forbidden without the prior consent of the Department and consequent contractual arrangements with the Department.

Department user codes will be issued as follows:

  • Students registered in Computer Science courses numbered 1(alpha)xx will receive user codes only for those systems required to complete the work in the course. These user codes will be removed at the end of each term or if the student withdraws from the course.
  • Students registered in Computer Science course(s) numbered 2(alpha)00 and above will be issued user codes on all Department systems. These user codes are removed if the student withdraws from all department courses, and in the subsequent fall unless the student has reregistered.

Although the Department will make every attempt to retain student files between years, students must take ultimate responsibility for backing up their files.

Application for user codes for students not covered above may be made using a form available from the secretary and on this server, and will require the approval of the department chair.

All user codes are subject to deactivation or removal as a result of disciplinary action taken against a user for violation of the computer use policies.

Software Piracy

The unauthorized copying of software deprives the developers of a fair return for their work, which results in an increase in prices, a reduction in the level of support and the chance of any future enhancements.

The unauthorized copying of copyrighted software is illegal. The Canadian Copyright law has been modified to also protect software authors and publishers. Users who make and use illegal copies of software are subject to the civil and criminal penalties imposed by Canadian Law.

Users should also realize that unauthorized copying of software by users can harm the entire University. If the unauthorized copying of software proliferates the University may also incur a legal liability. This could adversely affect any future negotiations with software vendors aimed at making software cheaper and more widely available to the University community.

The Department views software piracy seriously, and if users are caught running pirated software on University machines, they will be dealt with severely.

Software Access and Manuals

In order to adhere to the above policy on Software Piracy and to protect the Department and University from any liability any software purchased by the Department will be available either from a network server which enforces quotas (number of users allowed simultaneous access) and software copy protection or an installation on a user’s local hard disk with quotas and copy protection handled by appropriate software, such as a “key server”.

Departmental software media will be kept in a secure area away from general access.

Manuals and other types of documentation may be signed out through the Department secretary for a short period of time.

Software Purchases

Departmental software purchase requests should be directed either to the Department’s Network and Systems Administrator or the Department Chair. Each submission should be justified in order to provide a means of prioritizing software needs. This will ensure that the software once received is installed on the appropriate server and it provides coordination of purchases from a limited budget.

All Department purchases must be authorized by the Chair.

Computer Viruses

Malicious computer code, commonly known as computer viruses, can cause users mild inconvenience or can ruin years of work. The deliberate introduction, creation, propagation, or modification of a computer virus on campus by a user will be dealt with severely. It is strongly recommended that users make use of the anti-viral software available in order to protect their data.

Network Etiquette

Brock University’s campus network is connected to the Internet. The Internet is a network comprised of over three million computers around the world interconnected by hundreds of data communications networks. Please remember that as you utilize the network and its resources you are an ambassador, representing the University and its community! Any illicit actions by a user may result in the University losing its internet connection. Please use it responsibly!

Electronic Mail

Users must not use the Department’s computing facilities to send obscene, vulgar, or harassing messages.

Users must take care in how and what is said in their messages. None of the verbal hints and physical cues you use when speaking in person can be seen by others across a network. Your words generally deliver a stronger message when written than when spoken. As well, be aware that in an educational setting English may not be the first language of the person who wrote what you are reading, so please be tolerant and sensitive to unintentional incorrect choice of words.

InterNet News

The News Reader service (also known as USENET and NetNews) is the largest interactive electronic forum for on-line discussions in the world of education and research, and as a result is vulnerable to bad manners. Please read the FAQs (Frequently Asked Questions) for the groups to which you subscribe. They are posted to the group on a regular basis. One news group that you should start with is news.announce.newusers.

Avoid posting anything on the network until you understand the group dynamics. You risk getting hundreds of scathing e- mail messages (called ‘flames’) from around the world in return, as well as making a fool of yourself in the eyes of thousands of readers. In extreme cases, you may attract enough attention and complaints to threaten the University’s connection to the Internet.

Offensive Material

Offensive materials take many forms in the world of computing and networking. Originators have a responsibility to monitor their material so that it is not obscene, vulgar or harassing. Should you receive material, such as a message, picture, or suggestion, that offends you, tell the originator that the material is unwelcome and offensive to you. Ask that no more be sent to you. If the originator continues please submit your complaint in writing to the Department Chair or to the Sexual Harassment Advisor, extension 4019, if appropriate.

Computer Laboratory Etiquette

The computer laboratories are a resource that must be shared by many users. The equipment represents a significant financial investment by the Department and the University. It must also be realized by users that the Department has a limited number of computers systems. In order to accommodate the number of students enrolled in Department courses and provide equitable access to the laboratories, the Department reserves the right to limit laboratory access to registered users and to post in the laboratories, at the Department’s discretion, bookings or access times. The times that the laboratories are available for drop-in use will then also be posted. In some instances it is possible to sign out laboratory keys. Please refer to the Policy on Keys document for more information.

It is also the responsibility of users and the Department to safeguard this equipment and to provide an atmosphere within the laboratories which is consistent with a professional environment.

Unacceptable Behaviour

The following are examples of what is considered unacceptable by the Department and may result in the loss of privileges.

  • Disruptive behaviour such as prolonged loud talking, and playing loud music.
  • Monopolizing stations or printers.
  • Installing copyrighted software for which the Department has no license.
  • Installing software without the Department’s permission.
  • Modifying the computer system’s files, such as modifying system folders.
  • Using screen savers with passwords thus preventing others from making use of the system.
  • Playing games during peak periods. These users must yield their system to those students with work to perform.
  • Displaying, playing, or transmitting materials that may be considered offensive by others.

Acceptable Behaviour

The following are considered acceptable by the Department and will be encouraged.

  • Some of the microcomputer systems in the labs are equipped with their own hard drive. These drives may be used to temporarily store your files for the duration of your work session. These files must be erased from these systems before you leave. Note that the hard drives will be purged periodically, and no user files will be saved.
  • Conserving disk space, on shared systems. The Department makes regular back-ups of these shared disks.
  • Conserving paper by previewing your work on the computer system before printing.

When using the laboratories, students are asked to clean up after they are finished their work session. Please turn off (at end of day) the monitor and CPU when working on the Macs or PCs. Return your chair to its proper place and place any scrap paper or old printouts in the recycling bin.

Disciplinary Action

Use of the Department’s computing facilities entails your acceptance of the above policies. Normally a first violation of these policies will result in an appropriate warning. If the violations are sufficiently serious or persist, further action will be taken through the normal University channels.

Preamble

Since the Department is a part of the University, the general academic policies on cheating and plagiarism as found in the Calendar or the Faculty Handbook (section III 15), also apply within the Department. These policies suffice for much of the work, including examinations and written assignments. However, they do not deal explicitly with course work involving computers; thus the policies must be extended to cover these cases. Note that the terms “cheating” and “plagiarism” are effectively interchangeable for the purposes of this document. The decision as to whether a student has cheated depends on the intent of an assignment, the ground rules specified by the instructor, and the behaviour of the student. Two guidelines help an instructor decide if cheating has occurred:

  • Program plagiarism will be suspected if an assignment that calls for independent development and implementation of a program results in two or more solutions so similar that one can be converted to another by an algorithmic transformation.
  • Cheating will be suspected if a student who was to complete an assignment independently cannot explain both the intricacies of his or her solution and the techniques used to generate that solution.
    It is unreasonable to expect a complete definition of cheating; each case is important enough to be given careful, individual scrutiny. It is, however, helpful to have guidelines and precedents. Here are some examples of cases that are clearly cheating and clearly not cheating.

Cheating

  • Turning in someone else’s work, in whole or in part, as your own (with or without his or her knowledge) and without acknowledgment. Turning in a completely duplicated assignment is a flagrant offence.
  • Allowing someone else to turn in your work as their own.
  • Several people writing one program and turning in multiple copies, all represented (implicitly or explicitly) as individual work.
  • Using any part of someone else’s work without the proper acknowledgment.
  • Copying code from the web, even if it is an open-source site (e.g. Github, StackOverflow), possibly modifying it, and handing it in as your own.
  • Stealing an examination or a solution from the instructor. This is an extremely flagrant offence.

Not Cheating

  • Turning in work done alone or with the help of the course’s staff.
  • Submission of one assignment for a group of students if group work is explicitly permitted (or required).
  • Getting or giving help on how to do something on the operating system of the computer.
  • Getting or giving help on how to solve minor syntax errors.
  • A high-level discussion of the course material for a better understanding.
  • Discussion of assignments to understand what is required.
  • Acknowledging via a comment in the code the source of the program segment.
  • If you fully and correctly attribute the source (e.g. from an open-source site) it may not be cheating, but you might not get credit for it.

Disciplinary Actions

The Department faculty will not condone cheating. When cheating is suspected, instructors will take reasonable action to establish whether it actually occurred. The appropriate disciplinary policy will be applied in all proven cases, always subject to the regulations contained in the Faculty Handbook, and described in the University Undergraduate Calendar. The penalty imposed may range from zero for the piece of work to expulsion from the University.

Preamble

Programming and using a computer are obviously integral parts of a sound education in computing – TAs play an essential and valuable part in the teaching of computer science to undergraduates. This laboratory teaching function complements the formal lectures, and is vital. However, it is not the total function of the TA, the other functions being less tangible. TAs can often bridge the gap between first and second year students and the faculty. First year students in particular may find it easier to relate to a TA, who is a fellow student, than to faculty. Thus TAs have a pivotal function in setting an example, as a role model. Many students will pattern their behaviour and approach to programming and problem solving on their TA’s attitude and philosophy. The TA’s enthusiasm and their techniques of imparting their knowledge of programming and problem-solving are thus very important. A TA is expected to know the work that is being covered in the associated lecture sessions, and it is the TA’s responsibility to obtain all necessary information (assignment, what has been taught, package being used, …) prior to the laboratory.

General Guidelines for a TA

  • A TA should assist students to the best of his/her ability. Assistance is subject to the guidelines regarding the degree of help that a TA can or should provide (see the following section).
  • A TA should always be present at the time and place that is specified in their contract. This includes being on time for their laboratory.
  • In the case of illness or accident, the TA shall inform the supervisor as soon as possible (email, phone call) so adequate alternative arrangements can be made. Medical note may be requested to produce proof of sickness.
  • If a TA is unable to be present for other reason (e.g. dentist’s appointment, having to work on the TA’s own assignment), the onus is on the TA to inform the supervisor well in advance, and to assist in finding a replacement.
  • The TA’s responsibility first and foremost is the students in the laboratory. Thus TAs should refrain from doing personal work (assignments, essays, …) while the laboratory is in progress. Doing one’s own work is only acceptable if there is no one in the laboratory.
  • The TA should be active in the laboratory, not passive.
  • The TA’s presence should be made known by routinely walking around the laboratory, looking for students with assignment/programming problems.
  • A TA may be asked to help in the maintenance of the equipment and software in the laboratory (such as reformatting and loading a hard disk) during their laboratory period.
  • It is expected that a TA will attend all meetings scheduled with the course instructor/coordinator. These regular meetings are intended for feedback from the TAs to the instructor, as well as information sessions regarding what is due to be taught, what needs special explanations, what has not yet been covered in lectures, and marking expectations.

General Guidelines for a Marker

  • A marker should complete their marking of assignments in the time period (usually one week) specified by the course instructor/coordinator.
  • All assignments must be clearly initialled by the marker.
  • The marking scheme must be read completely and carefully first before any assignments are marked. If you have any difficulty with interpretation, please consult with the Course Coordinator or the faculty member involved.
  • Assignment submissions are the result of a lot of sweat and possibly tears on the part of the students -please do not be facetious in your comments, but be fair and constructive.
  • If a student has a genuine grievance or concern with the mark received for an assignment, the student should see the instructor, who will investigate the mark allocation and possibly consult with the marker. Only the instructor can change the mark.

Guidelines Regarding Assisting Students

  • The TA is responsible for helping the students in the laboratory with course related material, which may include instruction, coaching, and problem solving.
  • When student is having trouble solving an assignment problem, it is the TA’s responsibility to give direction to that student and lead them toward an understanding of the difficulty.
  • A TA is not required to, nor is it suggested that they, provide the solution to an assignment problem.
  • It is acceptable for a TA to suggest small code segments (no more than a few lines of code) in addition to correcting that code which a student has already written, in order to get the student on to the right track.
  • The TA is encouraged to prompt the student with questions that, when answered, will lead the student to a better understanding of the problem.
  • A TA should always fully explain what they have done when giving help to a student.
  • If there is general difficulty in a laboratory, the TA is encouraged to air the problem and a pointer to its solution, in front of the whole laboratory. This makes better use of a TA’s time and is less repetitive. The TA should make notes of these general difficulties and communicate them to the course instructor/coordinator.

Introduction

There are many potentially hazardous areas in the Faculty of Math and Science, primarily in the undergraduate and research labs. Work goes on without incident in these areas on a daily basis. When the university is in full operation there are usually many people in the vicinity to react and sound the alarm in the event of an incident occurring. Campus Police, Health Services staff, Athletic Injury Therapist, and other trained first-aiders are also readily accessible. However, after hours, on weekends, or in isolated places of the campus, this blanket of protection is much thinner. It is to address these circumstances that this policy has been established.

“Working Alone” can be defined as having no other individual nearby or within shouting distance. The need for on-going independent research is well recognized in the Faculty and the practice of individuals occasionally working alone is inevitable. This policy is not intended to be detrimental to the research process, but to provide guidelines for
prudent operational practices.

The Policy

Individuals who fall under the definition of “working alone” should make provision for having their welfare monitored by another individual. The level of monitoring necessary is determined by the degree of hazard (based on the probability and severity of the risk) of the work, or the work environment.

Classification System

Hazard Level I

  • Minimal hazard with respect to the activity and the environment
  • Working alone is acceptable, even after hours
  • Someone, somewhere, should be aware of the individual’s whereabouts
  • Checking-in every few hours is recommended

The laboratories and terminal areas of the Computer Science department are considered to be Hazard Level 1 areas. For your own safety the department suggests that you adhere to the recommendations given above for a Hazard Level 1 area.