Update 1/23: More detailed late policy for Workbooks
Contents
Grading
Note: I will use the letter grade scale (A,AB,…F) and 4-point scale (4=A, 3=B, 0=F) interchangeably.
We will give a grade for the “workbooks and programs” and for the exams. Your final grade will be:
- 35% exams (12% midterm, 18% final, 5% whichever you did better on)
- 65% workbook grade – this includes programming and “bonus points” (see below)
Lectures
The class meets from 11-12:15 on Tuesdays and Thursdays in room 19, Ingraham Hall (map), (AV info).
Lectures are required – material will be presented in lecture that may not be available any other way. There will be no way to make up the material – so if you miss a lecture, ask a classmate. While materials from lectures (slides, videos, code samples, etc.) may be available after class, these are meant as a reminder/supplement for people who attended lecture, not as a replacement. Lecture materials are not meant to replace the lecture.
The lecture room may get quite full for class. Please arrive at lecture on time so you don’t disrupt your classmates by coming late. If your late arrivals are a problem (e.g., you often come late and disturb others), you may not be allowed to enter.
You may use laptops, tablets, or other devices during class for class related activities (e.g., taking notes, trying the code examples the instructor is doing, looking up reference materials). Please be aware that the other students around you will see your screen and may be distracted by it. Your privilege to use a device in class may be revoked if it is abused.
There may be optional lectures, including help sessions, bonus topic sessions, or collaborative coding sessions. These will be held outside of class time. We understand that not everyone will be able to attend.
Readings
Required readings will be posted on the course web page and/or described in the workbooks. All readings will be provided online – either by Canvas (for materials that cannot be shared beyond class), links to the web, or through the UW Library.
You do not need to purchase any books for the class. However, you may choose to buy a physical copy of one of the books we are using if you prefer. See the Books page for details.
Readings are required. Materials in the readings may be tested in the exams or used in projects. The readings are designed to complement the lectures. In some cases, you will be expected to read before lecture to have context for the lecture material. In other cases, you will be expected to read after lecture to reinforce or get detail on topics that were discussed.
Readings include the contents of workbooks.
In some cases, you may be expected to find your own reading on the web. This will be described in the workbooks, and we will ask you what you looked at.
You may need to supplement your reading with other materials from the web. This is especially important for practical issues of the programming assignments. We will make suggestions.
The example code and materials in the workbooks are part of the required readings.
Weekly Workbooks and Projects
See the Workbooks page for more details.
There will be “weekly” workbooks (we expect there to be one per week, but since this is an experiment, we might skip weeks).
With each workbook, you will use a GitHub classroom link to get a repository on GitHub, clone this repo to your own computer, complete the workbook committing your work as you go, and then push the repo back to GitHub so that we can grade it. For each assignment, a description will be posted on Canvas with specific instructions.
With a workbook, you will be expected to read all required parts – which will include the code (the parts you are responsible for will be made clear). You will be expected to add to the programs, and to fill in text areas. Instructions will be given as to what you need to do. You are not only responsible for completing the workbook and turning it in, but also for understanding the material. We will ask questions about the content of the workbooks on the exams.
We will grade workbooks.
- 0 = nothing turned in
- 1 = something turned in, but little evidence of effort
- 2 = unacceptable / missing major parts
- 2.5 = some problems
- 3 = basic parts complete
- 3.5 = all parts complete (doesn’t include optional or bonus parts)
Note that you cannot get an A on for a workbook grade.
In some assignments (but not all), there will be opportunities for “bonus points” – this is how you get from an AB to an A (for the workbooks component of the grade). If you collect enough bonus points over the course of the semester, you can get a 1/2 grade raise (AB to A). So, if you have a “B” for the workbooks, you can’t get an A no matter how many bonus points you get. You can use bonus points to get from a B to an AB, or a BC to a B, etc.
Workbooks will explain opportunities for getting bonus points. It may be by doing an optional part, by doing an extra creative job in some way, or by extending the assignment (see “workbook projects” below).
Workbooks will be due on Fridays, but we will accept them until Monday. In general, the Monday deadline is tight – we may release example solutions, or need to do grading. Unless otherwise specified, you should assume that you cannot turn in a workbook after Monday. We will “collect” assignments (make a copy of them for grading) at this “drop dead” time point.
If you miss handing in an assignment in time, you should still push it to the repository. If you miss the grading collection, you will receive a 0 score. We cannot grant extensions. However, if you have extenuating circumstances (e.g., you have a family emergency, you get sick, you have a job interview), please let us know. We can re-assess missed assignments at the end of the semester if necessary. (if you miss an assignment, you must tell us as soon as possible – do not wait until the end of the semester!)
We will drop your lowest two workbook scores. However, you keep the bonus points from the workbooks whose grades we drop.
Your workbook grade will be the average (after dropping the lowest two) of the workbook grades, plus the bonus (if applicable).
We may assess a penalty of up to 1/2 letter grade (e.g. B to BC) if you are chronically late. We will generally consider timeliness of assignments in dealing with border cases. There is a separate posting with more specific details.
If you turn in fewer than half of the workbooks in time to be graded, you may receive a failing grade for the class. Even if the half of the workbooks you did turn in received good grades.
Workbook Projects
A few times during the semester, there will be optional “projects” to extend a workbook into a more interesting program. These will (in general) be due a week after the workbook itself is due. These “projects” will be an opportunity to earn bonus points. Specific details will be described as part of the workbook description. The projects do not take the place of the workbook: it will not change your workbook grade.
Late Policy
Exams cannot be made up. If you miss it, you’ve missed it.
Workbooks are due on Friday, Madison time. If it’s 12:01 Saturday, then it’s not Friday. Remember, that you need to push your repository to GitHub for us to get it.
Workbooks will be collected from GitHub sometime after the Monday (following the Friday). Probably early Tuesday morning. So be sure to turn things in on (or before) Monday in order to have them graded. If you turn things in (which involves pushing it to GitHub) after Monday, we will not grade it. This hard deadline allows us to give out the answers.
If you don’t turn your workbook in in time to be graded, you will receive a 0 grade for it. However, we may look at it in exceptional cases at the end of the semester.
Course Infrastructure
We will use several “systems” in this class:
- The course web will be used to provide information (such as this page). You are responsible for the materials on it.
- We will use Canvas as a way to communicate grades to students. We will also use Canvas as a way to distribute “private” documents (e.g., files that cannot be shared with students outside of class, or links to set up GitHub classroom). We will also use Canvas as a way to announce when there are updates to the course web. Students should not use Canvas as a way to communicate back to the course staff. Do not use messages or grade comments to communicate to course staff – we may not see it. We may use grade comments as a way to give feedback to you – do not reply to them!
- We will use Piazza as a way for students to communicate – to course staff as well as to discuss course content publicly.
- We will use GitHub (via GitHub Classroom) as a way to distribute “workbooks” (the starting framework for assignments), as well as to turn them in.
- In general, we will avoid using email for class. We will use the course mailing list a few times at the beginning of the semester to point people to the other systems. Please use Piazza to communicate with the course staff. If you send email to a specific course staff member, there may be a delay in a response (and the response might be “ask on Piazza”).
- We may use email as a way to ask a specific question to a specific student. If you are sent an email directly, please respond to it.
Communicating with Course Staff
The preferred mechanism for communicating with course staff is via Piazza.
Policies for GitHub
We will use GitHub as a mechanism to distribute starter code for assignments and for students to turn in their work. See the GIT page for details.
All students must have a GitHub account, and must use this same GitHub account for all assignments. All students should use their own GitHub account. Students will be asked to provide information that will allow us to correspond GitHub accounts and student IDs.
We may use the commit logs to determine the timing of when work has been done. We recommend making regular commits so there is a record of your work. Use the commit dates honestly (it is academic dishonesty to fake commits or alter dates to make it look like you did work when you did not).
Students are responsible for correctly using GIT to turn in their assignments. We will provide instructions for each assignment.
The repositories for class will be provided as part of a special class “organization” that will allow for a level of privacy: each student will only be able to access their own repository, and course staff will have access. Students should not change settings on the repositories (for example, to make it public or change access permissions) unless instructed to do so by course staff.
- All students must have a GitHub account.
- Each student needs to use their own GitHub account.
- You should use the same GitHub account for the entire class. If you need to change your GitHub ID for some reason, contact the course staff.
- We will provide mechanism for you to tell us what your GitHub account is.
- You should not manipulate the dates of your commits.
We are aware that it is possible to “re-write history” and change the dates in your commit history. Academic honesty requires you to not manipulate the history in your repository in order to make it look like you did an assignment on time. For hard deadlines, we will pull (clone/copy) the repositories shortly after the deadline.
Collaboration Policy
Computer graphics is (usually) a team sport. In fact, learning computer graphics (and, arguably, learning in general) is best done in collaboration with others. Unfortunately, in a university class setting, we have the unfortunate constraint that we must grade individuals independently, so we need to have people work independently on graded assignments so that we can assess them. Therefore, there is a fine line between “collaboration” and “academic misconduct”.
For CS559, we want to encourage collaboration. However, we also need to make sure that each individual gets appropriate credit for their work.
Students are encouraged to discuss class topics and assignments with other students, subject to the following rules.
- If you are unsure if something is collaboration or academic misconduct, please ask the instructor or TA for clarification.
- No collaboration is allowed on the exams.
- Assignments and projects must be substantively from the person claiming to have done it. It’s OK to ask for help, but most of the work should be your own.
- Ultimately, each student is responsible for the material. Projects, assignments and exams will require you to understand the assignments, so be careful not to rely on help since at some point you might need to do it your self.
- Collaboration must be a two way street. The person giving help agree. (e.g. don’t look at someone else’s work without their permission).
- Every student must turn in their own assignment, and is responsible for it, unless it is explicitly a group project. For group projects, specific instructions will be given.
- Projects must be “substantially” written by the student handing it in. In particular, the key parts of the project must be completed by the student handing in the project.
- Any code that you didn’t write must be given proper attribution. If you grab a piece of code from the web, another student, some book, … – you must say so!
- We will give you large amounts of example code to work with for various assignments and projects. Be sure to give it proper attribution.
- You may only use external libraries that we provide.
- With JavaScript, you can do “View Source” in the web browser to see how programs you find (including our sample solutions) work. While we encourage you to use this to learn, we discourage you from just copying too much stuff. We urge you not to snoop to find answers to things we want you to figure out yourself, or to steal large pieces of code. Again, this is a fine line: use your judgment, or ask.
- You should make reasonable efforts to keep your work private (from your classmates) so that others do not copy it. You can show them things you made, but please do not give people access to your programs (until after the assignments are due).
- Avoid putting large fragments of code on Piazza, or giving away the answers to key parts of assignments. If you are in doubt, send things privately to the course staff who can help you decide if it is appropriate to make public.
So…
- It is OK to ask a classmate for help. It is not OK to “borrow” their assignment and copy it without their permission. It is not OK to just copy it without understanding it (since you won’t learn the material).
- It is OK to ask a classmate for help looking over your code to find a bug. It is not OK to use a piece of their code without giving them proper attribution, or if its an important part of a project.
- If you ever have a question, ask.
The fact that we are using JavaScript in the web browser creates challenges and opportunities for class with respect to collaboration. You can always do “view source” in a web browser to look at someone’s program. If we give you a sample solution, you can look at it. There are steps one can take to hide their programs, but this complicates things.
You must give proper attribution for anything that you did not create in your README file. This should not be more than a few lines of code (for example, copied from a web tutorial). It may be an “artistic asset” (such as an image, texture, or 3D model), however you may only use things that you have license to use (e.g., it is public domain or has a creative commons license). Instructions will be provided when it is appropriate to use someone else’s artwork.
Programming assignments and workbooks will be turned in via GitHub. You must follow the GitHub classroom procedure to create your own repository (with the starter materials) on GitHub as part of each assignment (instructions will be provided with the assignment). You must clone your personal repository. You must commit changes to this repository. To hand in your work, you must push it back to the GitHub repository you were provided.
Your work will involve modifying the starter materials for each assignment. Sometimes, you will be asked to add new files – but often, you will modify existing files. The assignment will tell you which files you are allowed/required to change/ While you may change any parts of the files as you see fit, we recommend not making unnecessary changes.
All of the code and documentation that you submit should either be (1) the provided starter materials or (2) changes or additions that you conceived-of and typed.
Using Web Resources
Using the web as a resource to help with programming is part of programming these days. We understand that when you have a question, the first thing to do is to search for it. This is especially true for web programming things (like we’re doing) where the official documentation is online.
We understand that you will be using the web as a resource. Discussion sites like stackexchange are a valid resource. You should never copy more than a few lines of code from a resource (and even then, be sure to give attribution). Please try to avoid searching for complete solutions: if we ask you to implement something yourself, please implement it. It’s OK to look up details that you can’t remember: but make sure you understand what you put into your code.
Policy on JavaScript usage
Basic rule: you should start with what we give you, and type everything yourself. If you didn’t type it, you shouldn’t turn it in.
Ironically, these rules are more targeted at JavaScript experts who might want to use things we cannot support in class. If you’re a JavaScript novice and these rules don’t make sense, don’t worry – we’re basically asking you not to do fancy stuff. The Javascript and 559 page will explain.
Your program must run as handed in (no compilation steps). You may not use a transpiler (Babel, Typescript) to create the files that you hand in for use.
You may not add any new libraries that you did not write. You must use the library files that we provide. You should not change the libraries that we provide unless instructed to do so.
You may use whatever features of JavaScript work in the web browser that the grader will use for testing (Google Chrome). If your program only works with Firefox, you can specify that in your README file when you turn the assignment in.
See the Javascript and 559 page for more details.
These same rules apply to HTML and CSS (e.g., you need to write all the HTML and CSS “by hand” – rather than using a pre-processor for a higher level language like SASS or LESS).