Official Project Rubric & Grading Scheme

COMP 536 | Projects

Why This Page Exists

Projects in COMP 536 are not graded only on whether code runs. They are graded on whether you built something scientifically credible, whether you showed that it works, and whether another person can understand and reproduce what you did. This page defines the course-wide rubric that applies across projects unless a specific assignment page adds extra requirements.

Use this page as a student-facing guide to what strong project work looks like in this course. If you want to know how to spend your time wisely before a deadline, start here.

ImportantCorrectness comes first

A project that is ambitious but wrong will earn less credit than a simpler project that is correct, validated, and reproducible. Scope matters, but scope is never the whole story.

How Project Grades Work

Your project grade reflects three questions:

1. What did you build?
2. How convincingly did you show that it works?
3. How easy is it for someone else to run, inspect, and learn from your work?

That means the grade is not just a checklist of features. A submission can lose substantial credit for missing validation, broken reproducibility, unclear figures, or weak explanation even if the repo looks busy. On the other hand, a carefully validated project with clear scientific reasoning can score very well even if it stays close to the required baseline.

Submission Gates

Before points are assigned, the submission must meet the basic course contract described in the project page and the submission guide.

A complete submission normally includes:

• the required source code and supporting files,
• a runnable non-interactive workflow,
• required figures and outputs,
• a README.md with usage instructions,
• a research memo in PDF form,
• a growth memo in PDF form, when required by the project,
• acknowledgment of collaborators and outside help.

If one of those required pieces is missing, the project is still graded, but the missing piece lowers the relevant category score and may limit the overall ceiling because the submission is incomplete relative to the course contract.

What Your Project Grade Is Really Based On

Project grading in this course is holistic. That means I am not pretending that correctness, validation, reproducibility, code quality, and communication are completely separate things. In real scientific work, they overlap.

In practice, your project is judged through three big questions:

1. Does it work?

Did you build the required computational instrument, and do the main results appear correct?

2. Is it convincing?

Did you include enough validation, analysis, and interpretation to make the results believable rather than merely runnable?

3. Can another person follow and reuse it?

Is the repo organized, readable, and reproducible enough that someone else could inspect your work and regenerate the main outputs?

Grade Anchors

A Range (9.0 - 10.0)

An A-range project is one where correctness, validation, and reproducibility are all clearly demonstrated. You trust the results, the repo is easy to use, and the submission feels scientifically credible rather than merely complete.

B Range (7.5 - 8.9)

A B-range project is mostly correct and credible, but one part is noticeably weaker. Common cases are thin validation, a messy or fragile repo, or analysis that reports results without fully interpreting them.

C Range (6.0 - 7.4)

A C-range project runs and shows meaningful learning, but it is not yet convincing. The work may be fragile, under-validated, hard to interpret, or incomplete in ways that make scientific trust difficult.

D Range (4.5 - 5.9)

A D-range project has major problems. Results may be incorrect, major components may be missing, or the repo may not be runnable enough to support meaningful evaluation, but there is still enough submitted work to assess.

F Range (below 4.5)

An F-range project is missing too much trustworthy work to count as passing. Common cases are non-runnable repositories, missing core deliverables, or results that are not defensible enough to support course credit.

Broad Rubric Categories

If you want to know where to focus your effort, these are the broad categories that support the grade anchor above.

Category	Weight	What it covers
Functionality	30%	Required scope, correctness of implementation, and completion of project-specific deliverables
Scientific credibility	35%	Validation, quality of evidence, interpretation of results, and whether the conclusions are trustworthy
Reproducibility and usability	20%	Repo contract, clarity of execution, code organization, readability, and ease of rerunning the work
Communication and professionalism	15%	Memo quality, figures, README clarity, acknowledgment of help, and overall presentation

These categories are intentionally broad. That is because strong evidence in one area often supports another. For example, a project with strong validation usually also has stronger analysis, and a project that is easy to reproduce is usually easier to understand.

Project Grade Scale

Projects use a 10-point grading scale first. That score is then translated into the SDSU-style plus/minus letter grade shown below.

SDSU-style project grade	10-point score	Percentage equivalent
A	9.3 - 10.0	93% - 100%
A-	9.0 - 9.2	90% - 92%
B+	8.5 - 8.9	85% - 89%
B	8.0 - 8.4	80% - 84%
B-	7.5 - 7.9	75% - 79%
C+	7.0 - 7.4	70% - 74%
C	6.5 - 6.9	65% - 69%
C-	6.0 - 6.4	60% - 64%
D+	5.5 - 5.9	55% - 59%
D	5.0 - 5.4	50% - 54%
D-	4.5 - 4.9	45% - 49%
F	Below 4.5	Below 45%

This means projects use the same familiar letter-grade labels you see elsewhere at SDSU, but they are assigned through the project-specific 10-point system above rather than through a percentage-first checklist.

Relation to the Syllabus Grade Scale

The syllabus grade scale gives the standard course-level percentage cutoffs used elsewhere in the course. For projects, however, this rubric supersedes the syllabus percentage-first grading scale.

That is deliberate. Project work in this course is holistic, and the 10-point project scale makes it possible to grade different kinds of submissions more consistently. It also generally works in students’ favor: instead of over-penalizing one weak category in isolation, I can evaluate the overall scientific credibility of the work and then translate that judgment into an SDSU-style plus/minus project grade.

Graduate Overlay and Project-Specific Additions

Some project pages include extra expectations, especially for graduate students. When that happens, those requirements are not “extra credit.” They become part of the required project scope and should be scored primarily through Functionality and Scientific credibility.

Project-specific pages may also name special deliverables such as a required extension, a presentation, or a domain-specific validation target. Those requirements supplement this rubric rather than replacing it.

Student Planning Checklist

Before you submit, ask yourself:

• Can someone else run my project without guessing what command to use?
• Do I show evidence that the core method is correct?
• Do my figures and memo explain what the results mean, not just what I did?
• Does my repository look organized enough that a grader can audit it quickly?
• If my project required an extension or graduate overlay, did I actually complete it?

If your answer to any of those is “not really,” that is the best place to spend your final hour of project time.

What Usually Raises a Project by One Grade Band

The most common ways to move a project upward are:

• add one convincing validation test or reference comparison,
• make the repo easier to run from the README.md,
• improve the memo so it explains what the results mean instead of only describing what you did,
• fix one major missing or fragile part of the required baseline.