Carnegie Mellon
SCS logo
Computer Science Department
home
syllabus
staff
schedule
lecture
projects
homeworks
 
 

15-410 Policies and Mechanisms


About This Document

This document sets forth specific policies and mechanisms for this class. You must also read the companion document on high-level Expectations.

Getting Help

Where to start

Because synthesizing information from multiple sources is one of the learning objectives of this course, if it seems to us that you have overlooked a source of information about a topic we may ask you if you have consulted a certain source and request that you do so if you haven't yet. In general, Q&A sessions with course staff will be most productive if you check beforehand that you have consulted the following information sources:

  • Assigned textbook readings
  • General lecture material
  • Lecture material on a particular project
  • Written handout for a particular project
  • Pebbles kernel specification
  • Technical reference material (Linux "manual pages", Intel hardware documentation, etc.)

When possible, avoid questions along the lines of "I don't get xxxx"; try to ask a question about particular material which you find confusing or a case which you believe is not covered by a particular information source.

Contacting us for help

The class web site is http://www.cs.cmu.edu/~410/.

You should read and participate in academic.cs.15-410.qa and are required to monitor academic.cs.15-410.announce. (Visit the Andrew Web Mail Folders page; in the Subscribe/Unsubscribe section of the page, in the right-hand pane, select academic.cs.15-410.announce and hit the "Subscribe" button. This configures your Andrew IMAP account so that any IMAP client, e.g., Mail.app on a Mac, will be aware of your interest in seeing these messages.)

Issues particular to you or your group, and time-critical issues, can be addressed to staff-410@cs.cmu.edu. If you need to discuss a genuinely confidential issue you should contact the instructor(s) directly. But you should not send e-mail to randomly-selected staff members to ask clarification or guidance questions--if nothing else, you may choose somebody who is sick or out of town.

Please do not send us files via electronic mail. Really! If you want us to look at some of your files, you should put them into a private AFS directory, make sure we can read it, and send us the filename. If you use course-issued AFS space, this is easy, since 410 staff can automatically read that. If you use some other AFS space, you will need to do something like this:

% fs sa . de0u:410staff rl
% fs sa .. de0u:410staff l
% fs sa ../.. de0u:410staff l
Eventually you will be told "permission denied" and then you are probably done.

AFS access control lists

Be sure to store your work in a protected area. Since a new AFS directory inherits its parent's access control list, it is possible to create a directory which inadvertently is public.

AFS problems

Like any other large complicated thing, AFS can have problems. If it happens to you, please start by re-reading About your 15-410 AFS Space--please don't e-mail us a question which is already answered in that document.

Formatting

"Documents" should be submitted in a document interchange/publication format such as PDF or HTML (or, if appropriate, Unix-line-delimited 7-bit ASCII). Microsoft Word, WordPerfect, OpenOffice XML, FrameMaker editable-document format, etc., are not interchange formats. PostScript is really a printer transport language rather than a document interchange format, but it will generally suffice.

Also, if we ask you to use a particular filename for something, please do that. We probably intend to use a program to perform some action (such as printing) on all 100-odd files, and if your file doesn't have the right name maybe the right thing won't happen to it.

Hazards

Medical issues

If you experience a medical problem which disrupts your studies, please go to Student Health Services (or another medical provider) and have them emit some piece of paper describing the situation and what you are medically required to do about it. If there are privacy concerns, we will accept a firm statement of the restrictions on your activities without a description of the condition itself.

Please do not come to the course staff and tell us that you've been too sick to attend class and code for two weeks but that it hasn't "been bad enough" to merit medical attention. If nothing else, it probably has been "bad enough" for your partner.

It is probably best to describe an ongoing medical situation to your program administrator or your advisor instead of to us. This has two benefits to you. First, program staff are often better trained to deal with confidential issues than faculty members. Second, your program administrator can take care of notifying all of your instructors that there is a problem and, in general terms, what restrictions there will be on your work. If you are a CS undergraduate, this means you would notify your advisor and/or Catharine Fichtner; if you are an ECE undergraduate or M.S. student, you would probably discuss the matter with Janet Peters and/or Jessica Sun.

Partner problems

Please try to avoid having partner trouble. Seriously! Share your hopes before they turn into concerns, your concerns before they become problems, and your problems before they inflate into crises.

If you contact us about partner trouble early, there is a reasonable likelihood that we can help resolve the problem. If not, we may be able to provide special treatment which can lessen the negative consequences you experience. However, investigation and intervention take time. If you contact us too late, you will be denying both you and your partner the opportunity to receive help. Please don't do this! While some problems can never be truly solved, it is likely that your career after CMU will require you to "involve management" to address issues with co-workers... if you find yourself in a situation which you can't resolve, this will provide you with an opportunity to practice interacting with management.

