projects.md

# General Project Directions

## Collaboration/Conduct Guidance

Students may work alone or optionally work in groups of two.

**Code copying between students is not allowed in this course, except
between project partners.  Copying includes emailing, taking photos,
looking while typing line by line, etc.  Copying code then changing it
is still copying and thus not allowed.  Lock your compute when it's
not attended.**

**Partners**
* there should only be one submission repo for the team
* it's NOT OK to submit code from your partner that you didn't help write or understand

**Other Collaboration**
* you can talk about logic and help each other debug
* **no code copying**; for example, no emailing code (or similar), no photos of code, no looking at code and typing it line by line
* copying code then changing it is still copying and thus not allowed

**ChatGPT, Large Language Models, Interactive Tools**
* use of the tools is permitted, with proper citation
* a "chats" directory should contain screenshots or PDFs of any chats, in their entirety.  Name them as chat1.png, chat2.png, etc.  PDF and JPG formats are also permitted.

**Other Online Resources**
* you **may not** use any online resource intended to provide solutions specific to CS 544
* you **may** use other online resources, with proper citation
* add a comment in your code before anything you copied from such sources

## Compute Setup

For most projects, we'll use VMs provided by CSL.  See the directions
[here](csl-vm.md) about how to access it.  The first project will
involve some setup (like installing docker) on the VM.

For later projects, we'll share details about how to do use cloud
resources.

## Project Repository Creation

At the start of each project, you must submit the [partner
form](https://tyler.caraza-harter.com/cs544/s25/forms.html).  This
will indicate whether or now you have a partner (and if so, who).
Upon a valid a submission, we'll create a repo for you and your
partner (if any) on GitLab and email you a link.

## Submission

You'll submit by pushing to your GitLab project repo.  Be
carefull not to push after the deadline unless your intention is to
submit late (see policy below).

* projects have four parts; for notebooks, use big headers to divide your work into the four parts ("# Part 1: ...")
* for question based project work, (Q1, Q2, etc), include comments like ("# Q1: ...") before the answers
* each project will specify some specific files you need to commit (like a p1.ipynb or server.py); in addition to those, include whatever is needed (except data) for somebody to run your code

## Policies

### Late Policy

The general rule is no submissions >3 days late.  Each day late suffers a 10% penalty (so a 90% submission that is 2 days late gets 70%).

Common exceptions, and who to ask:
- Illness: you can **ask your TA** to override the late penalty, but they cannot give more than 3 days.  To qualify, you share a link to your repo; your commit history should show you made a substantial start on the project at least 3 days prior to the deadline
- Busyness: same policy as illness (you might be unusually busy due to travel, extracurriculars, other courses, etc).  This shouldn't happen more than a couple times a semester
- McBurney accomodations: **email your instructor** a proposed policy for the semester (we can discuss again if your situation changes during the semester)

If you're working with a project partner who has the late penalty waived by a TA, that means it is waived for you as well, even if you don't have special circumstances yourself.

For other cases (falling very far behind, family emergencies, etc), **reach out to your instructor** to discuss possible accomodations.

### Resubmission Policy

Resubmissions generally won't be allowed once projects have been
graded, except in unusual situations, or when we made a mistake on our
end (like a misleading specification).

### "Pre-grading" Policy

We won't pre-grade work, so don't ask questions like "does this all
look good?" during office hours.  When grading many assignments, it's
natural we'll notice issues someone might miss during office hours.
We also don't have the staff time to effectively grade submissions
twice.

You can always ask more specific questions if you're looking for some reassurance, such as:

* "does X in the spec mean Y, or does it mean Z"
* "what would be a good way to test this function?"
* "would this plot be clearer with ????, or without it"
* "is this result supposed to be deterministic, or are there reasons it might be different for other deployments?"