One special case to avoid is coming to us a day or two before a major deadline to tell us that your partner has been ill, or otherwise not contributing, for multiple weeks. We, and thus you, have many more options if you inform us while a problem is developing, as opposed to after the fact.

Exams

Exams will be closed-book. For the final exam you will probably be permitted to bring in a single sheet of notes.

At CMU, standard operating procedure is that final exams take place after classes end, during a special period of time. Each class is assigned an exam period according to a university-wide procedure which attempts to minimize conflicts.

What this means is that the date and time of the 15-410 final exam will not be decided by the course staff, and we do not know when the university will make the decision (the schedule is posted at approximately the same time every semester, but there is some variation).

It is your responsibility to alert the course staff to any exam conflicts. If we haven't heard from you seven days after a 15-410 exam date has been published, we will expect that to mean you do not have a conflict. In any case, notify us as soon as possible.

Collaboration and Group Work

Please remember: our baseline expectation is that you, starting from our problem statements and specifications, will devise your own solutions to the problems and will then implement those solutions with code you write yourselves. In order for your submissions to be eligible for credit, any time you read code from an outside source, you must first ensure you are doing so in a situation permitted by this course syllabus. Also remember that appropriate credit must always be given when the work of another is used. Using the work of another without giving credit will result in university-level academic integrity actions.

We think a lot can be learned by talking to other students, and, since we're pro-learning, this is generally ok with us. Discussing your data structures, module boundaries, and even the flow through your code is fine. Writing down snippets of code on a whiteboard is also ok (especially if you gesticulate wildly while doing so and use several colors).

However, some sorts of "collaboration", which reduce or impede learning, are not acceptable, such as:

  • "Discussing" code in sufficient detail to fully specify it (see, for example, Jonathan Baccash's BabelBuster C to English to C Translator.
  • Copying or typing in code from other people, or any OS class you might have taken before (if you can meaningfully do the latter, there is a good chance you shouldn't be taking this class for credit). You should also not be reading code produced by other people for OS classes at CMU or elsewhere, or components from "how to write your own mini-OS" kits, tutorials, etc.
  • Allowing other people to type in code for you or debug your code.
  • Allowing other people to read your code before it is turned in or before they have turned in their own code. Note that you must keep any network-accessible copies of your code protected (the default settings on many repository-hosting services such as bitbucket, gitorious, and github are not correct).

In the other direction:

  • You may read books about operating system internals and browse "professional" OS code (e.g., a BSD kernel, the Linux kernel, etc.). When using written reference material or "professional" kernel code, we expect you to study the code thoroughly enough to extract the ideas, set the reference or code aside, and then render the ideas into your own code without referring back to the outside source or to notes, files, or other records derived from the outside source. Your ability to recreate your solution independently will serve as evidence that you understand the work you submit. Copying code or pseudo-code directly, or "transcribing" manually from one written representation to another, are not allowed. We ask that you obey the spirit of this policy, as well as the letter: ensure that all the work you submit is your own and that you fully understand the solution.
  • It's ok to re-use basic code from lower-level CMU classes, if appropriately cited. However, you may not use other code which you did not write without prior permission of the course staff.

If you think you have encountered a gray area, please contact the course staff before making a decision.

You should have a reasonable understanding of all code your group turns in, even parts you didn't write. One easy way to think about this is that exam questions which assume understanding of project components are fair game. Also, while we hope this will be a rare occurence, we we reserve the right to assign partners different grades for a project.

Homework assignments are individual. Your model should be that you can talk about the problems, but then you must erase the whiteboard or shred the napkin, retreat to your cave, and write them up yourself.

If you question the legality of any type of collaboration or consultation, please ask. If you are in a real bind, do what feels right and discuss the issue with a staffer as soon as is possible. If you discuss the issue with us before you turn in your solution or document it as part of your solution, it will not be considered to be academic dishonesty (of course, it might not qualify for full credit, either).

You should be aware that there are several sophisticated code-similarity analysis tools based on machine-learning techniques. Fooling them is possible, but probably requires enough work (and worry) that it is probably better for you to do the assignments yourself.

Please note that the default outcome for any academic integrity violation is a failing course grade for the semester; the violation will be reported to your home academic unit and Student Affairs. Please don't get involved in this--it costs everybody enormous amounts of time during which nothing can be learned about operating systems. If you are having trouble with one assignment but struggle within the rules, you might end up with a failing grade for that assignment, but you may well be able to pass the course, or drop and take it again later. Willfully violating the policies of the course, on the other hand, threatens your opportunity to ever pass the course.

Distribution of Coursework Solutions

As a condition of your participation in the course, you may not make publicly available or distribute to others code you write to solve problems posed by course assignments.

For example, do not include solutions to course assignments in a public "portfolio" on the Web. (You may provide code samples to a prospective employer, assuming the employer in question isn't a CMU student...)

Working Alone on "Group" Projects

While it is possible to complete the major programming projects while working alone, that is not the best approach for most students. If you intend to work alone, you must obtain permission from the instructor(s).

Grades

Auditing

Please see the "Audit Grades" section of the University's Grading Policies document. Students auditing a class are required to to commit to some level of participation, and to meet that commitment in order to receive an audit grade at the end of the semester.

Documentation

Documentation will be a component of your course grades. The exact percentage may vary from one assignment to the next, and may be adjusted in response to class performance, but your model should probably be that documentation will be worth approximately 5% of each programming assignment.

Appeals

In general we will have a "7 CMU business day" deadline on grade appeals. That is not to say that we will never engage in grading archaeology, but we believe we can obtain a greater degree of consistency inside a smaller time window.

Weights and Grade Assignments

Here is a tentative, approximate grading breakdown.

Weight Item
5%Zeroth Programming Project
5%First Programming Project
15%Second Programming Project
25%Third Programming Project
5%Fourth Programming Project
15%Midterm Exam
20%Final Exam
10%Homeworks (~3) and book report

There is an excellent chance that the weight of the kernel project will be increased somewhat, probably at the expense of the homeworks.

In addition, your weighted project average and weighted exam average must each be a passing grade in order to pass the course.

Cutoff points for grades will be set by the course staff based on an examination of the quality of the work turned in by students near the border. Likewise, individual students, especially those near a cutoff, may receive adjustments upward or downward based on factors such as quality improvement, final exam scores, dramatic differences between partners, or other circumstances relevant to the estimation of the staff of which grade best represents the student's work.

Finally, while we do our best to specify our expectations in advance, grade assignment is at the discretion of the course instructor.

Policy on Late Work

Here is a somewhat traditional OS policy on late work:
Each student may grant himself or herself an extension on any homework assignment or project deadline/checkpoint -- but only three (3) days worth of extensions are available during the course of the semester under this policy. Possible configurations include turning in three projects one day late apiece, turning in each homework assignment one day late, etc.
If a team wishes an extension under this policy, the number of days available is the minimum of the number of days that each member has available. Because this might become an issue if you switch partners, it is probably unwise to use up too many late days on the earlier assignments.

Please understand that the use of extensions may, perhaps severely, delay the grading of your assignment. This isn't intended as punishment, it is just the natural consequence of the need to have all of the staff assembled to fairly assign grades. We'll do our best to be timely, but once extensions are injected into the system, this can sometimes become difficult.

We encourage you to reserve extensions for the inevitable: minor illnesses, conferences, University trips, bad karma, &c. But you are free to use them for any reason that you'd like. Just please remember that you have only a small fixed number of extensions.

Extensions beyond the standard quota will only be granted for extremely unusual, extremely unforeseeable, and/or extremely incapacitating circumstances. It is likely that we would require significant evidence of the circumstance and would consult with administrators and/or academic advisors before granting any further extensions. Your grade could be affected, and it is possible that you would be required to take an incomplete grade.

To grant yourself a one-day extension under this policy, use the late-day registration form. Please do so by 00:30 (thirty minutes after the deadline) if possible. Assuming your message is received, the next morning somebody will unlock your hand-in directory so you can again save your work. You may grant yourself multiple one-day extensions for a single project if that turns out to be necessary.

A note on the Simics license

Your use of the Simics simulation software takes place under a software license. Before using Simics for anything other than 15-410 class assignments, please see the instructor to ensure that your planned activities are in accordance with CMU's license.

Recording of lectures

Classroom activities may be taped or recorded by a student for the personal use of that student or for all students presently enrolled in the class only, but may not be further copied, distributed, published or otherwise used for any other purpose without the express written consent of the instructor(s).

Reminder About This Document

This document sets forth specific policies and mechanisms for this class. You must also read the companion document on high-level Expectations.

Acknowledgements

Ideas (and even some text) were stolen from Greg Kesden's 15-412 syllabus, Randy Bryant & Hui Zhang's 15-441 syllabus, and Bob Harper's 15-312 syllabus.


[Last modified Monday March 26, 2012]